From stpeter@stpeter.im Fri Apr 1 00:24:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21273A6B03 for ; Fri, 1 Apr 2011 00:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M5ZiKrbJdlp for ; Fri, 1 Apr 2011 00:24:10 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2C8EB3A6B32 for ; Fri, 1 Apr 2011 00:24:07 -0700 (PDT) Received: from dhcp-12cb.meeting.ietf.org (dhcp-12cb.meeting.ietf.org [130.129.18.203]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6091B40022 for ; Fri, 1 Apr 2011 01:27:42 -0600 (MDT) Message-ID: <4D957DF9.50708@stpeter.im> Date: Fri, 01 Apr 2011 09:25:45 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090006030308020105090800" Subject: [OAUTH-WG] moving to Security Area X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:24:13 -0000 This is a cryptographically signed message in MIME format. --------------ms090006030308020105090800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As discussed in the WG session at Prague just now, in discussion with the Security Area Directors I have decided to move the OAuth Working Group from the Applications Area to the Security Area of the IETF. The rationale is that all of the most important work remaining for the WG to produce OAuth 2.0 is security-related. Moving the WG to the Security Area will enable us to receive all of the right security reviews as early as possible before submitting the base specification to the IESG. Stephen Farrell of the Security Area will be your new AD, and I will stay on as Applications Area advisor. Let's complete the important work of the OAuth WG and do the best we can to make HTTP-based authorization more secure. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090006030308020105090800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQw MTA3MjU0NVowIwYJKoZIhvcNAQkEMRYEFNZMLRAZN7Xnwaxtej5Lt4TZoawUMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBFD6gjYNkFnyezPiVf/rAnyED50qWAafYKbCFQ9GYt6GHBsuFB3epTXrYa CDkg6D6VjxVyDo/LTpHIHrTHb2OQpndeF4LsVlTzZ741RQdrHa9EtkrHWEahj+kCT5V+A28+ MuyQFPk97fYkQ133kppWoNrF4eyUfJLu7HBTEdsceUA/NkT/0Nwx6o36mPS6xtDRKnQibrBK 25lvZXChNy6Go0prPnDDOIG/fT1zUBBP+ai3FAsC6z8CAU3PWXMd8maLHjqfZGfnSMwu53vy xG8uv5gd7G4RZdi0Ng4+Y9is8FzNDVixk3/riEwdFC3HQW2CZVxVDtuvbtbYNs7prFbxAAAA AAAA --------------ms090006030308020105090800-- From mark.mcgloin@ie.ibm.com Fri Apr 1 01:10:46 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B9C3A6BFB; Fri, 1 Apr 2011 01:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRQI8Wzjm1wq; Fri, 1 Apr 2011 01:10:44 -0700 (PDT) Received: from mtagate3.uk.ibm.com (mtagate3.uk.ibm.com [194.196.100.163]) by core3.amsl.com (Postfix) with ESMTP id 691FD3A6B0B; Fri, 1 Apr 2011 01:10:42 -0700 (PDT) Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p318CJPJ014512; Fri, 1 Apr 2011 08:12:19 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p318CtCT1654904; Fri, 1 Apr 2011 09:12:55 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p318CIG1010405; Fri, 1 Apr 2011 02:12:19 -0600 Received: from d06ml093.portsmouth.uk.ibm.com (d06ml093.portsmouth.uk.ibm.com [9.149.104.171]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p318CID0010402; Fri, 1 Apr 2011 02:12:18 -0600 In-Reply-To: References: X-KeepSent: 09DBBC4F:46DED330-80257865:002CF3EB; type=4; name=$KeepSent To: Marius Scurtescu X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Fri, 1 Apr 2011 09:11:40 +0100 X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 01/04/2011 09:11:43 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Cc: Greg Brockman , oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] OAuth without HTTP redirects X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:10:46 -0000 Hi Marius, Can you provide very high level details on what that approach is? thanks Mark oauth-bounces@ietf.org wrote on 01/04/2011 02:34:56: > Marius Scurtescu > Sent by: oauth-bounces@ietf.org > > 01/04/2011 02:34 > > To > > Greg Brockman > > cc > > oauth@ietf.org > > Subject > > Re: [OAUTH-WG] OAuth without HTTP redirects > > Hi Greg, > > Google is working on a pure JavaScript flow which does not involve redirects. > > Marius > > > > On Thu, Mar 17, 2011 at 12:20 PM, Greg Brockman wrote: > > Hi, > > > > I notice that the current OAuth2 draft seems to have browser redire= cts > > baked in rather deeply. =A0Are there any plans to add support for f= lows > > that don't involve HTTP redirects? =A0For example, it seems at the > > moment that pure JavaScript applications aren't well-supported, as = the > > resource owner must be redirected to the authorization endpoint, th= us > > leaving the JS app. =A0Now of course trying to do the OAuth flow fr= om > > within the JS app (say by displaying the authorization endpoint wit= hin > > an iframe) might expose phishing attacks, but one could imagine e.g= . a > > plugin that integrates with the browser in order to provide a > > relatively unforgeable OAuth authorization endpoint. > > > > More generally, does this sound like a use-case that OAuth would be= > > interested in supporting? > > > > Thanks, > > > > - gdb > > > > (Reposting from oauth@googlegroups.com as this seems a more > appropriate forum.) > > _______________________________________________ > > OAuth mailing 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 mark.mcgloin@ie.ibm.com Fri Apr 1 02:10:21 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7C13A6774; Fri, 1 Apr 2011 02:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syS0MyttkQMB; Fri, 1 Apr 2011 02:10:20 -0700 (PDT) Received: from mtagate7.uk.ibm.com (mtagate7.uk.ibm.com [194.196.100.167]) by core3.amsl.com (Postfix) with ESMTP id 88D013A67A3; Fri, 1 Apr 2011 02:10:19 -0700 (PDT) Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate7.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p319BuCr002216; Fri, 1 Apr 2011 09:11:56 GMT Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p319CQLR1867984; Fri, 1 Apr 2011 10:12:33 +0100 Received: from d06av06.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p319BnsN019266; Fri, 1 Apr 2011 03:11:49 -0600 Received: from d06ml093.portsmouth.uk.ibm.com (d06ml093.portsmouth.uk.ibm.com [9.149.104.171]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p319BnsK019260; Fri, 1 Apr 2011 03:11:49 -0600 In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664D700@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664D700@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-KeepSent: ECDFC275:5D7567F4-80257865:0030D87E; type=4; name=$KeepSent To: Eran Hammer-Lahav X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Fri, 1 Apr 2011 10:11:11 +0100 X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 01/04/2011 10:11:14 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:10:21 -0000 U28gd2UgaGF2ZSAyIGRpZmZlcmVudCBjb21tdW5pdGllcyBvZiBPYXV0aCBkZXZlbG9wZXJzIHRo YXQgd2lsbCBuZXZlcg0KYWdyZWUuDQoNClNIT1VMRDogVHlwaWNhbGx5IHRoZSBzb2NpYWwgbmV0 d29ya2luZyBzaXRlcyB0aGF0IG5lZWQgdG8gY2F0ZXIgZm9yIHRhaWwNCmVuZCBkZXZlbG9wZXJz IGJ5IG5vdCBlbmZvcmNpbmcgVExTIG9uIHJlZGlyZWN0X3VyaS4gSXQgaXMgYSByaXNrIHRvIHRo aW5rDQp0aGF0IHVzaW5nIHN0cm9uZyBsYW5ndWFnZSBpbiB0aGUgc3BlYyB3aWxsIGhlbHAgdGhl bSBhcHByZWNpYXRlIHRoZSBpc3N1ZXMNCk1VU1Q6IFR5cGljYWxseSBlbnRlcnByaXNlIG9yZ2Fu aXNhdGlvbnMgKEkgYW0gaW4gdGhpcyBjYW1wKS4gVGhleSBjYW4NCmVuZm9yY2UgaW5kaXJlY3Rs eSBieSBvbmx5IHN1cHBvcnRpbmcgcmVnaXN0ZXJlZCBjYWxsYmFjayB1cmxzIGFuZCBlbnN1cmUN CnRob3NlIHVzZSBUTFMNCg0KDQpJcyB0aGVyZSBhbnkgd2F5IHRoZSBzcGVjIGNhbiBiZSBhbHRl cmVkIHRvIGNhdGVyIGZvciBib3RoIGNhbXBzLiBIb3cgYWJvdXQNCmFuIGFkZGl0aW9uYWwgZ3Jh bnQgdHlwZSA9ICdzZWN1cmVfY29kZScgd2hpY2ggbWFuZGF0ZXMgdGhlIHVzZSBvZiBUTFMuDQpU aGlzIHdvbid0IGJyZWFrIGFueW9uZSB1c2luZyB0aGUgY3VycmVudCBncmFudCB0eXBlID0gJ2Nv ZGUnIGFuZCBwcm92aWRlcnMNCmNhbiBjaG9vc2Ugd2hpY2ggdG8gc3VwcG9ydC4NCg0KDQpNYXJr DQoNCg0Kb2F1dGgtYm91bmNlc0BpZXRmLm9yZyB3cm90ZSBvbiAwMS8wNC8yMDExIDAxOjA5OjQ2 Og0KDQo+IEVyYW4gSGFtbWVyLUxhaGF2IDxlcmFuQGh1ZW5pdmVyc2UuY29tPg0KPiBTZW50IGJ5 OiBvYXV0aC1ib3VuY2VzQGlldGYub3JnDQo+DQo+IDAxLzA0LzIwMTEgMDE6MDkNCj4NCj4gVG8N Cj4NCj4gT0F1dGggV0cgPG9hdXRoQGlldGYub3JnPg0KPg0KPiBjYw0KPg0KPiBTdWJqZWN0DQo+ DQo+IFtPQVVUSC1XR10gQXV0aG9yaXphdGlvbiBjb2RlIHNlY3VyaXR5IGlzc3VlIChyZWZyYW1l ZCkNCj4NCj4gKFRoZSBwcmV2aW91cyB0aHJlYWQgaXMgYmVjYW1lIGNvbXBsZXRlbHkgaW5hY2Nl c3NpYmxlIHRvIGFueW9uZSBub3QNCj4gZm9sbG93aW5nIGl0IGNhcmVmdWxseSBmb3IgdGhlIHBh c3Qgd2VlayBvciBzby4gRm9yIHRoZSBzYWtlIG9mDQo+IHJlYWNoaW5nIGEgY29uY2x1c2lvbiwg SSBhbSBnb2luZyB0byBzdW0gdXAgdGhlIGlzc3VlIGFuZCB0cnkgdG8NCj4gc3RhcnQgb3ZlciB3 aXRoIGEgbW9yZSBuYXJyb3cgZm9jdXMuKQ0KPg0KPiAqIFRoZSBzZWN1cml0eSBpc3N1ZSBpcyB2 ZXJ5IHNpbXBsZToNCj4NCj4gVGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyB0aGUgb25seSBhcnRp ZmFjdCBiaW5kaW5nIHRoZSByZXNvdXJjZQ0KPiBvd25lciBncmFudGluZyBhY2Nlc3MgYXQgdGhl IGF1dGhvcml6YXRpb24gZW5kcG9pbnQgdG8gdGhlIHJlc291cmNlDQo+IG93bmVyIGJlaW5nIHJl ZGlyZWN0ZWQgYmFjayB0byB0aGUgY2xpZW50LiBPQXV0aCAxLjBhIGFkZGVkIHRoZQ0KPiB2ZXJp ZmljYXRpb24gY29kZSBmb3IgdGhpcyBzb2xlIHB1cnBvc2UuIElmIHRoZSBhdXRob3JpemF0aW9u IGNvZGUNCj4gaXMgaW50ZXJjZXB0ZWQgYnkgYSBNSVRNIChlLmcuIGZha2UgYWlycG9ydCB3aWZp KSwgdGhlIGF0dGFja2VyIGNhbg0KPiB0YWtlIG92ZXIgdGhlIHNlc3Npb24gYW5kIHByZXRlbmQg dG8gYmUgdGhlIHJlYWwgcmVzb3VyY2Ugb3duZXIuDQo+IFNpbmNlIHRoZSBjbGllbnQgaGFzIG5v IHdheSB0byBkZXRlY3QgdGhpcywgaXQgd2lsbCBncmFudCB0aGUNCj4gYXR0YWNrZXIgYWNjZXNz IHRvIHRoZSBjbGllbnQgYXBwbGljYXRpb24gd2hpY2ggdXN1YWxseSBpbmNsdWRlcw0KPiBkYXRh IG9idGFpbiB2aWEgdGhlIGFjY2VzcyB0b2tlbiAocmVjZWl2ZWQgdXNpbmcgdGhlIGNvbXByb21p c2UNCj4gYXV0aG9yaXphdGlvbiBjb2RlKS4NCj4NCj4gVGhlIGF0dGFjayBkb2VzIG5vdCBnaXZl IHRoZSBhdHRhY2tlciBhbnkgZGlyZWN0IGFjY2VzcyB0byB0aGUNCj4gYWNjZXNzIHRva2VuLCB0 aGUgY2xpZW50IGNyZWRlbnRpYWxzLCBvciBhbnl0aGluZyBvdGhlciB0aGFuIHRoZQ0KPiBjbGll bnQgYXBwbGljYXRpb24gaXRzZWxmLiBIb3dldmVyLCB0aGUgY2xpZW50IGFwcGxpY2F0aW9uIGlz DQo+IHR5cGljYWxseSBjb25zaWRlcmVkIGFuIGV4dGVuc2lvbiBvZiB0aGUgcmVzb3VyY2Ugc2Vy dmVyLg0KPg0KPiBBbm90aGVyIHZhcmlhdGlvbiBvZiB0aGlzIGF0dGFjayBpcyByZWxhdGVkIHRv IHRoZSBpbXBsaWNpdCBncmFudA0KPiAodXNlci1hZ2VudCBmbG93KS4gSWYgYSBNSVRNIGNhbiBp bnRlcmNlcHQgdGhlIHJlc3BvbnNlIGluIGZpZ3VyZSA0DQo+IHN0ZXAgRSwgaXQgY2FuIG1hbmlw dWxhdGUgdGhlIHNjcmlwdCB0byBvYnRhaW4gdGhlIGFjY2VzcyB0b2tlbiAoYW5kDQo+IGFueSBz ZWNyZXQgb3Igb3RoZXIgcHJvcGVydGllcyBpcyBpbmNsdWRlZCkuDQo+DQo+IEluIG90aGVyIHdv cmRzLCB0aGUgY2xpZW50IHJlZGlyZWN0aW9uIFVSSSBtdXN0IHVzZSBhIHNlY3VyZSBjaGFubmVs DQo+IHRvIGNvbXBsZXRlbHkgcHJldmVudCB0aGVzZSBpc3N1ZXMuDQo+DQo+IEhvd2V2ZXIsIGl0 IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgdGhpcyBpcyBub3QgT0F1dGggc3BlY2lmaWMuIEl0 DQo+IGlzIGEgZ2VuZXJhbCBzZWN1cml0eSBjb25jZXJuIHJlZ2FyZGluZyBhbGwgb3RoZXIgYXNw ZWN0cyBvZiB0aGUNCj4gY2xpZW50IGlmIGl0IGlzIG5vdCBmdWxseSBzZWN1cmUuIEZvciBleGFt cGxlLCBpZiB0aGUgY2xpZW50IHVzZXMNCj4gaW5zZWN1cmUgY29va2llcyBvciBwcm92aWRlcyBh dXRoZW50aWNhdGlvbiB2aWEgb3RoZXIgbWVhbnMgbm90DQo+IHVzaW5nIFRMUy4gSWYgdGhlIGNs aWVudCBpcyBpbnNlY3VyZSwgd2VsbCwgaXTigJlzIGluc2VjdXJlIGluY2x1ZGluZw0KPiBpdHMg T0F1dGggcmVkaXJlY3Rpb24gZW5kcG9pbnQuDQo+DQo+ICogVGhlIHR3byBzb2x1dGlvbnMNCj4N Cj4gVGhlIGRlYmF0ZSBpcyB3aGljaCBvZiB0aGUgZm9sbG93aW5nIHR3byBsYW5ndWFnZSBhbHRl cm5hdGl2ZSB3ZQ0KPiB3YW50IHRvIGluY2x1ZGUgaW4gdGhlIHNwZWNpZmljYXRpb246DQo+DQo+ IDEuIEluY2x1ZGUgYSBub3JtYXRpdmUgTVVTVCB1c2UgVExTIGZvciB0aGUgY2xpZW50IHJlZGly ZWN0aW9uIFVSSQ0KZW5kcG9pbnQuDQo+IDIuIEluY2x1ZGUgYSBub3JtYXRpdmUgU0hPVUxEIHVz ZSBUTFMgZm9yIHRoZSBjbGllbnQgcmVkaXJlY3Rpb24gVVJJDQo+IGVuZHBvaW50IHdpdGggc3Ry b25nIGxhbmd1YWdlIGV4cGxhaW5pbmcgdGhlIHZhcmlvdXMgYXR0YWNrcw0KPiBwb3NzaWJsZSBp ZiB0aGUgZW5kcG9pbnQgaXMgbm90IG1hZGUgc2VjdXJlLg0KPg0KPiBCb3RoIG9wdGlvbnMgcmVm bGVjdCB0aGUgc2FtZSBzZWN1cml0eSBpc3N1ZSwgYnV0ICpjb21tdW5pY2F0ZSogdGhlICpzYW1l DQo+ICogc29sdXRpb24gZGlmZmVyZW50bHkuIFNpbmNlIHRoaXMgaXMganVzdCBhIHNwZWNpZmlj YXRpb24gKG5vDQo+IHN0YW5kYXJkIHBvbGljZSksIHRoaXMgaXMganVzdCBhIG1hbnVhbCwgbm90 IGFuIGFjdHVhbCBkZWZlbnNlLg0KPg0KPiAtLS0gWW91IGNhbiBzdG9wIHJlYWRpbmcgaGVyZSBp ZiB5b3UgYXJlIHNob3J0IG9uIHRpbWUuIFRoaXMgc2hvdWxkDQo+IGdpdmUgeW91IGFsbCB0aGUg aW5mb3JtYXRpb24geW91IG5lZWQgdG8ga25vdyAtLS0NCj4NCj4NCj4gKiBUaGUgZGlmZmljdWx0 eQ0KPg0KPiBUaGVyZSBpcyBubyBkZWJhdGUgdGhhdCB0aGlzIGlzIGEgdmFsaWQgc2VjdXJpdHkg Y29uY2VybiwgYW5kIHRoYXQNCj4gdGhlIG9ubHkgc29sdXRpb24gaXMgdG8gYXBwbHkgYSBNSVRN IHByb3RlY3Rpb24gKGkuZS4gVExTKS4NCj4NCj4gSG93ZXZlciwgZ2l2ZW4gdGhlIGN1cnJlbnQg d2ViIGxhbmRzY2FwZSBhbmQgT0F1dGggaGlzdG9yeSAob3IgYW55DQo+IG90aGVyIHdlYiBBUEkp LCByZXF1aXJpbmcgVExTIGlzIGFuIHVuZXhwZWN0ZWQgY2hhbmdlIHRvIHRoZSAqZWNvc3lzdGVt DQo+ICouIEZyb20gdW5vZmZpY2lhbCBkaXNjdXNzaW9ucyBJIGhhZCB3aXRoIFlhaG9vISwgRmFj ZWJvb2ssIGFuZA0KPiBHb29nbGUgdG9kYXksIGFsbCB0aHJlZSBpbmRpY2F0ZWQgdGhleSBoYXZl IG5vIHBsYW5zIHRvIGVuZm9yY2Ugc3VjaA0KPiBhIHJlc3RyaWN0aW9uLiBOb25lIG9mIHRoZSBt YWpvciBPQXV0aCAxLjAgcHJvdmlkZXJzIHRvZGF5IGVuZm9yY2UNCj4gc3VjaCBhIHJlcXVpcmVt ZW50LCBldmVuIHRob3VnaCB0aGUgZXhhY3Qgc2FtZSBpc3N1ZSBpcyBwcmVzZW50IGluIE9BdXRo DQoxLjBhLg0KPg0KPiBUaGUgY2hhbGxlbmdlIGlzIHRvIGZpbmQgdGhlIHJpZ2h0ICpsYW5ndWFn ZSogYmFsYW5jZSBiZXR3ZWVuDQo+IHJlZmxlY3RpbmcgcmVhbGl0eSBhbmQgcmVmbGVjdGluZyB0 aGUgaWRlYWwgc2VjdXJpdHkgY29uZmlndXJhdGlvbi4NCj4gVGhpcyBpcyBub3QgYSBxdWVzdGlv biBvZiB3aGF0IGlzIGFwcHJvcHJpYXRlIGluIGNlcnRhaW4gc2l0dWF0aW9uLA0KPiBvciB0aGUg dW5pcXVlIGF0dGFjayB2ZWN0b3JzIG9mIGluZGl2aWR1YWwgZGVwbG95bWVudHMuIEl0IGlzIGFi b3V0DQo+IGhvdyB3ZSB0YWxrIGFib3V0IHNlY3VyaXR5LCBhbmQgaG93IHRvIGJlc3QgcHVzaCB0 aGUgd2ViIHRvd2FyZHMNCj4gYmV0dGVyIHNlY3VyaXR5IHdpdGhvdXQgcHVzaGluZyB0b28gaGFy ZCB0b28gZmFzdC4NCj4NCj4gVG8gbWUsIHRoZSBjaGFsbGVuZ2UgaXMgaG93IHRvIGVmZmVjdGl2 ZWx5IGNvbW11bmljYXRlIHRoZSBpc3N1ZSwNCj4gd2l0aG91dCBmb3JjaW5nIGNvbXBhbmllcyB0 byBrbm93aW5nbHkgdmlvbGF0ZSB0aGUgc3BlY2lmaWNhdGlvbi4NCj4gVGhlIHByb2JsZW0gd2l0 aCB0aGF0IGlzIHRoYXQgZXhwZXJpZW5jZSBzaG93cyBpdOKAmXMgYSBzbGlwcGVyeQ0KPiBzbG9w ZS4gT25jZSB5b3UgYXJlIG5vIGxvbmdlciBmdWxseSBjb21wbGlhbnQsIGl0IGlzIGVhc2llciB0 byBsZXQNCj4gb3RoZXIgTVVTVHMgc2xpZGUuDQo+DQo+IEluIHRoZSBjb25zdW1lciB3ZWIgc3Bh Y2Ug4oCTIHdoaWNoIG9yaWdpbmF0ZWQgYW5kIGlzIHN0aWxsIHRoZQ0KPiBwcmltYXJ5IGF1ZGll bmNlIGZvciB0aGlzIHdvcmsgKG5vIG1hdHRlciBob3cgbXVjaCB0aGUgZW50ZXJwcmlzZQ0KPiBm b2xrcyBoZXJlIHByb3Rlc3QpIOKAkyBlbmZvcmNpbmcgc3VjaCBhIHJlcXVpcmVtZW50IG9uIGNs aWVudA0KPiBkZXZlbG9wZXJzIGlzIGltcHJhY3RpY2FsLiBWZXJ5IGZldyBwcm92aWRlcnMgY2Fu IGFmZm9yZCB0byBhbGllbmF0ZQ0KPiB0aGVpciBkZXZlbG9wZXJzIGJ5IG1ha2luZyBzdWNoIGEg cmVxdWlyZW1lbnQgdG9kYXkuIEl0IHdpbGwgYWxzbw0KPiBjb21wbGV0ZWx5IHVuZG8gYWxsIHRo ZSBvdGhlciB3b3JrIGRvbmUgdG8gbWFrZSB0aGlzIHNwZWNpZmljYXRpb24NCj4gbW9yZSBhY2Nl c3NpYmxlIGFuZCBlYXNpZXIgdG8gZGVwbG95LiBIYW5kcyBkb3duLCBkZXBsb3lpbmcgc2VydmVy LQ0KPiBzaWRlIFRMUyBpcyBtdWNoIGhhcmRlciBmb3IgY2xpZW50IGRldmVsb3BlcnMgdGhhbiBm aWd1cmluZyBPQXV0aCAxLg0KPiAwIHNpZ25hdHVyZXMuDQo+DQo+IEVITA0KPg0KPg0KPg0KPg0K Pg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPiAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg= From eran@hueniverse.com Fri Apr 1 02:12:37 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68363A679C for ; Fri, 1 Apr 2011 02:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pqi3+lwJM36u for ; Fri, 1 Apr 2011 02:12:34 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3F8143A6774 for ; Fri, 1 Apr 2011 02:12:33 -0700 (PDT) Received: (qmail 27804 invoked from network); 1 Apr 2011 09:14:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Apr 2011 09:14:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 1 Apr 2011 02:14:13 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Fri, 1 Apr 2011 02:14:03 -0700 Thread-Topic: Reques to drop section 3 Thread-Index: AcvwTHF45x2l7hflQ7Wx6+6NV+MdWQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664D735@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664D735P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Reques to drop section 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:12:37 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664D735P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There was (still is) a long heated debate at the WG meeting today about cli= ent authentication and the dropped client assertion credentials section. I = want to repeat my past view (and this time post it as an open issue), that = this entire section makes no sense in this document. OAuth should not be de= fining hackish HTTP authentication schemes, especially ones not using the R= FC2617 framework. Someone can easily register the client_password parameter as an extension (= it's a nasty hack but I won't stand in its way), as well as any other poorl= y design client authentication scheme using form-encoded parameters to auth= entication an HTTP request... So - I want to see section 3 turned into a brief discussion about client au= thentication which gives HTTP Basic auth as an example and nothing else. Cl= ient authentication is already 95% out of scope. EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234465664D735P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There was (still= is) a long heated debate at the WG meeting today about client authenticati= on and the dropped client assertion credentials section. I want to repeat m= y past view (and this time post it as an open issue), that this entire sect= ion makes no sense in this document. OAuth should not be defining hackish H= TTP authentication schemes, especially ones not using the RFC2617 framework= .

 

Someone can easily register the client_password parameter as an extensi= on (it’s a nasty hack but I won’t stand in its way), as well as= any other poorly design client authentication scheme using form-encoded pa= rameters to authentication an HTTP request…

 

So – I want to se= e section 3 turned into a brief discussion about client authentication whic= h gives HTTP Basic auth as an example and nothing else. Client authenticati= on is already 95% out of scope.

&nb= sp;

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664D735P3PW5EX1MB01E_-- From tonynad@microsoft.com Fri Apr 1 05:15:12 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE3C28D026 for ; Fri, 1 Apr 2011 05:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrBt+UiSGl54 for ; Fri, 1 Apr 2011 05:15:07 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 35C4528D04E for ; Fri, 1 Apr 2011 05:09:05 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 1 Apr 2011 05:10:35 -0700 Received: from TX2EHSOBE005.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.270.2; Fri, 1 Apr 2011 05:10:35 -0700 Received: from mail127-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.8; Fri, 1 Apr 2011 12:10:34 +0000 Received: from mail127-tx2 (localhost.localdomain [127.0.0.1]) by mail127-tx2-R.bigfish.com (Postfix) with ESMTP id C5BDAF88347 for ; Fri, 1 Apr 2011 12:10:34 +0000 (UTC) X-SpamScore: -30 X-BigFish: PS-30(zz9371PzzdafM1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:SN1PRD0302HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail127-tx2 (localhost.localdomain [127.0.0.1]) by mail127-tx2 (MessageSwitch) id 1301659834298140_7548; Fri, 1 Apr 2011 12:10:34 +0000 (UTC) Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.254]) by mail127-tx2.bigfish.com (Postfix) with ESMTP id 460FC12F0051; Fri, 1 Apr 2011 12:10:34 +0000 (UTC) Received: from SN1PRD0302HT001.namprd03.prod.outlook.com (65.55.94.9) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 1 Apr 2011 12:10:33 +0000 Received: from SN1PRD0302MB100.namprd03.prod.outlook.com ([169.254.10.226]) by SN1PRD0302HT001.namprd03.prod.outlook.com ([10.14.149.47]) with mapi id 14.01.0225.027; Fri, 1 Apr 2011 12:10:32 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , OAuth WG Thread-Topic: Reques to drop section 3 Thread-Index: AcvwTHF45x2l7hflQ7Wx6+6NV+MdWQAECfsQ Date: Fri, 1 Apr 2011 12:10:31 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E7234465664D735@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664D735@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.66.132] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E7114EB24DSN1PRD0302MB100_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN1PRD0302HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] Reques to drop section 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 12:15:12 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E7114EB24DSN1PRD0302MB100_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This section makes sense as it does setup for the identification and authen= tication of the client, so I do believe that it makes sense in the document= . Thomas undertook the task to revive the Client Credentials section from = previous draft that will include normative text, which when asked the room = showed interest, I believe he indicated 3 weeks to do this. I assume you are objecting to not using just HTTP authentication? There are= scenarios where we need SAML and other technology so only allowing HTTP au= thentication is too restrictive and to allow the profiling for interoperabi= lity of these technologies we need an extension point here. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, April 01, 2011 2:14 AM To: OAuth WG Subject: [OAUTH-WG] Reques to drop section 3 There was (still is) a long heated debate at the WG meeting today about cli= ent authentication and the dropped client assertion credentials section. I = want to repeat my past view (and this time post it as an open issue), that = this entire section makes no sense in this document. OAuth should not be de= fining hackish HTTP authentication schemes, especially ones not using the R= FC2617 framework. Someone can easily register the client_password parameter as an extension (= it's a nasty hack but I won't stand in its way), as well as any other poorl= y design client authentication scheme using form-encoded parameters to auth= entication an HTTP request... So - I want to see section 3 turned into a brief discussion about client au= thentication which gives HTTP Basic auth as an example and nothing else. Cl= ient authentication is already 95% out of scope. EHL --_000_B26C1EF377CB694EAB6BDDC8E624B6E7114EB24DSN1PRD0302MB100_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This section makes sen= se as it does setup for the identification and authentication of the client= , so I do believe that it makes sense in the document.  Thomas underto= ok the task to revive the Client Credentials section from previous draft that will include normative text, which when a= sked the room showed interest, I believe he indicated 3 weeks to do this.

 

I assume you are objec= ting to not using just HTTP authentication? There are scenarios where we need SAML and other= technology so only allowing HTTP authentication is too restrictive and to = allow the profiling for interoperability of these technologies we need an e= xtension point here.=

 

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Friday, April 01, 2011 2:14 AM
To: OAuth WG
Subject: [OAUTH-WG] Reques to drop section 3

 

There was (still is) a long heated debate at the WG = meeting today about client authentication and the dropped client assertion = credentials section. I want to repeat my past view (and this time post it a= s an open issue), that this entire section makes no sense in this document. OAuth should not be defining hack= ish HTTP authentication schemes, especially ones not using the RFC2617 fram= ework.

 

Someone can easily register the client_password para= meter as an extension (it’s a nasty hack but I won’t stand in i= ts way), as well as any other poorly design client authentication scheme us= ing form-encoded parameters to authentication an HTTP request…

 

So – I want to see section 3 turned into a bri= ef discussion about client authentication which gives HTTP Basic auth as an= example and nothing else. Client authentication is already 95% out of scop= e.

 

EHL

--_000_B26C1EF377CB694EAB6BDDC8E624B6E7114EB24DSN1PRD0302MB100_-- From jricher@mitre.org Fri Apr 1 05:27:45 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2351B28C801 for ; Fri, 1 Apr 2011 05:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.942 X-Spam-Level: X-Spam-Status: No, score=-4.942 tagged_above=-999 required=5 tests=[AWL=1.657, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ0ZxLEbmb9R for ; Fri, 1 Apr 2011 05:27:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 59A6928D046 for ; Fri, 1 Apr 2011 05:20:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8420421B113F; Fri, 1 Apr 2011 08:22:33 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7E1A221B0263; Fri, 1 Apr 2011 08:22:33 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 1 Apr 2011 08:22:33 -0400 From: "Richer, Justin P." To: Eran Hammer-Lahav , OAuth WG Date: Fri, 1 Apr 2011 08:18:48 -0400 Thread-Topic: Reques to drop section 3 Thread-Index: AcvwTHF45x2l7hflQ7Wx6+6NV+MdWQAGoLgK Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E7234465664D735@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664D735@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Reques to drop section 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 12:27:45 -0000 -1 once again I want to keep the client password mechanism in core as it reflects the way= that most (nearly all in my personal experience) client implementations pa= ss their auth parameters today. I do think that the assertion credentials c= ould live fine in a simple extension, though, with the same arguments as th= e assertion grant type. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Ham= mer-Lahav [eran@hueniverse.com] Sent: Friday, April 01, 2011 5:14 AM To: OAuth WG Subject: [OAUTH-WG] Reques to drop section 3 There was (still is) a long heated debate at the WG meeting today about cli= ent authentication and the dropped client assertion credentials section. I = want to repeat my past view (and this time post it as an open issue), that = this entire section makes no sense in this document. OAuth should not be de= fining hackish HTTP authentication schemes, especially ones not using the R= FC2617 framework. Someone can easily register the client_password parameter as an extension (= it=92s a nasty hack but I won=92t stand in its way), as well as any other p= oorly design client authentication scheme using form-encoded parameters to = authentication an HTTP request=85 So =96 I want to see section 3 turned into a brief discussion about client = authentication which gives HTTP Basic auth as an example and nothing else. = Client authentication is already 95% out of scope. EHL From Michael.Jones@microsoft.com Fri Apr 1 06:18:16 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B676A3A6877 for ; Fri, 1 Apr 2011 06:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TknhGA3dIxFs for ; Fri, 1 Apr 2011 06:18:16 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id F0F3E3A6838 for ; Fri, 1 Apr 2011 06:18:15 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 1 Apr 2011 06:19:49 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.38]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0270.002; Fri, 1 Apr 2011 06:19:49 -0700 From: Mike Jones To: "Richer, Justin P." , Eran Hammer-Lahav , OAuth WG Thread-Topic: [OAUTH-WG] Reques to drop section 3 Thread-Index: Acvwb3gCsGr10rJISnOaB3dsHiYaGA== Date: Fri, 1 Apr 2011 13:19:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252C5D8F@TK5EX14MBXC203.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.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Reques to drop section 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:18:16 -0000 Also -1 on dropping section 3. Rather, we need to restore the client asser= tion credentials to 3, per the outcome of the discussion at today's working= group meeting. I'm glad that we're headed in that direction. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of R= icher, Justin P. Sent: Friday, April 01, 2011 5:19 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Reques to drop section 3 -1 once again I want to keep the client password mechanism in core as it reflects the way= that most (nearly all in my personal experience) client implementations pa= ss their auth parameters today. I do think that the assertion credentials c= ould live fine in a simple extension, though, with the same arguments as th= e assertion grant type. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Ham= mer-Lahav [eran@hueniverse.com] Sent: Friday, April 01, 2011 5:14 AM To: OAuth WG Subject: [OAUTH-WG] Reques to drop section 3 There was (still is) a long heated debate at the WG meeting today about cli= ent authentication and the dropped client assertion credentials section. I = want to repeat my past view (and this time post it as an open issue), that = this entire section makes no sense in this document. OAuth should not be de= fining hackish HTTP authentication schemes, especially ones not using the R= FC2617 framework. Someone can easily register the client_password parameter as an extension (= it's a nasty hack but I won't stand in its way), as well as any other poorl= y design client authentication scheme using form-encoded parameters to auth= entication an HTTP request... So - I want to see section 3 turned into a brief discussion about client au= thentication which gives HTTP Basic auth as an example and nothing else. Cl= ient authentication is already 95% out of scope. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Apr 1 08:11:50 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7843A688C for ; Fri, 1 Apr 2011 08:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP-L5swv+Tdd for ; Fri, 1 Apr 2011 08:11:48 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8CE193A68A2 for ; Fri, 1 Apr 2011 08:11:48 -0700 (PDT) Received: (qmail 18058 invoked from network); 1 Apr 2011 15:13:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Apr 2011 15:13:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 1 Apr 2011 08:13:19 -0700 From: Eran Hammer-Lahav To: Eran Hammer-Lahav Date: Fri, 1 Apr 2011 08:13:12 -0700 Thread-Topic: [OAUTH-WG] Authorization code security issue (reframed) Thread-Index: Acvwf1VwgLM00JtzQheIuiGLl260sA== Message-ID: <39437D50-786F-48B8-9107-FEB9EED139C5@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465664D700@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664D700@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_39437D50786F48B89107FEB9EED139C5hueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 15:11:50 -0000 --_000_39437D50786F48B89107FEB9EED139C5hueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdtIHdpdGhkcmF3aW5nIG15IHZvdGUuIFdoZW4gb3RoZXJzIGRlY2lkZSB3aGF0IHRoZXkgd2Fu dCB0byBkbyBJJ2xsIGFwcGx5IGl0Lg0KDQpFSEwNCg0KT24gTWFyIDMxLCAyMDExLCBhdCAxNzox MCwgIkVyYW4gSGFtbWVyLUxhaGF2IiA8ZXJhbkBodWVuaXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBo dWVuaXZlcnNlLmNvbT4+IHdyb3RlOg0KDQooVGhlIHByZXZpb3VzIHRocmVhZCBpcyBiZWNhbWUg Y29tcGxldGVseSBpbmFjY2Vzc2libGUgdG8gYW55b25lIG5vdCBmb2xsb3dpbmcgaXQgY2FyZWZ1 bGx5IGZvciB0aGUgcGFzdCB3ZWVrIG9yIHNvLiBGb3IgdGhlIHNha2Ugb2YgcmVhY2hpbmcgYSBj b25jbHVzaW9uLCBJIGFtIGdvaW5nIHRvIHN1bSB1cCB0aGUgaXNzdWUgYW5kIHRyeSB0byBzdGFy dCBvdmVyIHdpdGggYSBtb3JlIG5hcnJvdyBmb2N1cy4pDQoNCiogVGhlIHNlY3VyaXR5IGlzc3Vl IGlzIHZlcnkgc2ltcGxlOg0KDQpUaGUgYXV0aG9yaXphdGlvbiBjb2RlIGlzIHRoZSBvbmx5IGFy dGlmYWN0IGJpbmRpbmcgdGhlIHJlc291cmNlIG93bmVyIGdyYW50aW5nIGFjY2VzcyBhdCB0aGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byB0aGUgcmVzb3VyY2Ugb3duZXIgYmVpbmcgcmVkaXJl Y3RlZCBiYWNrIHRvIHRoZSBjbGllbnQuIE9BdXRoIDEuMGEgYWRkZWQgdGhlIHZlcmlmaWNhdGlv biBjb2RlIGZvciB0aGlzIHNvbGUgcHVycG9zZS4gSWYgdGhlIGF1dGhvcml6YXRpb24gY29kZSBp cyBpbnRlcmNlcHRlZCBieSBhIE1JVE0gKGUuZy4gZmFrZSBhaXJwb3J0IHdpZmkpLCB0aGUgYXR0 YWNrZXIgY2FuIHRha2Ugb3ZlciB0aGUgc2Vzc2lvbiBhbmQgcHJldGVuZCB0byBiZSB0aGUgcmVh bCByZXNvdXJjZSBvd25lci4gU2luY2UgdGhlIGNsaWVudCBoYXMgbm8gd2F5IHRvIGRldGVjdCB0 aGlzLCBpdCB3aWxsIGdyYW50IHRoZSBhdHRhY2tlciBhY2Nlc3MgdG8gdGhlIGNsaWVudCBhcHBs aWNhdGlvbiB3aGljaCB1c3VhbGx5IGluY2x1ZGVzIGRhdGEgb2J0YWluIHZpYSB0aGUgYWNjZXNz IHRva2VuIChyZWNlaXZlZCB1c2luZyB0aGUgY29tcHJvbWlzZSBhdXRob3JpemF0aW9uIGNvZGUp Lg0KDQpUaGUgYXR0YWNrIGRvZXMgbm90IGdpdmUgdGhlIGF0dGFja2VyIGFueSBkaXJlY3QgYWNj ZXNzIHRvIHRoZSBhY2Nlc3MgdG9rZW4sIHRoZSBjbGllbnQgY3JlZGVudGlhbHMsIG9yIGFueXRo aW5nIG90aGVyIHRoYW4gdGhlIGNsaWVudCBhcHBsaWNhdGlvbiBpdHNlbGYuIEhvd2V2ZXIsIHRo ZSBjbGllbnQgYXBwbGljYXRpb24gaXMgdHlwaWNhbGx5IGNvbnNpZGVyZWQgYW4gZXh0ZW5zaW9u IG9mIHRoZSByZXNvdXJjZSBzZXJ2ZXIuDQoNCkFub3RoZXIgdmFyaWF0aW9uIG9mIHRoaXMgYXR0 YWNrIGlzIHJlbGF0ZWQgdG8gdGhlIGltcGxpY2l0IGdyYW50ICh1c2VyLWFnZW50IGZsb3cpLiBJ ZiBhIE1JVE0gY2FuIGludGVyY2VwdCB0aGUgcmVzcG9uc2UgaW4gZmlndXJlIDQgc3RlcCBFLCBp dCBjYW4gbWFuaXB1bGF0ZSB0aGUgc2NyaXB0IHRvIG9idGFpbiB0aGUgYWNjZXNzIHRva2VuIChh bmQgYW55IHNlY3JldCBvciBvdGhlciBwcm9wZXJ0aWVzIGlzIGluY2x1ZGVkKS4NCg0KSW4gb3Ro ZXIgd29yZHMsIHRoZSBjbGllbnQgcmVkaXJlY3Rpb24gVVJJIG11c3QgdXNlIGEgc2VjdXJlIGNo YW5uZWwgdG8gY29tcGxldGVseSBwcmV2ZW50IHRoZXNlIGlzc3Vlcy4NCg0KSG93ZXZlciwgaXQg aXMgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCB0aGlzIGlzIG5vdCBPQXV0aCBzcGVjaWZpYy4gSXQg aXMgYSBnZW5lcmFsIHNlY3VyaXR5IGNvbmNlcm4gcmVnYXJkaW5nIGFsbCBvdGhlciBhc3BlY3Rz IG9mIHRoZSBjbGllbnQgaWYgaXQgaXMgbm90IGZ1bGx5IHNlY3VyZS4gRm9yIGV4YW1wbGUsIGlm IHRoZSBjbGllbnQgdXNlcyBpbnNlY3VyZSBjb29raWVzIG9yIHByb3ZpZGVzIGF1dGhlbnRpY2F0 aW9uIHZpYSBvdGhlciBtZWFucyBub3QgdXNpbmcgVExTLiBJZiB0aGUgY2xpZW50IGlzIGluc2Vj dXJlLCB3ZWxsLCBpdOKAmXMgaW5zZWN1cmUgaW5jbHVkaW5nIGl0cyBPQXV0aCByZWRpcmVjdGlv biBlbmRwb2ludC4NCg0KKiBUaGUgdHdvIHNvbHV0aW9ucw0KDQpUaGUgZGViYXRlIGlzIHdoaWNo IG9mIHRoZSBmb2xsb3dpbmcgdHdvIGxhbmd1YWdlIGFsdGVybmF0aXZlIHdlIHdhbnQgdG8gaW5j bHVkZSBpbiB0aGUgc3BlY2lmaWNhdGlvbjoNCg0KMS4gSW5jbHVkZSBhIG5vcm1hdGl2ZSBNVVNU IHVzZSBUTFMgZm9yIHRoZSBjbGllbnQgcmVkaXJlY3Rpb24gVVJJIGVuZHBvaW50Lg0KMi4gSW5j bHVkZSBhIG5vcm1hdGl2ZSBTSE9VTEQgdXNlIFRMUyBmb3IgdGhlIGNsaWVudCByZWRpcmVjdGlv biBVUkkgZW5kcG9pbnQgd2l0aCBzdHJvbmcgbGFuZ3VhZ2UgZXhwbGFpbmluZyB0aGUgdmFyaW91 cyBhdHRhY2tzIHBvc3NpYmxlIGlmIHRoZSBlbmRwb2ludCBpcyBub3QgbWFkZSBzZWN1cmUuDQoN CkJvdGggb3B0aW9ucyByZWZsZWN0IHRoZSBzYW1lIHNlY3VyaXR5IGlzc3VlLCBidXQgKmNvbW11 bmljYXRlKiB0aGUgKnNhbWUqIHNvbHV0aW9uIGRpZmZlcmVudGx5LiBTaW5jZSB0aGlzIGlzIGp1 c3QgYSBzcGVjaWZpY2F0aW9uIChubyBzdGFuZGFyZCBwb2xpY2UpLCB0aGlzIGlzIGp1c3QgYSBt YW51YWwsIG5vdCBhbiBhY3R1YWwgZGVmZW5zZS4NCg0KLS0tIFlvdSBjYW4gc3RvcCByZWFkaW5n IGhlcmUgaWYgeW91IGFyZSBzaG9ydCBvbiB0aW1lLiBUaGlzIHNob3VsZCBnaXZlIHlvdSBhbGwg dGhlIGluZm9ybWF0aW9uIHlvdSBuZWVkIHRvIGtub3cgLS0tDQoNCg0KKiBUaGUgZGlmZmljdWx0 eQ0KDQpUaGVyZSBpcyBubyBkZWJhdGUgdGhhdCB0aGlzIGlzIGEgdmFsaWQgc2VjdXJpdHkgY29u Y2VybiwgYW5kIHRoYXQgdGhlIG9ubHkgc29sdXRpb24gaXMgdG8gYXBwbHkgYSBNSVRNIHByb3Rl Y3Rpb24gKGkuZS4gVExTKS4NCg0KSG93ZXZlciwgZ2l2ZW4gdGhlIGN1cnJlbnQgd2ViIGxhbmRz Y2FwZSBhbmQgT0F1dGggaGlzdG9yeSAob3IgYW55IG90aGVyIHdlYiBBUEkpLCByZXF1aXJpbmcg VExTIGlzIGFuIHVuZXhwZWN0ZWQgY2hhbmdlIHRvIHRoZSAqZWNvc3lzdGVtKi4gRnJvbSB1bm9m ZmljaWFsIGRpc2N1c3Npb25zIEkgaGFkIHdpdGggWWFob28hLCBGYWNlYm9vaywgYW5kIEdvb2ds ZSB0b2RheSwgYWxsIHRocmVlIGluZGljYXRlZCB0aGV5IGhhdmUgbm8gcGxhbnMgdG8gZW5mb3Jj ZSBzdWNoIGEgcmVzdHJpY3Rpb24uIE5vbmUgb2YgdGhlIG1ham9yIE9BdXRoIDEuMCBwcm92aWRl cnMgdG9kYXkgZW5mb3JjZSBzdWNoIGEgcmVxdWlyZW1lbnQsIGV2ZW4gdGhvdWdoIHRoZSBleGFj dCBzYW1lIGlzc3VlIGlzIHByZXNlbnQgaW4gT0F1dGggMS4wYS4NCg0KVGhlIGNoYWxsZW5nZSBp cyB0byBmaW5kIHRoZSByaWdodCAqbGFuZ3VhZ2UqIGJhbGFuY2UgYmV0d2VlbiByZWZsZWN0aW5n IHJlYWxpdHkgYW5kIHJlZmxlY3RpbmcgdGhlIGlkZWFsIHNlY3VyaXR5IGNvbmZpZ3VyYXRpb24u IFRoaXMgaXMgbm90IGEgcXVlc3Rpb24gb2Ygd2hhdCBpcyBhcHByb3ByaWF0ZSBpbiBjZXJ0YWlu IHNpdHVhdGlvbiwgb3IgdGhlIHVuaXF1ZSBhdHRhY2sgdmVjdG9ycyBvZiBpbmRpdmlkdWFsIGRl cGxveW1lbnRzLiBJdCBpcyBhYm91dCBob3cgd2UgdGFsayBhYm91dCBzZWN1cml0eSwgYW5kIGhv dyB0byBiZXN0IHB1c2ggdGhlIHdlYiB0b3dhcmRzIGJldHRlciBzZWN1cml0eSB3aXRob3V0IHB1 c2hpbmcgdG9vIGhhcmQgdG9vIGZhc3QuDQoNClRvIG1lLCB0aGUgY2hhbGxlbmdlIGlzIGhvdyB0 byBlZmZlY3RpdmVseSBjb21tdW5pY2F0ZSB0aGUgaXNzdWUsIHdpdGhvdXQgZm9yY2luZyBjb21w YW5pZXMgdG8ga25vd2luZ2x5IHZpb2xhdGUgdGhlIHNwZWNpZmljYXRpb24uIFRoZSBwcm9ibGVt IHdpdGggdGhhdCBpcyB0aGF0IGV4cGVyaWVuY2Ugc2hvd3MgaXTigJlzIGEgc2xpcHBlcnkgc2xv cGUuIE9uY2UgeW91IGFyZSBubyBsb25nZXIgZnVsbHkgY29tcGxpYW50LCBpdCBpcyBlYXNpZXIg dG8gbGV0IG90aGVyIE1VU1RzIHNsaWRlLg0KDQpJbiB0aGUgY29uc3VtZXIgd2ViIHNwYWNlIOKA kyB3aGljaCBvcmlnaW5hdGVkIGFuZCBpcyBzdGlsbCB0aGUgcHJpbWFyeSBhdWRpZW5jZSBmb3Ig dGhpcyB3b3JrIChubyBtYXR0ZXIgaG93IG11Y2ggdGhlIGVudGVycHJpc2UgZm9sa3MgaGVyZSBw cm90ZXN0KSDigJMgZW5mb3JjaW5nIHN1Y2ggYSByZXF1aXJlbWVudCBvbiBjbGllbnQgZGV2ZWxv cGVycyBpcyBpbXByYWN0aWNhbC4gVmVyeSBmZXcgcHJvdmlkZXJzIGNhbiBhZmZvcmQgdG8gYWxp ZW5hdGUgdGhlaXIgZGV2ZWxvcGVycyBieSBtYWtpbmcgc3VjaCBhIHJlcXVpcmVtZW50IHRvZGF5 LiBJdCB3aWxsIGFsc28gY29tcGxldGVseSB1bmRvIGFsbCB0aGUgb3RoZXIgd29yayBkb25lIHRv IG1ha2UgdGhpcyBzcGVjaWZpY2F0aW9uIG1vcmUgYWNjZXNzaWJsZSBhbmQgZWFzaWVyIHRvIGRl cGxveS4gSGFuZHMgZG93biwgZGVwbG95aW5nIHNlcnZlci1zaWRlIFRMUyBpcyBtdWNoIGhhcmRl ciBmb3IgY2xpZW50IGRldmVsb3BlcnMgdGhhbiBmaWd1cmluZyBPQXV0aCAxLjAgc2lnbmF0dXJl cy4NCg0KRUhMDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aA0K --_000_39437D50786F48B89107FEB9EED139C5hueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5JJ20gd2l0aGRyYXdpbmcgbXkgdm90 ZS4gV2hlbiBvdGhlcnMgZGVjaWRlIHdoYXQgdGhleSB3YW50IHRvIGRvIEknbGwgYXBwbHkgaXQu PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5FSEw8YnI+PGJyPk9uIE1hciAzMSwgMjAxMSwgYXQg MTc6MTAsICJFcmFuIEhhbW1lci1MYWhhdiIgJmx0OzxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5p dmVyc2UuY29tIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rp dj48ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+KFRoZSBwcmV2aW91cyB0aHJlYWQgaXMgYmVjYW1lIGNvbXBsZXRl bHkgaW5hY2Nlc3NpYmxlIHRvIGFueW9uZSBub3QgZm9sbG93aW5nIGl0IGNhcmVmdWxseSBmb3Ig dGhlIHBhc3Qgd2VlayBvciBzby4gRm9yIHRoZSBzYWtlIG9mIHJlYWNoaW5nIGEgY29uY2x1c2lv biwgSSBhbSBnb2luZyB0byBzdW0gdXAgdGhlIGlzc3VlIGFuZCB0cnkgdG8gc3RhcnQgb3ZlciB3 aXRoIGEgbW9yZSBuYXJyb3cgZm9jdXMuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4qIFRoZSBzZWN1cml0eSBpc3N1ZSBpcyB2 ZXJ5IHNpbXBsZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyB0aGUgb25seSBhcnRp ZmFjdCBiaW5kaW5nIHRoZSByZXNvdXJjZSBvd25lciBncmFudGluZyBhY2Nlc3MgYXQgdGhlIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQgdG8gdGhlIHJlc291cmNlIG93bmVyIGJlaW5nIHJlZGlyZWN0 ZWQgYmFjayB0byB0aGUgY2xpZW50LiBPQXV0aCAxLjBhIGFkZGVkIHRoZSB2ZXJpZmljYXRpb24g Y29kZSBmb3IgdGhpcyBzb2xlIHB1cnBvc2UuIElmIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaXMg aW50ZXJjZXB0ZWQgYnkgYSBNSVRNIChlLmcuIGZha2UgYWlycG9ydCB3aWZpKSwgdGhlIGF0dGFj a2VyIGNhbiB0YWtlIG92ZXIgdGhlIHNlc3Npb24gYW5kIHByZXRlbmQgdG8gYmUgdGhlIHJlYWwg cmVzb3VyY2Ugb3duZXIuIFNpbmNlIHRoZSBjbGllbnQgaGFzIG5vIHdheSB0byBkZXRlY3QgdGhp cywgaXQgd2lsbCBncmFudCB0aGUgYXR0YWNrZXIgYWNjZXNzIHRvIHRoZSBjbGllbnQgYXBwbGlj YXRpb24gd2hpY2ggdXN1YWxseSBpbmNsdWRlcyBkYXRhIG9idGFpbiB2aWEgdGhlIGFjY2VzcyB0 b2tlbiAocmVjZWl2ZWQgdXNpbmcgdGhlIGNvbXByb21pc2UgYXV0aG9yaXphdGlvbiBjb2RlKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhlIGF0dGFjayBkb2VzIG5vdCBnaXZlIHRoZSBhdHRhY2tlciBhbnkgZGlyZWN0IGFj Y2VzcyB0byB0aGUgYWNjZXNzIHRva2VuLCB0aGUgY2xpZW50IGNyZWRlbnRpYWxzLCBvciBhbnl0 aGluZyBvdGhlciB0aGFuIHRoZSBjbGllbnQgYXBwbGljYXRpb24gaXRzZWxmLiBIb3dldmVyLCB0 aGUgY2xpZW50IGFwcGxpY2F0aW9uIGlzIHR5cGljYWxseSBjb25zaWRlcmVkIGFuIGV4dGVuc2lv biBvZiB0aGUgcmVzb3VyY2Ugc2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Bbm90aGVyIHZhcmlhdGlvbiBvZiB0aGlz IGF0dGFjayBpcyByZWxhdGVkIHRvIHRoZSBpbXBsaWNpdCBncmFudCAodXNlci1hZ2VudCBmbG93 KS4gSWYgYSBNSVRNIGNhbiBpbnRlcmNlcHQgdGhlIHJlc3BvbnNlIGluIGZpZ3VyZSA0IHN0ZXAg RSwgaXQgY2FuIG1hbmlwdWxhdGUgdGhlIHNjcmlwdCB0byBvYnRhaW4gdGhlIGFjY2VzcyB0b2tl biAoYW5kIGFueSBzZWNyZXQgb3Igb3RoZXIgcHJvcGVydGllcyBpcyBpbmNsdWRlZCkuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkluIG90aGVyIHdvcmRzLCB0aGUgY2xpZW50IHJlZGlyZWN0aW9uIFVSSSBtdXN0IHVzZSBhIHNl Y3VyZSBjaGFubmVsIHRvIGNvbXBsZXRlbHkgcHJldmVudCB0aGVzZSBpc3N1ZXMuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhv d2V2ZXIsIGl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgdGhpcyBpcyBub3QgT0F1dGggc3Bl Y2lmaWMuIEl0IGlzIGEgZ2VuZXJhbCBzZWN1cml0eSBjb25jZXJuIHJlZ2FyZGluZyBhbGwgb3Ro ZXIgYXNwZWN0cyBvZiB0aGUgY2xpZW50IGlmIGl0IGlzIG5vdCBmdWxseSBzZWN1cmUuIEZvciBl eGFtcGxlLCBpZiB0aGUgY2xpZW50IHVzZXMgaW5zZWN1cmUgY29va2llcyBvciBwcm92aWRlcyBh dXRoZW50aWNhdGlvbiB2aWEgb3RoZXIgbWVhbnMgbm90IHVzaW5nIFRMUy4gSWYgdGhlIGNsaWVu dCBpcyBpbnNlY3VyZSwgd2VsbCwgaXTigJlzIGluc2VjdXJlIGluY2x1ZGluZyBpdHMgT0F1dGgg cmVkaXJlY3Rpb24gZW5kcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiogVGhlIHR3byBzb2x1dGlvbnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhl IGRlYmF0ZSBpcyB3aGljaCBvZiB0aGUgZm9sbG93aW5nIHR3byBsYW5ndWFnZSBhbHRlcm5hdGl2 ZSB3ZSB3YW50IHRvIGluY2x1ZGUgaW4gdGhlIHNwZWNpZmljYXRpb246PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjEuIEluY2x1 ZGUgYSBub3JtYXRpdmUgTVVTVCB1c2UgVExTIGZvciB0aGUgY2xpZW50IHJlZGlyZWN0aW9uIFVS SSBlbmRwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIuIEluY2x1ZGUgYSBub3Jt YXRpdmUgU0hPVUxEIHVzZSBUTFMgZm9yIHRoZSBjbGllbnQgcmVkaXJlY3Rpb24gVVJJIGVuZHBv aW50IHdpdGggc3Ryb25nIGxhbmd1YWdlIGV4cGxhaW5pbmcgdGhlIHZhcmlvdXMgYXR0YWNrcyBw b3NzaWJsZSBpZiB0aGUgZW5kcG9pbnQgaXMgbm90IG1hZGUgc2VjdXJlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Cb3RoIG9w dGlvbnMgcmVmbGVjdCB0aGUgc2FtZSBzZWN1cml0eSBpc3N1ZSwgYnV0ICo8Yj5jb21tdW5pY2F0 ZTwvYj4qIHRoZSAqPGI+c2FtZTwvYj4qIHNvbHV0aW9uIGRpZmZlcmVudGx5LiBTaW5jZSB0aGlz IGlzIGp1c3QgYSBzcGVjaWZpY2F0aW9uIChubyBzdGFuZGFyZCBwb2xpY2UpLCB0aGlzIGlzIGp1 c3QgYSBtYW51YWwsIG5vdCBhbiBhY3R1YWwgZGVmZW5zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS0tIFlvdSBjYW4gc3Rv cCByZWFkaW5nIGhlcmUgaWYgeW91IGFyZSBzaG9ydCBvbiB0aW1lLiBUaGlzIHNob3VsZCBnaXZl IHlvdSBhbGwgdGhlIGluZm9ybWF0aW9uIHlvdSBuZWVkIHRvIGtub3cgLS0tPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KiBUaGUgZGlmZmljdWx0eTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVy ZSBpcyBubyBkZWJhdGUgdGhhdCB0aGlzIGlzIGEgdmFsaWQgc2VjdXJpdHkgY29uY2VybiwgYW5k IHRoYXQgdGhlIG9ubHkgc29sdXRpb24gaXMgdG8gYXBwbHkgYSBNSVRNIHByb3RlY3Rpb24gKGku ZS4gVExTKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgZ2l2ZW4gdGhlIGN1cnJlbnQgd2ViIGxhbmRzY2FwZSBh bmQgT0F1dGggaGlzdG9yeSAob3IgYW55IG90aGVyIHdlYiBBUEkpLCByZXF1aXJpbmcgVExTIGlz IGFuIHVuZXhwZWN0ZWQgY2hhbmdlIHRvIHRoZSAqPGI+ZWNvc3lzdGVtPC9iPiouIEZyb20gdW5v ZmZpY2lhbCBkaXNjdXNzaW9ucyBJIGhhZCB3aXRoIFlhaG9vISwgRmFjZWJvb2ssIGFuZCBHb29n bGUgdG9kYXksIGFsbCB0aHJlZSBpbmRpY2F0ZWQgdGhleSBoYXZlIG5vIHBsYW5zIHRvIGVuZm9y Y2Ugc3VjaCBhIHJlc3RyaWN0aW9uLiBOb25lIG9mIHRoZSBtYWpvciBPQXV0aCAxLjAgcHJvdmlk ZXJzIHRvZGF5IGVuZm9yY2Ugc3VjaCBhIHJlcXVpcmVtZW50LCBldmVuIHRob3VnaCB0aGUgZXhh Y3Qgc2FtZSBpc3N1ZSBpcyBwcmVzZW50IGluIE9BdXRoIDEuMGEuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBjaGFsbGVu Z2UgaXMgdG8gZmluZCB0aGUgcmlnaHQgKjxiPmxhbmd1YWdlPC9iPiogYmFsYW5jZSBiZXR3ZWVu IHJlZmxlY3RpbmcgcmVhbGl0eSBhbmQgcmVmbGVjdGluZyB0aGUgaWRlYWwgc2VjdXJpdHkgY29u ZmlndXJhdGlvbi4gVGhpcyBpcyBub3QgYSBxdWVzdGlvbiBvZiB3aGF0IGlzIGFwcHJvcHJpYXRl IGluIGNlcnRhaW4gc2l0dWF0aW9uLCBvciB0aGUgdW5pcXVlIGF0dGFjayB2ZWN0b3JzIG9mIGlu ZGl2aWR1YWwgZGVwbG95bWVudHMuIEl0IGlzIGFib3V0IGhvdyB3ZSB0YWxrIGFib3V0IHNlY3Vy aXR5LCBhbmQgaG93IHRvIGJlc3QgcHVzaCB0aGUgd2ViIHRvd2FyZHMgYmV0dGVyIHNlY3VyaXR5 IHdpdGhvdXQgcHVzaGluZyB0b28gaGFyZCB0b28gZmFzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gbWUsIHRoZSBjaGFs bGVuZ2UgaXMgaG93IHRvIGVmZmVjdGl2ZWx5IGNvbW11bmljYXRlIHRoZSBpc3N1ZSwgd2l0aG91 dCBmb3JjaW5nIGNvbXBhbmllcyB0byBrbm93aW5nbHkgdmlvbGF0ZSB0aGUgc3BlY2lmaWNhdGlv bi4gVGhlIHByb2JsZW0gd2l0aCB0aGF0IGlzIHRoYXQgZXhwZXJpZW5jZSBzaG93cyBpdOKAmXMg YSBzbGlwcGVyeSBzbG9wZS4gT25jZSB5b3UgYXJlIG5vIGxvbmdlciBmdWxseSBjb21wbGlhbnQs IGl0IGlzIGVhc2llciB0byBsZXQgb3RoZXIgTVVTVHMgc2xpZGUuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIHRoZSBjb25z dW1lciB3ZWIgc3BhY2Ug4oCTIHdoaWNoIG9yaWdpbmF0ZWQgYW5kIGlzIHN0aWxsIHRoZSBwcmlt YXJ5IGF1ZGllbmNlIGZvciB0aGlzIHdvcmsgKG5vIG1hdHRlciBob3cgbXVjaCB0aGUgZW50ZXJw cmlzZSBmb2xrcyBoZXJlIHByb3Rlc3QpIOKAkyBlbmZvcmNpbmcgc3VjaCBhIHJlcXVpcmVtZW50 IG9uIGNsaWVudCBkZXZlbG9wZXJzIGlzIGltcHJhY3RpY2FsLiBWZXJ5IGZldyBwcm92aWRlcnMg Y2FuIGFmZm9yZCB0byBhbGllbmF0ZSB0aGVpciBkZXZlbG9wZXJzIGJ5IG1ha2luZyBzdWNoIGEg cmVxdWlyZW1lbnQgdG9kYXkuIEl0IHdpbGwgYWxzbyBjb21wbGV0ZWx5IHVuZG8gYWxsIHRoZSBv dGhlciB3b3JrIGRvbmUgdG8gbWFrZSB0aGlzIHNwZWNpZmljYXRpb24gbW9yZSBhY2Nlc3NpYmxl IGFuZCBlYXNpZXIgdG8gZGVwbG95LiBIYW5kcyBkb3duLCBkZXBsb3lpbmcgc2VydmVyLXNpZGUg VExTIGlzIG11Y2ggaGFyZGVyIGZvciBjbGllbnQgZGV2ZWxvcGVycyB0aGFuIGZpZ3VyaW5nIE9B dXRoIDEuMCBzaWduYXR1cmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FSEw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj48c3Bhbj5PQXV0aCBtYWlsaW5nIGxpc3Q8 L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0 Zi5vcmc8L2E+PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_39437D50786F48B89107FEB9EED139C5hueniversecom_-- From eran@hueniverse.com Fri Apr 1 08:16:17 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356E93A68B6 for ; Fri, 1 Apr 2011 08:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jsn0sCGdVwqX for ; Fri, 1 Apr 2011 08:16:16 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 51A3D3A688C for ; Fri, 1 Apr 2011 08:16:16 -0700 (PDT) Received: (qmail 26683 invoked from network); 1 Apr 2011 15:17:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Apr 2011 15:17:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 1 Apr 2011 08:17:45 -0700 From: Eran Hammer-Lahav To: Eran Hammer-Lahav Date: Fri, 1 Apr 2011 08:17:39 -0700 Thread-Topic: [OAUTH-WG] Reques to drop section 3 Thread-Index: Acvwf/QC5X22zgc7RyS39uK1FPaRsA== Message-ID: <6A577758-B39A-490A-95D5-89F1B985F851@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465664D735@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664D735@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6A577758B39A490A95D589F1B985F851hueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Reques to drop section 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 15:16:17 -0000 --_000_6A577758B39A490A95D589F1B985F851hueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2l0aGRyYXduLiBJIGp1c3QgZG9uJ3QgY2FyZSBlbm91Z2ggdG8gd2FzdGUgYW55IG1vcmUgdGlt ZSBvbiB0aGlzLiBJJ2xsIHdhaXQgZm9yIHRoZSByZXZpc2VkIHRleHQgYXNzaWduZWQgYXQgdGhl IG1lZXRpbmcgYW5kIHdpbGwgaW50ZWdyYXRlIGF0IHRoZSBkaXJlY3Rpb24gb2YgdGhlIGNoYWly cy4NCg0KRUhMDQoNCk9uIEFwciAxLCAyMDExLCBhdCAyOjE0LCAiRXJhbiBIYW1tZXItTGFoYXYi IDxlcmFuQGh1ZW5pdmVyc2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPj4gd3JvdGU6 DQoNClRoZXJlIHdhcyAoc3RpbGwgaXMpIGEgbG9uZyBoZWF0ZWQgZGViYXRlIGF0IHRoZSBXRyBt ZWV0aW5nIHRvZGF5IGFib3V0IGNsaWVudCBhdXRoZW50aWNhdGlvbiBhbmQgdGhlIGRyb3BwZWQg Y2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBzZWN0aW9uLiBJIHdhbnQgdG8gcmVwZWF0IG15 IHBhc3QgdmlldyAoYW5kIHRoaXMgdGltZSBwb3N0IGl0IGFzIGFuIG9wZW4gaXNzdWUpLCB0aGF0 IHRoaXMgZW50aXJlIHNlY3Rpb24gbWFrZXMgbm8gc2Vuc2UgaW4gdGhpcyBkb2N1bWVudC4gT0F1 dGggc2hvdWxkIG5vdCBiZSBkZWZpbmluZyBoYWNraXNoIEhUVFAgYXV0aGVudGljYXRpb24gc2No ZW1lcywgZXNwZWNpYWxseSBvbmVzIG5vdCB1c2luZyB0aGUgUkZDMjYxNyBmcmFtZXdvcmsuDQoN ClNvbWVvbmUgY2FuIGVhc2lseSByZWdpc3RlciB0aGUgY2xpZW50X3Bhc3N3b3JkIHBhcmFtZXRl ciBhcyBhbiBleHRlbnNpb24gKGl04oCZcyBhIG5hc3R5IGhhY2sgYnV0IEkgd29u4oCZdCBzdGFu ZCBpbiBpdHMgd2F5KSwgYXMgd2VsbCBhcyBhbnkgb3RoZXIgcG9vcmx5IGRlc2lnbiBjbGllbnQg YXV0aGVudGljYXRpb24gc2NoZW1lIHVzaW5nIGZvcm0tZW5jb2RlZCBwYXJhbWV0ZXJzIHRvIGF1 dGhlbnRpY2F0aW9uIGFuIEhUVFAgcmVxdWVzdOKApg0KDQpTbyDigJMgSSB3YW50IHRvIHNlZSBz ZWN0aW9uIDMgdHVybmVkIGludG8gYSBicmllZiBkaXNjdXNzaW9uIGFib3V0IGNsaWVudCBhdXRo ZW50aWNhdGlvbiB3aGljaCBnaXZlcyBIVFRQIEJhc2ljIGF1dGggYXMgYW4gZXhhbXBsZSBhbmQg bm90aGluZyBlbHNlLiBDbGllbnQgYXV0aGVudGljYXRpb24gaXMgYWxyZWFkeSA5NSUgb3V0IG9m IHNjb3BlLg0KDQpFSEwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_6A577758B39A490A95D589F1B985F851hueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5XaXRoZHJhd24uIEkganVzdCBkb24n dCBjYXJlIGVub3VnaCB0byB3YXN0ZSBhbnkgbW9yZSB0aW1lIG9uIHRoaXMuIEknbGwgd2FpdCBm b3IgdGhlIHJldmlzZWQgdGV4dCBhc3NpZ25lZCBhdCB0aGUgbWVldGluZyBhbmQgd2lsbCBpbnRl Z3JhdGUgYXQgdGhlIGRpcmVjdGlvbiBvZiB0aGUgY2hhaXJzLiZuYnNwOzwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+RUhMPGJyPjxicj5PbiBBcHIgMSwgMjAxMSwgYXQgMjoxNCwgIkVyYW4gSGFt bWVyLUxhaGF2IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5A aHVlbml2ZXJzZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZXJlIHdhcyAoc3RpbGwgaXMpIGEgbG9uZyBoZWF0ZWQgZGViYXRl IGF0IHRoZSBXRyBtZWV0aW5nIHRvZGF5IGFib3V0IGNsaWVudCBhdXRoZW50aWNhdGlvbiBhbmQg dGhlIGRyb3BwZWQgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBzZWN0aW9uLiBJIHdhbnQg dG8gcmVwZWF0IG15IHBhc3QgdmlldyAoYW5kIHRoaXMgdGltZSBwb3N0IGl0IGFzIGFuIG9wZW4g aXNzdWUpLCB0aGF0IHRoaXMgZW50aXJlIHNlY3Rpb24gbWFrZXMgbm8gc2Vuc2UgaW4gdGhpcyBk b2N1bWVudC4gT0F1dGggc2hvdWxkIG5vdCBiZSBkZWZpbmluZyBoYWNraXNoIEhUVFAgYXV0aGVu dGljYXRpb24gc2NoZW1lcywgZXNwZWNpYWxseSBvbmVzIG5vdCB1c2luZyB0aGUgUkZDMjYxNyBm cmFtZXdvcmsuPG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZW9uZSBjYW4gZWFzaWx5IHJlZ2lzdGVy IHRoZSBjbGllbnRfcGFzc3dvcmQgcGFyYW1ldGVyIGFzIGFuIGV4dGVuc2lvbiAoaXTigJlzIGEg bmFzdHkgaGFjayBidXQgSSB3b27igJl0IHN0YW5kIGluIGl0cyB3YXkpLCBhcyB3ZWxsIGFzIGFu eSBvdGhlciBwb29ybHkgZGVzaWduIGNsaWVudCBhdXRoZW50aWNhdGlvbiBzY2hlbWUgdXNpbmcg Zm9ybS1lbmNvZGVkIHBhcmFtZXRlcnMgdG8gYXV0aGVudGljYXRpb24gYW4gSFRUUCByZXF1ZXN0 4oCmPG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28g4oCTIEkgd2FudCB0byBzZWUgc2VjdGlvbiAzIHR1 cm5lZCBpbnRvIGEgYnJpZWYgZGlzY3Vzc2lvbiBhYm91dCBjbGllbnQgYXV0aGVudGljYXRpb24g d2hpY2ggZ2l2ZXMgSFRUUCBCYXNpYyBhdXRoIGFzIGFuIGV4YW1wbGUgYW5kIG5vdGhpbmcgZWxz ZS4gQ2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIGFscmVhZHkgOTUlIG91dCBvZiBzY29wZS48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBj bGFzcz0iTXNvTm9ybWFsIj5FSEw8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVv dGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+T0F1dGggbWFpbGlu ZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9B dXRoQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+ PC9odG1sPg== --_000_6A577758B39A490A95D589F1B985F851hueniversecom_-- From bcampbell@pingidentity.com Fri Apr 1 08:36:17 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4AD3A68BA for ; Fri, 1 Apr 2011 08:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.577 X-Spam-Level: X-Spam-Status: No, score=-5.577 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJKLXvVTMu2f for ; Fri, 1 Apr 2011 08:36:16 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with ESMTP id F196E3A6889 for ; Fri, 1 Apr 2011 08:36:15 -0700 (PDT) Received: from source ([209.85.161.50]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTZXxU+XRT+KGVwTfh0i8YW9i/sXwS8/V@postini.com; Fri, 01 Apr 2011 08:37:56 PDT Received: by mail-fx0-f50.google.com with SMTP id 16so2826926fxm.9 for ; Fri, 01 Apr 2011 08:37:55 -0700 (PDT) Received: by 10.223.66.70 with SMTP id m6mr2536601fai.34.1301672275124; Fri, 01 Apr 2011 08:37:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.70.198 with HTTP; Fri, 1 Apr 2011 08:37:25 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252C462C@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4718054E-15B8-4FD9-8C8F-2633A943F1A6@gmx.net> <4E1F6AAD24975D4BA5B1680429673943252C462C@TK5EX14MBXC203.redmond.corp.microsoft.com> From: Brian Campbell Date: Fri, 1 Apr 2011 09:37:25 -0600 Message-ID: To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Agenda Update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 15:36:17 -0000 Sadly, I am not in Prague. Given the similarities between the JWT and SAML grant drafts, please let me know if anything substantial comes out of the JWT discussions. Thanks! On Thu, Mar 31, 2011 at 3:05 PM, Mike Jones w= rote: > To this, I'd like to add discussion of draft-jones-oauth-jwt-bearer -- th= e JWT equivalent of draft-ietf-oauth-saml2-bearer. =A0In specific, I'd like= us to consider taking this up as a working group item. > > Thanks and see you in the morning! > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Hannes Tschofenig > Sent: Thursday, March 31, 2011 12:13 PM > To: OAuth WG > Subject: [OAUTH-WG] Agenda Update > > After a chat with Blaine we have an updated agenda proposal: > > First, we need to cover our working group items: > > -draft-ietf-oauth-v2 > *Security Consideration Section (Torsten) *Error Code registry (Mike) *Cl= ient Assertion Credentials (Mike) *Anything else? > -draft-ietf-oauth-v2-bearer > *Open issues? > -draft-ietf-oauth-saml2-bearer > *Open issues? > > Then, we jump into the presentations of the individual submissions: > > *OAuth Security (Torsten) > *JSON Web Token (Mike) > *Use Cases (Zachary) > *Simple Web Discovery (Mike) > *Dynamic Client Registration (Thomas, if time permits) *Token Revocation = (Torsten, if time permits) *Chain Grant Type (Hannes on behalf of Phil, if = time permits) > > Then, we will solicit your feedback on the rechartering. The feedback fro= m the presentations earlier will be taken into consideration. > > Hope that works for you! > > Ciao > Hannes & Blaine > > > > _______________________________________________ > OAuth mailing 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 fcorella@pomcor.com Fri Apr 1 09:20:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0DE3A68C0 for ; Fri, 1 Apr 2011 09:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOmBdfSuDsqO for ; Fri, 1 Apr 2011 09:20:54 -0700 (PDT) Received: from web55801.mail.re3.yahoo.com (web55801.mail.re3.yahoo.com [216.252.110.47]) by core3.amsl.com (Postfix) with SMTP id 44BE43A6870 for ; Fri, 1 Apr 2011 09:20:54 -0700 (PDT) Received: (qmail 12189 invoked by uid 60001); 1 Apr 2011 16:22:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301674952; bh=rSoofPXBaZBvy5/PxmuJnzx34bAGStW5UqwFcY5Uddo=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1Wvt6NYprkkK0kMaZCWMtNU+2RmVeKtzmHhmUppcOa0eT8X0vCdBx/QgaIa9k2n/s5Krt7HshDAjyttPpHm+ofk1UCePK3i1Ev9zj2W6ShVWztT3q17roX6qNBsN80xr2+2KQocBmMJuXnHjXkzy2ebl5IGQZxkO669I/HfQuIA= Message-ID: <754693.84979.qm@web55801.mail.re3.yahoo.com> X-YMail-OSG: bKOmTUUVM1lUZ2BAprhLxn.SdH_bVL_n1QAdAAnZqeJlEcT fbU75d8U1tZAMFSunGnwevEG1NfwpGqOIwmvxel5JMVRwwkBZ4.yHsrCIiDK WVnl3YgVJv0iaItWmukWuTxUfz62vFiRPem1o2OILBKon1Ej_tuG.rOwwxyo aHgpiSEbkop6Mtbt1s6GE5BD5R6r9KASwEe9jmFtQwTKtTMcffd4OEgGJyPR Uod_SBfczHMXAlhiArgGAfEYAol7xUR.ZwicHipRSooeoLQCAPFXgRqZFZvD pBVS2pW0EE.kVPWTnWfvc1FKMaTWDT_wLdKz4NlUttT_73U7EH8pbZd6BF04 f4RSYgcU99I0mUTsfmX.Fx5IbHph1RN4tO46ELx9OG3YV6Z_1IErlUdtY1xr XZVgC Received: from [67.91.91.101] by web55801.mail.re3.yahoo.com via HTTP; Fri, 01 Apr 2011 09:22:32 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Fri, 1 Apr 2011 09:22:32 -0700 (PDT) From: Francisco Corella To: Eran Hammer-Lahav , Mark Mcgloin In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-606531522-1301674952=:84979" Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 16:20:56 -0000 --0-606531522-1301674952=:84979 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > So we have 2 different communities of Oauth developers that > will never agree. >=20 > SHOULD: Typically the social networking sites that need to > cater for tail end developers by not enforcing TLS on > redirect_uri. It is a risk to think that using strong > language in the spec will help them appreciate the issues > MUST: Typically enterprise organisations (I am in this > camp). They can enforce indirectly by only supporting > registered callback urls and ensure those use TLS Security is at least as necessary to social networking sites as to enterprise sites.=A0 Think about what this means for Facebook.=A0 If you are using Wifi in a cafe and use the Facebook login button to log in to any application, a hacker can easily impersonate you. By the way, is somebody from Facebook reading this?=A0 If so, this is a vulnerability that Facebook has right now, and you should do something about it.=A0 At the very least you should change the examples of redirect URIs in the developer documentation so that they use https rather than http. Francisco --0-606531522-1301674952=:84979 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
> So we have 2 different communities of Oa= uth developers that
> will never agree.
>
> SHOULD: Typi= cally the social networking sites that need to
> cater for tail end d= evelopers by not enforcing TLS on
> redirect_uri. It is a risk to thi= nk that using strong
> language in the spec will help them appreciate= the issues
> MUST: Typically enterprise organisations (I am in this<= br>> camp). They can enforce indirectly by only supporting
> regis= tered callback urls and ensure those use TLS

Security is at least as= necessary to social networking sites
as to enterprise sites.  Thin= k about what this means for
Facebook.  If you are using Wifi in a c= afe and use the
Facebook login button to log in to any application, a ha= cker
can easily impersonate you.

By the way, is somebody from Facebook reading this?  If so,
this is a vulnerability that Facebo= ok has right now, and you
should do something about it.  At the ver= y least you should
change the examples of redirect URIs in the developer=
documentation so that they use https rather than http.

Francisco=

--0-606531522-1301674952=:84979-- From wmills@yahoo-inc.com Fri Apr 1 10:20:17 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15DA3A679F for ; Fri, 1 Apr 2011 10:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr8+5prDtRsR for ; Fri, 1 Apr 2011 10:20:16 -0700 (PDT) Received: from web32314.mail.mud.yahoo.com (web32314.mail.mud.yahoo.com [68.142.207.162]) by core3.amsl.com (Postfix) with SMTP id 5D72F3A6765 for ; Fri, 1 Apr 2011 10:20:16 -0700 (PDT) Received: (qmail 28806 invoked by uid 60001); 1 Apr 2011 17:21:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1301678511; bh=+crcFHI4rGaRqWp65vJy71virDw/R2eU6+elwfKPUKk=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=g0ciLpmTNcbhs3OQmIkDBUw4iGKa/mWub7Wr0iy2HlAAfTFu0vN0DbnePSzl1OZLYnmmxjOJB2VGcJiNP7sfexrN4e9jQ+z3LsZbWslMqHotF6/sch/dX4hY2mcb5DklkQLZrFdWv9MlJ6wjvR+ByRI4B1lgG9Mr11H/yRLp390= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=MOEUggUdnIFyQ7NZyojidMo6hYc10PQsTemjdk/9H+2yDPMaFyfBfYFx15hO5PpM4XRt8vZH+mOgNdnK1k3fwZzWP3V9Ni8n0tI1Y+7edQzHh4geUY8fI/UHmsrJoWGY4RE+AbQqTmQuOtzPslAsU7QKbMxW4DfFfxmjK+qzriE=; Message-ID: <658267.92293.qm@web32314.mail.mud.yahoo.com> X-YMail-OSG: wg55ofsVM1kV8_JECcdLAxUftMWxYouADpJGie25LEJj_rk dEgx5cpN1XGh8w.O8L9GqTbd4ZriWyaSN2C_AEPRCSvHJir_gLtPE5c7qN2S 8dOmPGBAwYbgg2IbjAF5QDsef2mahx4Wq4CufPuINIYoxErcNYgljaziwwfJ dKI6sDExtap5FaSLhl5LugnJsaOASnKL3zk6xc1xwxlIYliXPD464.JVqrPu fBEFe2CZQSgaucyxyRTJtIdrsbrT9gs90k.xyRzFaOfrUkc.Z6AbCsPxpAUC ghwrRBbr5q8cozw3abQE85CTBAbVTl33zAejMAXvgdz9cd8k_.SSlfjnBrHm pzzxs04rnSS5c_SjpOM9qiA-- Received: from [99.31.212.42] by web32314.mail.mud.yahoo.com via HTTP; Fri, 01 Apr 2011 10:21:51 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <90C41DD21FB7C64BB94121FBBC2E7234465664D735@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 1 Apr 2011 10:21:51 -0700 (PDT) From: "William J. Mills" To: "Richer, Justin P." , Eran Hammer-Lahav , OAuth WG In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-503663878-1301678511=:92293" Subject: Re: [OAUTH-WG] Reques to drop section 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 17:20:17 -0000 --0-503663878-1301678511=:92293 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree with Justin.=0A=0A=0A________________________________=0AFrom: "Rich= er, Justin P." =0ATo: Eran Hammer-Lahav ; OAuth WG =0ASent: Friday, April 1, 2011 5:18 AM=0ASu= bject: Re: [OAUTH-WG] Reques to drop section 3=0A=0A-1 once again=0A=0AI wa= nt to keep the client password mechanism in core as it reflects the way tha= t most (nearly all in my personal experience) client implementations pass t= heir auth parameters today. I do think that the assertion credentials could= live fine in a simple extension, though, with the same arguments as the as= sertion grant type.=0A=0A-- Justin=0A______________________________________= __=0AFrom: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Era= n Hammer-Lahav [eran@hueniverse.com]=0ASent: Friday, April 01, 2011 5:14 AM= =0ATo: OAuth WG=0ASubject: [OAUTH-WG] Reques to drop section 3=0A=0AThere w= as (still is) a long heated debate at the WG meeting today about client aut= hentication and the dropped client assertion credentials section. I want to= repeat my past view (and this time post it as an open issue), that this en= tire section makes no sense in this document. OAuth should not be defining = hackish HTTP authentication schemes, especially ones not using the RFC2617 = framework.=0A=0ASomeone can easily register the client_password parameter a= s an extension (it=E2=80=99s a nasty hack but I won=E2=80=99t stand in its = way), as well as any other poorly design client authentication scheme using= form-encoded parameters to authentication an HTTP request=E2=80=A6=0A=0ASo= =E2=80=93 I want to see section 3 turned into a brief discussion about cli= ent authentication which gives HTTP Basic auth as an example and nothing el= se. Client authentication is already 95% out of scope.=0A=0AEHL=0A_________= ______________________________________=0AOAuth mailing list=0AOAuth@ietf.or= g=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-503663878-1301678511=:92293 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I agree wi= th Justin.

From:<= /span> "Richer, Justin P." <jricher@mitre.org>
To: Eran Hammer-Lahav <eran@huenivers= e.com>; OAuth WG <oauth@ietf.org>
Sent: Friday, April 1, 2011 5:18 AM
Subject: Re: [OAUTH-WG] Reques to drop s= ection 3

=0A-1 once again

I want to keep the client pa= ssword mechanism in core as it reflects the way that most (nearly all in my= personal experience) client implementations pass their auth parameters tod= ay. I do think that the assertion credentials could live fine in a simple e= xtension, though, with the same arguments as the assertion grant type.
<= br> -- Justin
________________________________________
From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf= Of Eran Hammer-Lahav [eran@hueniverse.com]
Sent: Friday, April 0= 1, 2011 5:14 AM
To: OAuth WG
Subject: [OAUTH-WG] Reques to drop secti= on 3

There was (still is) a long heated debate at the WG meeting tod= ay about client authentication and the dropped client assertion credentials section. I want to repeat my = past view (and this time post it as an open issue), that this entire sectio= n makes no sense in this document. OAuth should not be defining hackish HTT= P authentication schemes, especially ones not using the RFC2617 framework.<= br>
Someone can easily register the client_password parameter as an exte= nsion (it=E2=80=99s a nasty hack but I won=E2=80=99t stand in its way), as = well as any other poorly design client authentication scheme using form-enc= oded parameters to authentication an HTTP request=E2=80=A6

So =E2=80= =93 I want to see section 3 turned into a brief discussion about client aut= hentication which gives HTTP Basic auth as an example and nothing else. Cli= ent authentication is already 95% out of scope.

EHL
_____________= __________________________________
OAuth mailing list
OAuth@ietf.org
= htt= ps://www.ietf.org/mailman/listinfo/oauth


<= /body> --0-503663878-1301678511=:92293-- From mscurtescu@google.com Fri Apr 1 10:24:47 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED913A679F for ; Fri, 1 Apr 2011 10:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG1zY5xpm4cM for ; Fri, 1 Apr 2011 10:24:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 1BFBD3A6765 for ; Fri, 1 Apr 2011 10:24:45 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p31HQPJf015907 for ; Fri, 1 Apr 2011 10:26:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301678786; bh=gnlXXacslVTCZySJEs8Ax63Kr6s=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=jJG5RxchdRm7Ut/cBCNGwXu+c7/tP530tVwiDg2vEfXAvXzR5eqI2l0QZ0E99m3Kt 28w+yLWoRGXWUHczOpojg== Received: from yxt33 (yxt33.prod.google.com [10.190.5.225]) by kpbe15.cbf.corp.google.com with ESMTP id p31HQNIM016508 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 1 Apr 2011 10:26:23 -0700 Received: by yxt33 with SMTP id 33so1814793yxt.0 for ; Fri, 01 Apr 2011 10:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=xAvt1WA+63POJ5zJyWcmISBwu3yH3UpGxw3PDiqtN6g=; b=xYWARiyJhEY5QC1H5JLNjOj6BJ1WyoHmjRzQzk2wCHxmLHYrbFmyDJv3CRxg1Ub9Zm XsE0/7FdJejPDOROx6wQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=BpyCstiA88YyFRCz6Ma0xqFMHHYusOoJvq2D9ePINrf0XkTktKj4Ect9NsbcUC4bGW n4gf+BZQui83mCkeACnQ== Received: by 10.101.206.10 with SMTP id i10mr3172304anq.82.1301678783121; Fri, 01 Apr 2011 10:26:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.34.4 with HTTP; Fri, 1 Apr 2011 10:26:03 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252C5D8F@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943252C5D8F@TK5EX14MBXC203.redmond.corp.microsoft.com> From: Marius Scurtescu Date: Fri, 1 Apr 2011 10:26:03 -0700 Message-ID: To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Reques to drop section 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 17:24:47 -0000 What Mike said. Definitely keep section 3 and I would really like to see the client assertion section restored. Glad to hear there is some progress on that front. Marius On Fri, Apr 1, 2011 at 6:19 AM, Mike Jones wr= ote: > Also -1 on dropping section 3. =A0Rather, we need to restore the client a= ssertion credentials to 3, per the outcome of the discussion at today's wor= king group meeting. =A0I'm glad that we're headed in that direction. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Richer, Justin P. > Sent: Friday, April 01, 2011 5:19 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Reques to drop section 3 > > -1 once again > > I want to keep the client password mechanism in core as it reflects the w= ay that most (nearly all in my personal experience) client implementations = pass their auth parameters today. I do think that the assertion credentials= could live fine in a simple extension, though, with the same arguments as = the assertion grant type. > > =A0-- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran H= ammer-Lahav [eran@hueniverse.com] > Sent: Friday, April 01, 2011 5:14 AM > To: OAuth WG > Subject: [OAUTH-WG] Reques to drop section 3 > > There was (still is) a long heated debate at the WG meeting today about c= lient authentication and the dropped client assertion credentials section. = I want to repeat my past view (and this time post it as an open issue), tha= t this entire section makes no sense in this document. OAuth should not be = defining hackish HTTP authentication schemes, especially ones not using the= RFC2617 framework. > > Someone can easily register the client_password parameter as an extension= (it's a nasty hack but I won't stand in its way), as well as any other poo= rly design client authentication scheme using form-encoded parameters to au= thentication an HTTP request... > > So - I want to see section 3 turned into a brief discussion about client = authentication which gives HTTP Basic auth as an example and nothing else. = Client authentication is already 95% out of scope. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From fcorella@pomcor.com Fri Apr 1 10:25:27 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FDF83A679F for ; Fri, 1 Apr 2011 10:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB5szT53Lqbb for ; Fri, 1 Apr 2011 10:25:26 -0700 (PDT) Received: from web55801.mail.re3.yahoo.com (web55801.mail.re3.yahoo.com [216.252.110.47]) by core3.amsl.com (Postfix) with SMTP id 395D33A6765 for ; Fri, 1 Apr 2011 10:25:26 -0700 (PDT) Received: (qmail 80924 invoked by uid 60001); 1 Apr 2011 17:27:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301678823; bh=4xiZmSNlGvfyLsOozFUVpeu8r4RZUIr/EQDmCb88gLU=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PyAUSO1nq0oDtxntRhS+wjSTFbvIR32RK2k3NRjEcI5I5ZnJL6VrRXul1oZ3ntR0bz5fXjdyDVAhdZ0iDV4hgboeF+s9h/APyDBtxjc7KLBQRHSIBfoBRiZVsQZ21SpIlx/cf6xj5kDln22LcZ1NE/Y5JmbHDmuC1hWnBr+be6A= Message-ID: <950156.69518.qm@web55801.mail.re3.yahoo.com> X-YMail-OSG: 1_3AZKAVM1lfJetVSny3lSod.VrHrKFjKN8khrm05ri3Ou9 c4I80oGT99uRSExlgmhS5_wX1oCD5oWvx9OXX8oU0GcTqNpmp2t_VQygYp.R 5tapjnD76jdDVO70vQEJrD7XB7FDBCCyFyQDo.rNakEKd2gTJNnWVKPzj16j irHc.putjnBP881kk7XLGwCdY7HdyEffY3DNPB6aej8tcTfmDe1Lo9XrxiMj .Ijk5H7RY_dMetHImf09a3zQHcjjrsOZ5AFC72oswWwps9I.d1sgpNAnyhdZ VfHCGhqKC0_v2_bewzJXyWXgRr_3EIcAzt1jFq2wAVV7l2yQSIzhIrwCLXzy 3W1tkSYZvi2kcG2aPobGZjE2YLWwVwq4LKB4G4403vKlJsVJikmmO8bwjN3o Jw8YPXe2_EIA- Received: from [67.91.91.101] by web55801.mail.re3.yahoo.com via HTTP; Fri, 01 Apr 2011 10:27:02 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Fri, 1 Apr 2011 10:27:02 -0700 (PDT) From: Francisco Corella To: Skylar Woodward In-Reply-To: <5D31024C-1CBE-46E0-8074-6BD8F5157DE7@kiva.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-234490418-1301678822=:69518" Cc: OAuth WG , "Karen P. Lewison" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 17:25:27 -0000 --0-234490418-1301678822=:69518 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Skylar, > Francisco, correct me if I'm wrong, but in your discussion > you assume that the application is incapable of keeping > secrets from the public (eg, mobile, desktop apps, etc.). > According to the spec, those applications should never > receive client credentials to begin with.=A0 They can't keep > secrets so they aren't issued any. Obfuscating secrets in > binary code doesn't count - if the tokens in question are > outside a secured firewall, they aren't secrets. No, the application can be a traditional Web application with a client secret. > George's attack is a MITM attack which can be expensive or > difficult to pull off, but a possibility. At the least, it's > a security consideration of why a callback *should* use TLS. George's attack, and the ones I've been discussing, are easy to set up using hacker tools that can downloaded for free from the Web.=A0 When I first reported the issue back on January 3 I made an effort to explain how easy an attack can be.=A0 See the message: http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html The attack scenario described in that message is slightly different from those discussed lately, but the practicality considerations are the same as for all the MITM attacks that have been discussed. > Someone speak up if George's scenario is flawed or I'm > misunderstanding it.=A0 My understanding is this: >=20 > - Bob uses (web) client C to access provider P. > - Mallory has set up a MITM attack between client C and Bob's computer. > - Mallory also uses client to C and starts an an approval process from th= e client to provider P > - Bob sends a request over HTTPS to provider P with client ID for C. > - Provider P responds to his request with a redirect to an authentication= code. > - Meanwhile, Mallory does not continue with the auth flow at provider P. = Instead, he waits for Bob. > - Bob's browser performs the redirect sent from provider P back to client= C (over HTTP). > - Mallory intercepts the clear-text request from Bob's computer and does = not pass the request on to client C. > - Mallory uses the auth code from Bob (and any state information) to forg= e a redirect request to client C on his own session. > - Client C requests an access token from provider P for Bob's account usi= ng it's secured client credentials. > - Mallory now has credentials for Bob on client C.=A0 Bob has a dead or i= nvalid auth handshake which was interrupted by Mallory (and not passed on t= o P to avoid replay detection). I don't think this is what George said.=A0 Mallory does not to "start an approval process" at step 3. Francisco --0-234490418-1301678822=:69518 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Skylar,

> = Francisco, correct me if I'm wrong, but in your discussion
> you assu= me that the application is incapable of keeping
> secrets from the pu= blic (eg, mobile, desktop apps, etc.).
> According to the spec, those= applications should never
> receive client credentials to begin with= .  They can't keep
> secrets so they aren't issued any. Obfuscat= ing secrets in
> binary code doesn't count - if the tokens in questio= n are
> outside a secured firewall, they aren't secrets.

No, t= he application can be a traditional Web application
with a client secret= .

> George's attack is a MITM attack which can be expensive or> difficult to pull off, but a possibility. At the least, it's
> = a security consideration of why a callback *should* use TLS.

George'= s attack, and the ones I've been discussing, are easy
to set up using hac= ker tools that can downloaded for free
from the Web.  When I first = reported the issue back on
January 3 I made an effort to explain how eas= y an attack can
be.  See the message:

http://www.ietf.org/= mail-archive/web/oauth/current/msg04894.html

The attack scenario= described in that message is slightly
different from those discussed la= tely, but the practicality
considerations are the same as for all the MI= TM attacks that
have been discussed.

> Someone speak up if Geo= rge's scenario is flawed or I'm
> misunderstanding it.  My under= standing is this:
>
> - Bob uses (web) client C to access prov= ider P.
> - Mallory has set up a MITM attack between client C and Bob= 's computer.
> - Mallory also uses client to C and starts an an approval process from the client to provider P
> - Bob sends a reque= st over HTTPS to provider P with client ID for C.
> - Provider P resp= onds to his request with a redirect to an authentication code.
> - Me= anwhile, Mallory does not continue with the auth flow at provider P. Instea= d, he waits for Bob.
> - Bob's browser performs the redirect sent fro= m provider P back to client C (over HTTP).
> - Mallory intercepts the= clear-text request from Bob's computer and does not pass the request on to= client C.
> - Mallory uses the auth code from Bob (and any state inf= ormation) to forge a redirect request to client C on his own session.
&g= t; - Client C requests an access token from provider P for Bob's account us= ing it's secured client credentials.
> - Mallory now has credentials = for Bob on client C.  Bob has a dead or invalid auth handshake which w= as interrupted by Mallory (and not passed on to P to avoid replay detection).

I don't think this is what George said.  Mallory d= oes not to
"start an approval process" at step 3.

Francisco
--0-234490418-1301678822=:69518-- From fcorella@pomcor.com Fri Apr 1 10:27:41 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEC928B23E for ; Fri, 1 Apr 2011 10:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JUnrgh0jHe9 for ; Fri, 1 Apr 2011 10:27:40 -0700 (PDT) Received: from web55807.mail.re3.yahoo.com (web55807.mail.re3.yahoo.com [216.252.110.53]) by core3.amsl.com (Postfix) with SMTP id 7780B3A690C for ; Fri, 1 Apr 2011 10:27:40 -0700 (PDT) Received: (qmail 14194 invoked by uid 60001); 1 Apr 2011 17:29:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301678960; bh=QUlY/jgYI65PXbHuIXtFlYDU0ZuCAMd9RRq6QcUbEm0=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=D/Livud2VBnKcD6NPfVeyIYyYrepHgtp6BAAVnzIkjdF2SOlZ97AImSW2RF99gXQcWX2zGJnDVWK1uX/PQj6YxWubcBaPaJahPfizj4GM1zx/q1MnsnmarfYm3kl48WWTHbFjfCacWeOKiv3roiVKm4k36X7s8vefPUSZhnL+xc= Message-ID: <796881.62132.qm@web55807.mail.re3.yahoo.com> X-YMail-OSG: 4quRP4kVM1kHAAumEt.DV6NwhoGb.p3Onq17hLRUeqJ0g8Y RnXF8P7R_uvMayEFAqvnIUKWPMAJn7.rx_kuD9U8CnSvDzTdHLPIO2sE2ju1 CorcxVGR35oTkcGoSYYGw7KzLi_vy8eyI8iYipkVmb73Xd8yTtLIkaXa4cXt CHP6Kpea7ErtDoMMUfLzTsMe7gTTMdYTelOk96XMhnoTCYJw27WICGTVRDBP .npYemObepG8U5_Z173cg7TXNr3sPfjqv1fQ4U.l6r91k7ks_1k2rsILkoQG V9s62fvXSINJr2.Pc0Apf1HNop0Y4D5w8JWVNNpBP1FzHWayyYef31HzRTv. HNdp2orfaRPRLqVpGFrnSHdq4hodRQZNimB46dwrFs3PEUWRI8H455iOKkBi rB6Y_HvQ6YJ0- Received: from [67.91.91.101] by web55807.mail.re3.yahoo.com via HTTP; Fri, 01 Apr 2011 10:29:20 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Fri, 1 Apr 2011 10:29:20 -0700 (PDT) From: Francisco Corella To: Skylar Woodward In-Reply-To: <3F048A31-6B9E-4260-9E07-AECAEFE038EE@kiva.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1734775679-1301678960=:62132" Cc: "Karen P. Lewison" , OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 17:27:41 -0000 --0-1734775679-1301678960=:62132 Content-Type: text/plain; charset=us-ascii Skylar, > Right, but just so we are clear, the only case you are > discussing here is the MITM attack, which George, I and > others have recently outlined. There several flavors of MITM attacks, and a passive attack. See http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html, http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html, and the last two paragraphs of page 4 of http://pomcor.com/techreports/DoubleRedirection.pdf. Francisco --0-1734775679-1301678960=:62132 Content-Type: text/html; charset=us-ascii
Skylar,

> Right, but just so we are clear, the only case you are
> discussing here is the MITM attack, which George, I and
> others have recently outlined.

There several flavors of MITM attacks, and a passive attack.
See
http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html,
http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html,
and the last two paragraphs of page 4 of
http://pomcor.com/techreports/DoubleRedirection.pdf.

Francisco


--0-1734775679-1301678960=:62132-- From oleg_gryb@yahoo.com Fri Apr 1 10:49:43 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833F33A6904 for ; Fri, 1 Apr 2011 10:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Viauo8LeM8EV for ; Fri, 1 Apr 2011 10:49:42 -0700 (PDT) Received: from web37602.mail.mud.yahoo.com (web37602.mail.mud.yahoo.com [209.191.87.85]) by core3.amsl.com (Postfix) with SMTP id 7DC0A3A67B4 for ; Fri, 1 Apr 2011 10:49:42 -0700 (PDT) Received: (qmail 49101 invoked by uid 60001); 1 Apr 2011 17:51:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301680279; bh=FlHZr4XYWoat/IfalKABXGzjT4CcgCdZpirgC3zptKc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Z6BRFPrdGu0183DcZkXC+RQ6tnKvT5jRrLs1/REipjGzGqnHyXL3KYwXsjf2/o899nprRj8ISM71U1cB6yxbGisi2gAiokufvLNX5V33NxxCGvMOsBF0ZZkwA0xbbDMoRzTQ7f+nPOpKqlkGi19Yxd5hCPQOL57K5RjZ2KbxHBM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qa8y3gtCoTYdfw0vGcmmCgpyM6TiH3xtsfujWj27MUas5YiLv4uGhHMAD6O9g80IpEq2AZLAJGS5y7MVNvmllS5zQ/G+e954CodaBkWgKRA/TYeySuiBgqYNPy+wS2vLk+1rm9sAykHs49jzPkhfzDSYalb4uGmcIYgFEJfWPYs=; Message-ID: <555698.48529.qm@web37602.mail.mud.yahoo.com> X-YMail-OSG: kO.s_XUVM1k71D6zI_dAM4CGl6zt.cKEGfKIgTTpm0iPcsd lltDQRV2M1DTFli57wZN2U1z80XBT6NjjkruFwkalo2ZfzN5_2jrlF5Dp9P0 ZLwCFxw0sM4fMi9of_Akt1Hm.G7ULDH1dRHab2jIJF9_x7tWOtGpFGrWuq3g fLiPaW0MeLh0LMpR63L.Jk_lMmdMix973lCUiSbfg7F1hlELvdqIsV3zUnvj MIsQLKd8_iLGIuF0MDoDu8aaTX0XtYtv1JukJGZRaqSnYjfkqLxrdxiyXc0i edvptO9m9wjUPeKJ0Emx1SIfKdMvWr0OFVYAoYixPUTlzEETTi3uHz7goDZO 1cvcFscBeYE1QxajQdRUZGtKg8XqsNFDmqpaF8nssgEDJ18kDb.zUDP0- Received: from [208.240.243.170] by web37602.mail.mud.yahoo.com via HTTP; Fri, 01 Apr 2011 10:51:19 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <754693.84979.qm@web55801.mail.re3.yahoo.com> Date: Fri, 1 Apr 2011 10:51:19 -0700 (PDT) From: Oleg Gryb To: fcorella@pomcor.com, Eran Hammer-Lahav , Mark Mcgloin In-Reply-To: <754693.84979.qm@web55801.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2103004017-1301680279=:48529" Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 17:49:43 -0000 --0-2103004017-1301680279=:48529 Content-Type: text/plain; charset=us-ascii It's a very interesting discussion and I think, I understand both parties well because consider myself belonging to both communities (enterprise and networking). Still, I would vote in favor of MUST. Considering the big size of this mailing list and the big level of engagement of its members, why don't we vote? The results of the vote should be taken into consideration by those who writes the final version. > >From: Francisco Corella >To: Eran Hammer-Lahav ; Mark Mcgloin > >Cc: OAuth WG ; oauth-bounces@ietf.org >Sent: Fri, April 1, 2011 9:22:32 AM >Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) > > >> So we have 2 different communities of Oauth developers that >> will never agree. >> >> SHOULD: Typically the social networking sites that need to >> cater for tail end developers by not enforcing TLS on >> redirect_uri. It is a risk to think that using strong >> language in the spec will help them appreciate the issues >> MUST: Typically enterprise organisations (I am in this >> camp). They can enforce indirectly by only supporting >> registered callback urls and ensure those use TLS > >Security is at least as necessary to social networking sites >as to enterprise sites. Think about what this means for >Facebook. If you are using Wifi in a cafe and use the >Facebook login button to log in to any application, a hacker >can easily impersonate you. > >By the way, is somebody from Facebook reading this? If so, >this is a vulnerability that Facebook has right now, and you >should do something about it. At the very least you should >change the examples of redirect URIs in the developer >documentation so that they use https rather than http. > >Francisco > > --0-2103004017-1301680279=:48529 Content-Type: text/html; charset=us-ascii
It's a very interesting discussion and I think, I understand both parties well because consider myself belonging to both communities (enterprise and networking). Still, I would vote in favor of MUST.

Considering the big size of this mailing list and the big level of engagement of its members, why don't we vote?

The results of the vote should be taken into consideration by those who writes the final version.

From: Francisco Corella <fcorella@pomcor.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>; Mark Mcgloin <mark.mcgloin@ie.ibm.com>
Cc: OAuth WG <oauth@ietf.org>; oauth-bounces@ietf.org
Sent: Fri, April 1, 2011 9:22:32 AM
Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)

> So we have 2 different communities of Oauth developers that
> will never agree.
>
> SHOULD: Typically the social networking sites that need to
> cater for tail end developers by not enforcing TLS on
> redirect_uri. It is a risk to think that using strong
> language in the spec will help them appreciate the issues
> MUST: Typically enterprise organisations (I am in this
> camp). They can enforce indirectly by only supporting
> registered callback urls and ensure those use TLS

Security is at least as necessary to social networking sites
as to enterprise sites.  Think about what this means for
Facebook.  If you are using Wifi in a cafe and use the
Facebook login button to log in to any application, a hacker
can easily impersonate you.

By the way, is somebody from Facebook reading this?  If so,
this is a vulnerability that Facebook has right now, and you
should do something about it.  At the very least you should
change the examples of redirect URIs in the developer
documentation so that they use https rather than http.

Francisco

--0-2103004017-1301680279=:48529-- From phil.hunt@oracle.com Fri Apr 1 11:11:32 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0CB3A690D; Fri, 1 Apr 2011 11:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSABxaj6MLLa; Fri, 1 Apr 2011 11:11:24 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5C9F03A6911; Fri, 1 Apr 2011 11:11:23 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p31ICvp6021287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2011 18:12:59 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p31ICuoK002685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2011 18:12:56 GMT Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p31ICuIq013402; Fri, 1 Apr 2011 13:12:56 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Apr 2011 11:12:55 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-23--895657161 From: Phil Hunt In-Reply-To: <555698.48529.qm@web37602.mail.mud.yahoo.com> Date: Fri, 1 Apr 2011 11:12:53 -0700 Message-Id: <0095016D-7603-49D3-9E35-B1AA16C86E35@oracle.com> References: <754693.84979.qm@web55801.mail.re3.yahoo.com> <555698.48529.qm@web37602.mail.mud.yahoo.com> To: Oleg Gryb X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4D9615A9.00E3:SCFSTAT5015188,ss=1,fgs=0 Cc: oauth-bounces@ietf.org, OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 18:11:35 -0000 --Apple-Mail-23--895657161 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Unfortunately neither solution suggested so far is acceptable. So a vote = from my perspective is premature. I'd like to keep working for a new solution. Phil phil.hunt@oracle.com On 2011-04-01, at 10:51 AM, Oleg Gryb wrote: > It's a very interesting discussion and I think, I understand both = parties well because consider myself belonging to both communities = (enterprise and networking). Still, I would vote in favor of MUST. >=20 > Considering the big size of this mailing list and the big level of = engagement of its members, why don't we vote? >=20 > The results of the vote should be taken into consideration by those = who writes the final version. >=20 > From: Francisco Corella > To: Eran Hammer-Lahav ; Mark Mcgloin = > Cc: OAuth WG ; oauth-bounces@ietf.org > Sent: Fri, April 1, 2011 9:22:32 AM > Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) >=20 > > So we have 2 different communities of Oauth developers that > > will never agree. > >=20 > > SHOULD: Typically the social networking sites that need to > > cater for tail end developers by not enforcing TLS on > > redirect_uri. It is a risk to think that using strong > > language in the spec will help them appreciate the issues > > MUST: Typically enterprise organisations (I am in this > > camp). They can enforce indirectly by only supporting > > registered callback urls and ensure those use TLS >=20 > Security is at least as necessary to social networking sites > as to enterprise sites. Think about what this means for > Facebook. If you are using Wifi in a cafe and use the > Facebook login button to log in to any application, a hacker > can easily impersonate you. >=20 > By the way, is somebody from Facebook reading this? If so, > this is a vulnerability that Facebook has right now, and you > should do something about it. At the very least you should > change the examples of redirect URIs in the developer > documentation so that they use https rather than http. >=20 > Francisco >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-23--895657161 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 2011-04-01, at 10:51 AM, Oleg Gryb wrote:

It's a = very interesting discussion and I think, I understand both parties well = because consider myself belonging to both communities (enterprise and = networking). Still, I would vote in favor of MUST.

Considering = the big size of this mailing list and the big level of engagement of its = members, why don't we vote?

The results of the vote should be = taken into consideration by those who writes the final = version.

From: Francisco Corella <fcorella@pomcor.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>; Mark = Mcgloin <mark.mcgloin@ie.ibm.com>Cc: OAuth WG <oauth@ietf.org>; oauth-bounces@ietf.org
Sent: Fri, April 1, 2011 9:22:32 = AM
Subject: Re: [OAUTH-WG] = Authorization code security issue (reframed)

> So we have 2 different = communities of Oauth developers that
> will never = agree.
> 
> = SHOULD: Typically the social networking sites that need to
> cater = for tail end developers by not enforcing TLS on
> redirect_uri. It = is a risk to think that using strong
> language in the spec will = help them appreciate the issues
> MUST: Typically enterprise = organisations (I am in this
> camp). They can enforce indirectly = by only supporting
> registered callback urls and ensure those use = TLS

Security is at least as necessary to social networking = sites
as to enterprise sites.  Think about what this means = for
Facebook.  If you are using Wifi in a cafe and use = the
Facebook login button to log in to any application, a = hacker
can easily impersonate you.

By the way, is somebody = from Facebook reading this?  If so,
this is a vulnerability that = Facebook has right now, and you
should do something about it.  = At the very least you should
change the examples of redirect URIs in = the developer
documentation so that they use https rather than = http.

Francisco

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

= --Apple-Mail-23--895657161-- From fcorella@pomcor.com Fri Apr 1 11:22:44 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD623A686C for ; Fri, 1 Apr 2011 11:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx0cOCbvY5AV for ; Fri, 1 Apr 2011 11:22:43 -0700 (PDT) Received: from web55802.mail.re3.yahoo.com (web55802.mail.re3.yahoo.com [216.252.110.48]) by core3.amsl.com (Postfix) with SMTP id BCFDE3A68C1 for ; Fri, 1 Apr 2011 11:22:42 -0700 (PDT) Received: (qmail 76983 invoked by uid 60001); 1 Apr 2011 18:24:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301682261; bh=us+zCUNgxmR3yItoDt3t9nx94gMRMokn6gaz92Hsd/o=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4aHOAWcN+eDOACjkqCMeNe8BvFIyRLDk8AQE3NTK/BO1YNS98PZevCuRFABmZ3uM6O1XnwYG6OUy8C0aIunx9O+N03iSsu/ljrjRnu2JKr7ylF4PcOQNYKqO7li+/yMt0diHJVBovBhDaG2HtDw5laqyfhSaplID+nmeKWHyWE4= Message-ID: <133605.76951.qm@web55802.mail.re3.yahoo.com> X-YMail-OSG: 5N0o4wQVM1nJLP_wAGS6zeQ9YAImCkfh6YG6SdTNIsi3Isi ml8H7rmJI_gq9wVTHkGzmqDKfHiKccXP6824iDjKZX0cx8zd1lnZmERE2d1d kI1OJ2CxGo66NkSg6Ino2tTOM4Rc.QRcwd5vBOsWCfnbncJ7f_CLVoxXJqCi oFfr9t5CWpO3zp_CpT_ijhzmf77vyQe_dloq1bO0P12ecQuPAaMwC5asLonm f_fJPnWBEL7w.Lzl8sCMI.EGjVv86uv3qQPrzIXEjYxtjg.50UsEF46Zn0HM mfRt8Q.dwJ587IkjwzgkrXmnrUNt9Rlt4U72IzowQhY0unsXQ95bbwHKnsVa YYM6TLEOeCaB.sk833jr4h8wZCIRhc941Y4.QSSXpvXNTKtRYUc4a_wrfzXp DaxQMgfPbcmMhl5dk6eE- Received: from [67.91.91.101] by web55802.mail.re3.yahoo.com via HTTP; Fri, 01 Apr 2011 11:24:21 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Fri, 1 Apr 2011 11:24:21 -0700 (PDT) From: Francisco Corella To: Eran Hammer-Lahav , Prateek Mishra In-Reply-To: <4D947BA4.6080502@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-148677718-1301682261=:76951" Cc: OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 18:22:44 -0000 --0-148677718-1301682261=:76951 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Prateek, > I would like to strongly disagree with this proposal. >=20 > It amounts to explicitly making OAuth 2.0 insecure so as to > satisfy some mysterious and unspecified set of legacy OAuth > 1.0 deployments. >=20 > The SAML web SSO (artifact) profile - which shares many > characteristics with the initial steps in OAuth - requires > precisely such a counter-measure and is widely implemented > in 1000s of deployments. What counter-measure is this?=A0 Can you provide a reference? Section 4.1.3.5 of=20 http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf recommends TLS but does not require it. Francisco --0-148677718-1301682261=:76951 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Prateek,

> I would like to stron= gly disagree with this proposal.
>
> It amounts to explicitly = making OAuth 2.0 insecure so as to
> satisfy some mysterious and unsp= ecified set of legacy OAuth
> 1.0 deployments.
>
> The S= AML web SSO (artifact) profile - which shares many
> characteristics = with the initial steps in OAuth - requires
> precisely such a counter= -measure and is widely implemented
> in 1000s of deployments.

= What counter-measure is this?  Can you provide a reference?
Section= 4.1.3.5 of
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles= -2.0-os.pdf
recommends TLS but does not require it.

Francisco
=

--0-148677718-1301682261=:76951-- From Michael.Jones@microsoft.com Fri Apr 1 12:09:09 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D063A692D for ; Fri, 1 Apr 2011 12:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvEZ9qPonW3E for ; Fri, 1 Apr 2011 12:09:08 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id C73723A6920 for ; Fri, 1 Apr 2011 12:09:08 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 1 Apr 2011 12:10:42 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.38]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0270.002; Fri, 1 Apr 2011 12:10:42 -0700 From: Mike Jones To: Brian Campbell Thread-Topic: [OAUTH-WG] Agenda Update Thread-Index: AQHL79fC9xzeMdi1d0WS+Hm6TkRs+pRH7ZsggAGtdID//8XvQA== Date: Fri, 1 Apr 2011 19:10:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252C62BD@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4718054E-15B8-4FD9-8C8F-2633A943F1A6@gmx.net> <4E1F6AAD24975D4BA5B1680429673943252C462C@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Agenda Update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 19:09:09 -0000 We ran out of time in the working group meeting to consider the JWT profile= in any depth. I pointed out that it was intentionally very parallel to th= e SAML profile and asked people to review it toward the goal of making it a= working group document. Cheers, -- Mike -----Original Message----- From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Friday, April 01, 2011 8:37 AM To: Mike Jones Cc: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] Agenda Update Sadly, I am not in Prague. Given the similarities between the JWT and SAML= grant drafts, please let me know if anything substantial comes out of the = JWT discussions. Thanks! On Thu, Mar 31, 2011 at 3:05 PM, Mike Jones w= rote: > To this, I'd like to add discussion of draft-jones-oauth-jwt-bearer -- th= e JWT equivalent of draft-ietf-oauth-saml2-bearer. =A0In specific, I'd like= us to consider taking this up as a working group item. > > Thanks and see you in the morning! > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Hannes Tschofenig > Sent: Thursday, March 31, 2011 12:13 PM > To: OAuth WG > Subject: [OAUTH-WG] Agenda Update > > After a chat with Blaine we have an updated agenda proposal: > > First, we need to cover our working group items: > > -draft-ietf-oauth-v2 > *Security Consideration Section (Torsten) *Error Code registry (Mike) *Cl= ient Assertion Credentials (Mike) *Anything else? > -draft-ietf-oauth-v2-bearer > *Open issues? > -draft-ietf-oauth-saml2-bearer > *Open issues? > > Then, we jump into the presentations of the individual submissions: > > *OAuth Security (Torsten) > *JSON Web Token (Mike) > *Use Cases (Zachary) > *Simple Web Discovery (Mike) > *Dynamic Client Registration (Thomas, if time permits) *Token=20 > Revocation (Torsten, if time permits) *Chain Grant Type (Hannes on=20 > behalf of Phil, if time permits) > > Then, we will solicit your feedback on the rechartering. The feedback fro= m the presentations earlier will be taken into consideration. > > Hope that works for you! > > Ciao > Hannes & Blaine > > > > _______________________________________________ > OAuth mailing 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 skylar@kiva.org Fri Apr 1 18:05:41 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32903A69BE for ; Fri, 1 Apr 2011 18:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85jrMA6sycX7 for ; Fri, 1 Apr 2011 18:05:40 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by core3.amsl.com (Postfix) with SMTP id 189703A69BA for ; Fri, 1 Apr 2011 18:05:39 -0700 (PDT) Received: from source ([74.125.83.48]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKTZZ2x0ZNwR54g8l8KVhL7kg4Jc2wNy2i@postini.com; Fri, 01 Apr 2011 18:07:21 PDT Received: by gwj22 with SMTP id 22so2382241gwj.21 for ; Fri, 01 Apr 2011 18:07:19 -0700 (PDT) Received: by 10.150.239.7 with SMTP id m7mr654689ybh.55.1301706436199; Fri, 01 Apr 2011 18:07:16 -0700 (PDT) Received: from 205.66.227.10.in-addr.arpa (m9e0736d0.tmodns.net [208.54.7.158]) by mx.google.com with ESMTPS id q18sm611641ybk.26.2011.04.01.18.07.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 18:07:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <796881.62132.qm@web55807.mail.re3.yahoo.com> Date: Fri, 1 Apr 2011 21:07:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1BD75365-43BF-422E-9404-326A8D200A07@kiva.org> References: <796881.62132.qm@web55807.mail.re3.yahoo.com> To: fcorella@pomcor.com X-Mailer: Apple Mail (2.1084) Cc: "Karen P. Lewison" , OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 01:05:41 -0000 I'm going to summarize (hopefully faithfully) the attacks referenced = here, with the hope of attempting to sum up the scope of attacks being = documented. On Apr 1, 2011, at 1:29 PM, Francisco Corella wrote: > Skylar, >=20 > > Right, but just so we are clear, the only case you are > > discussing here is the MITM attack, which George, I and > > others have recently outlined. >=20 > There several flavors of MITM attacks, and a passive attack. > See=20 This document describes the MITM attack, similar to the one I just = described. Furthermore, it goes on to describe the vulnerabilities of = users on unsecured or public networks (particularly WiFi and malicious = rouge WiFi access points) to MITM attacks. > http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html, This document references the above attack, but emphasizes the risk to = applications using a provider service for Authentication who also fail = to secure their application (including redirect) with TLS. > http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html, This document briefly describes attacks from the first document and = mentions also a "passive" attack where the attacker "sniffs" the auth = code rather than performing a MITM attack. The attack can only be = successful if providers fail to revoke tokens/sessions for which the = provider sees a replay of auth codes. However, for all implementations = (again, assuming no TLS on the callback) it can "annoy" the user by = disrupting or breaking their sessions by use of auth-code replay. > and the last two paragraphs of page 4 of > http://pomcor.com/techreports/DoubleRedirection.pdf. So for all attacks, I assume you would agree that risk is all but = mitigated for applications running on a trusted corporate intranet = (where Bob and client C are within the corporate intranet) or VPN on a = public network. In this case, there would be no risk of MITM attacks = unless the corporate network itself was compromised (in which case, the = victim may have larger issues). Also, for the "cafe attack" the risks = would be nominal for users accessing the public service through a = protective VPN (in which case the MITM attack would be much more = expensive/difficult). I'm not trying to downplay the validity of any of the attacks, I'm just = trying to understand the cases being described and contexts which will = most likely bring attacks to bear. I do feel like in most cases the = security of the user's computer or the client app itself is more in = question than the security of the redirect step (getting back to the = difficult debate of scope/role of the OAuth spec). skylar= From phil.hunt@oracle.com Fri Apr 1 19:22:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 664DC28C0F7 for ; Fri, 1 Apr 2011 19:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bztC4eygXwMO for ; Fri, 1 Apr 2011 19:22:11 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 9A1BA28C0E3 for ; Fri, 1 Apr 2011 19:22:11 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p322Norw028476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Apr 2011 02:23:51 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p322NncI027860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Apr 2011 02:23:49 GMT Received: from abhmt015.oracle.com (abhmt015.oracle.com [141.146.116.24]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p322Nn99024981; Fri, 1 Apr 2011 21:23:49 -0500 Received: from [25.64.46.224] (/74.198.150.224) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Apr 2011 19:23:49 -0700 References: <796881.62132.qm@web55807.mail.re3.yahoo.com> <1BD75365-43BF-422E-9404-326A8D200A07@kiva.org> In-Reply-To: <1BD75365-43BF-422E-9404-326A8D200A07@kiva.org> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Type: text/plain; charset=us-ascii Message-Id: <66A24734-4F64-407C-8DDF-ABAF1F31CDDC@oracle.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8G4) From: Phillip Hunt Date: Fri, 1 Apr 2011 19:23:37 -0700 To: Skylar Woodward X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4D9688B6.0031:SCFSTAT5015188,ss=1,fgs=0 Cc: OAuth WG , "Karen P.Lewison" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 02:22:13 -0000 Sorry. I forgot to add it becomes a race if and only if the TS is smart enou= gh to invalidate code after first use.=20 Phil Sent from my phone.=20 On 2011-04-01, at 18:07, Skylar Woodward wrote: > I'm going to summarize (hopefully faithfully) the attacks referenced here,= with the hope of attempting to sum up the scope of attacks being documented= . >=20 > On Apr 1, 2011, at 1:29 PM, Francisco Corella wrote: >=20 >> Skylar, >>=20 >>> Right, but just so we are clear, the only case you are >>> discussing here is the MITM attack, which George, I and >>> others have recently outlined. >>=20 >> There several flavors of MITM attacks, and a passive attack. >> See=20 >=20 > This document describes the MITM attack, similar to the one I just describ= ed. Furthermore, it goes on to describe the vulnerabilities of users on unse= cured or public networks (particularly WiFi and malicious rouge WiFi access p= oints) to MITM attacks. >=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html, >=20 > This document references the above attack, but emphasizes the risk to appl= ications using a provider service for Authentication who also fail to secure= their application (including redirect) with TLS. >=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html, >=20 > This document briefly describes attacks from the first document and mentio= ns also a "passive" attack where the attacker "sniffs" the auth code rather t= han performing a MITM attack. The attack can only be successful if providers= fail to revoke tokens/sessions for which the provider sees a replay of auth= codes. However, for all implementations (again, assuming no TLS on the call= back) it can "annoy" the user by disrupting or breaking their sessions by us= e of auth-code replay. >=20 >> and the last two paragraphs of page 4 of >> http://pomcor.com/techreports/DoubleRedirection.pdf. >=20 > So for all attacks, I assume you would agree that risk is all but mitigate= d for applications running on a trusted corporate intranet (where Bob and cl= ient C are within the corporate intranet) or VPN on a public network. In th= is case, there would be no risk of MITM attacks unless the corporate network= itself was compromised (in which case, the victim may have larger issues). = Also, for the "cafe attack" the risks would be nominal for users accessing t= he public service through a protective VPN (in which case the MITM attack wo= uld be much more expensive/difficult). >=20 > I'm not trying to downplay the validity of any of the attacks, I'm just tr= ying to understand the cases being described and contexts which will most li= kely bring attacks to bear. I do feel like in most cases the security of th= e user's computer or the client app itself is more in question than the secu= rity of the redirect step (getting back to the difficult debate of scope/rol= e of the OAuth spec). >=20 > skylar From skylar@kiva.org Fri Apr 1 21:50:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708BA3A6A38 for ; Fri, 1 Apr 2011 21:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrMWuXFl2yJP for ; Fri, 1 Apr 2011 21:50:54 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by core3.amsl.com (Postfix) with SMTP id 8C0953A6A36 for ; Fri, 1 Apr 2011 21:50:53 -0700 (PDT) Received: from source ([209.85.210.174]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKTZarkUzzMV7MhTWcaDY7n4CkJpH3qnWc@postini.com; Fri, 01 Apr 2011 21:52:34 PDT Received: by mail-iy0-f174.google.com with SMTP id 14so5408593iyb.5 for ; Fri, 01 Apr 2011 21:52:33 -0700 (PDT) Received: by 10.43.69.202 with SMTP id yd10mr6695242icb.375.1301719952032; Fri, 01 Apr 2011 21:52:32 -0700 (PDT) Received: from [10.243.192.119] ([174.46.190.10]) by mx.google.com with ESMTPS id g16sm1929438ibb.3.2011.04.01.21.52.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 21:52:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <0095016D-7603-49D3-9E35-B1AA16C86E35@oracle.com> Date: Sat, 2 Apr 2011 00:52:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <754693.84979.qm@web55801.mail.re3.yahoo.com> <555698.48529.qm@web37602.mail.mud.yahoo.com> <0095016D-7603-49D3-9E35-B1AA16C86E35@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1084) Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 04:50:56 -0000 Am I the only one still supporting SHOULD on this case? If someone else = supports this language, please speak up. Otherwise, it seems the group = SHOULD move forward with MUST. As a provider, we (Kiva) must deal with the possibility of an ecosystem = of developer apps which can't feasibly serve HTTPS endpoints. However, = we're perfectly capable of securing credential exchange and our = ecosystem with our own API/Network additions without holding up the = working group on this point. Alternatively, if others are interested in = supporting developers who can't or won't establish HTTPS endpoints, I'm = happy to continue the discussion to work toward a solution (in this = working group or side thread). On Apr 1, 2011, at 2:12 PM, Phil Hunt wrote: > Unfortunately neither solution suggested so far is acceptable. So a = vote from my perspective is premature. >=20 > I'd like to keep working for a new solution. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-04-01, at 10:51 AM, Oleg Gryb wrote: >=20 >> It's a very interesting discussion and I think, I understand both = parties well because consider myself belonging to both communities = (enterprise and networking). Still, I would vote in favor of MUST. >>=20 >> Considering the big size of this mailing list and the big level of = engagement of its members, why don't we vote? >>=20 >> The results of the vote should be taken into consideration by those = who writes the final version. >>=20 >> From: Francisco Corella >> To: Eran Hammer-Lahav ; Mark Mcgloin = >> Cc: OAuth WG ; oauth-bounces@ietf.org >> Sent: Fri, April 1, 2011 9:22:32 AM >> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) >>=20 >> > So we have 2 different communities of Oauth developers that >> > will never agree. >> >=20 >> > SHOULD: Typically the social networking sites that need to >> > cater for tail end developers by not enforcing TLS on >> > redirect_uri. It is a risk to think that using strong >> > language in the spec will help them appreciate the issues >> > MUST: Typically enterprise organisations (I am in this >> > camp). They can enforce indirectly by only supporting >> > registered callback urls and ensure those use TLS >>=20 >> Security is at least as necessary to social networking sites >> as to enterprise sites. Think about what this means for >> Facebook. If you are using Wifi in a cafe and use the >> Facebook login button to log in to any application, a hacker >> can easily impersonate you. >>=20 >> By the way, is somebody from Facebook reading this? If so, >> this is a vulnerability that Facebook has right now, and you >> should do something about it. At the very least you should >> change the examples of redirect URIs in the developer >> documentation so that they use https rather than http. >>=20 >> Francisco >>=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 phil.hunt@oracle.com Fri Apr 1 23:55:47 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF34328C138 for ; Fri, 1 Apr 2011 23:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mte4CFZihEBu for ; Fri, 1 Apr 2011 23:55:46 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 9344228C0F8 for ; Fri, 1 Apr 2011 23:55:46 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p326vOm7008033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Apr 2011 06:57:26 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p326vN4s028031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Apr 2011 06:57:24 GMT Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p326vNJN016431; Sat, 2 Apr 2011 01:57:23 -0500 Received: from [25.64.46.224] (/74.198.150.224) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Apr 2011 23:57:23 -0700 References: <754693.84979.qm@web55801.mail.re3.yahoo.com> <555698.48529.qm@web37602.mail.mud.yahoo.com> <0095016D-7603-49D3-9E35-B1AA16C86E35@oracle.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8G4) Content-Type: text/plain; charset=us-ascii Message-Id: <20798CDB-7F06-4BC5-B781-4489E08C5386@oracle.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8G4) From: Phillip Hunt Date: Fri, 1 Apr 2011 23:57:15 -0700 To: Skylar Woodward X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4D96C8D4.0063:SCFSTAT5015188,ss=1,fgs=0 Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 06:55:47 -0000 By not feasible, what is the technical use case/issue?=20 Phil Sent from my phone.=20 On 2011-04-01, at 21:52, Skylar Woodward wrote: > Am I the only one still supporting SHOULD on this case? If someone else su= pports this language, please speak up. Otherwise, it seems the group SHOULD m= ove forward with MUST. >=20 > As a provider, we (Kiva) must deal with the possibility of an ecosystem of= developer apps which can't feasibly serve HTTPS endpoints. However, we're p= erfectly capable of securing credential exchange and our ecosystem with our o= wn API/Network additions without holding up the working group on this point.= Alternatively, if others are interested in supporting developers who can't= or won't establish HTTPS endpoints, I'm happy to continue the discussion to= work toward a solution (in this working group or side thread). >=20 >=20 >=20 > On Apr 1, 2011, at 2:12 PM, Phil Hunt wrote: >=20 >> Unfortunately neither solution suggested so far is acceptable. So a vote f= rom my perspective is premature. >>=20 >> I'd like to keep working for a new solution. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-04-01, at 10:51 AM, Oleg Gryb wrote: >>=20 >>> It's a very interesting discussion and I think, I understand both partie= s well because consider myself belonging to both communities (enterprise and= networking). Still, I would vote in favor of MUST. >>>=20 >>> Considering the big size of this mailing list and the big level of engag= ement of its members, why don't we vote? >>>=20 >>> The results of the vote should be taken into consideration by those who w= rites the final version. >>>=20 >>> From: Francisco Corella >>> To: Eran Hammer-Lahav ; Mark Mcgloin >>> Cc: OAuth WG ; oauth-bounces@ietf.org >>> Sent: Fri, April 1, 2011 9:22:32 AM >>> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) >>>=20 >>>> So we have 2 different communities of Oauth developers that >>>> will never agree. >>>>=20 >>>> SHOULD: Typically the social networking sites that need to >>>> cater for tail end developers by not enforcing TLS on >>>> redirect_uri. It is a risk to think that using strong >>>> language in the spec will help them appreciate the issues >>>> MUST: Typically enterprise organisations (I am in this >>>> camp). They can enforce indirectly by only supporting >>>> registered callback urls and ensure those use TLS >>>=20 >>> Security is at least as necessary to social networking sites >>> as to enterprise sites. Think about what this means for >>> Facebook. If you are using Wifi in a cafe and use the >>> Facebook login button to log in to any application, a hacker >>> can easily impersonate you. >>>=20 >>> By the way, is somebody from Facebook reading this? If so, >>> this is a vulnerability that Facebook has right now, and you >>> should do something about it. At the very least you should >>> change the examples of redirect URIs in the developer >>> documentation so that they use https rather than http. >>>=20 >>> Francisco >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From fcorella@pomcor.com Sat Apr 2 08:30:38 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAE828C103 for ; Sat, 2 Apr 2011 08:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQr1wjyc793x for ; Sat, 2 Apr 2011 08:30:37 -0700 (PDT) Received: from web55807.mail.re3.yahoo.com (web55807.mail.re3.yahoo.com [216.252.110.53]) by core3.amsl.com (Postfix) with SMTP id CC7CD3A6846 for ; Sat, 2 Apr 2011 08:30:36 -0700 (PDT) Received: (qmail 51440 invoked by uid 60001); 2 Apr 2011 15:32:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301758336; bh=wZIzYOnJMeK1H/4WED30pEOtX+U37uRspXa2ZfvKKHg=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Btfh6gOaqpt5/QG0xeKVkDXgNzhlRPW3J2lgnXdrhd0F3nJMWqO3/OEcGeQW8UADgejy82NNNqrdUcr5qoDXG82t5FY66k1DL6hOFmTwxx9pLC4PFdWFNkT7jkdVDUd5bDjN+XCkVFrOUtMGqdHLy3Xyh7iRaNkkgIO84DbMaQ4= Message-ID: <1484.31056.qm@web55807.mail.re3.yahoo.com> X-YMail-OSG: XGkPrcAVM1lr5gtNbBCpKIDWWYeCRme33q1_c1I.cYLzR8m J4Q0DqAjXhkOft5QmtHBICMQD8KV7t0kz_qX_d..ds6Lg4J6oxrAB0r8Pt9p 2.rmysbcyuIA8C6nFQrd8eveD1hXIVCsRUw8xdqQ2aPSOUfXaZnbWJ4x5GTQ 98H5ewubqdyQTZAqyOiu6WcR0pvf6ZWYenI5bN6ae6vq3B8YlIPXwS9z0kD7 PjIzmwRTlJGZ7UggqC7wbWmSfWKYmZJvVVxiEZAtYxh3ZoWYrZs5sh_jd2pj .e1e.Y4h1I63Th0jmkbbMpvSq1B.W322DArTVpuHJDqDBgKeuQj2GWBEi1kD fj2CzPF6teyXmjGiiohdCsqvdr3vB_gZEvm199qkY6bUhELkf8T3Jch.8B6Y sLOpEpl9cVbs- Received: from [174.65.103.16] by web55807.mail.re3.yahoo.com via HTTP; Sat, 02 Apr 2011 08:32:15 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Sat, 2 Apr 2011 08:32:15 -0700 (PDT) From: Francisco Corella To: Skylar Woodward In-Reply-To: <1BD75365-43BF-422E-9404-326A8D200A07@kiva.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1832667956-1301758335=:31056" Cc: "Karen P. Lewison" , OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 15:30:38 -0000 --0-1832667956-1301758335=:31056 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Skylar, > I'm going to summarize (hopefully faithfully) the attacks > referenced here, with the hope of attempting to sum up the > scope of attacks being documented. Thank you for reading and summarizing the attacks. > On Apr 1, 2011, at 1:29 PM, Francisco Corella wrote: >=20 > > Skylar, > > > > > Right, but just so we are clear, the only case you are > > > discussing here is the MITM attack, which George, I and > > > others have recently outlined. > > > > There several flavors of MITM attacks, and a passive attack. > > See >=20 > This document describes the MITM attack, similar to the one > I just described. Furthermore, it goes on to describe the > vulnerabilities of users on unsecured or public networks > (particularly WiFi and malicious rouge WiFi access points) > to MITM attacks. >=20 > > http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html, >=20 > This document references the above attack, but emphasizes > the risk to applications using a provider service for > Authentication who also fail to secure their application > (including redirect) with TLS. >=20 > > http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html, The difference between 4894 and 4900 is that, whereas in 4900 the attacker intercepts the authorization code, as we've been discussing, in 4894 the attacker interecpts a session cookie.=A0 But yes, both are attacks against the same callback endpoint unprotected by TLS. > This document briefly describes attacks from the first > document and mentions also a "passive" attack where the > attacker "sniffs" the auth code rather than performing a > MITM attack. The attack can only be successful if providers > fail to revoke tokens/sessions for which the provider sees a > replay of auth codes.=20 When the same authorization code is received twice, the specification suggests revoking the access token that was issued first.=A0 If the suggestion is followed, the attack is most likely to succeed. > However, for all implementations > (again, assuming no TLS on the callback) it can "annoy" the > user by disrupting or breaking their sessions by use of > auth-code replay. >=20 > > and the last two paragraphs of page 4 of > > http://pomcor.com/techreports/DoubleRedirection.pdf. >=20 > So for all attacks, I assume you would agree that risk is > all but mitigated for applications running on a trusted > corporate intranet (where Bob and client C are within the > corporate intranet)=20 Placing all participants within a corporate intranet does not by itself mitigate the attacks, unless you assume all intranet users are trusted.=A0 But that may not be case.=A0 The WiFi attacks that I described can be mounted against an intranet from a company parking lot. > or VPN on a public network.=A0 In this > case, there would be no risk of MITM attacks unless the > corporate network itself was compromised (in which case, the > victim may have larger issues).=A0 Also, for the "cafe attack" > the risks would be nominal for users accessing the public > service through a protective VPN (in which case the MITM > attack would be much more expensive/difficult). Would requiring use of a VPN be less of a burden than requiring TLS for the callback endpoint? Francisco --0-1832667956-1301758335=:31056 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --0-1832667956-1301758335=:31056-- From dick.hardt@gmail.com Sat Apr 2 08:53:40 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2DAD28C0E0 for ; Sat, 2 Apr 2011 08:53:40 -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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7H+dx38B3bqI for ; Sat, 2 Apr 2011 08:53:40 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id 1584E28B797 for ; Sat, 2 Apr 2011 08:53:40 -0700 (PDT) Received: by pxi20 with SMTP id 20so1377718pxi.27 for ; Sat, 02 Apr 2011 08:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=+qbxh6fobQuWRjrDGOy25EtChnCoH3/et3XzjWCqfFk=; b=qxg19h+cGftiVjOUq/pz/wF1ZaGGyYPgVXsMYqNxBImYxqnhBEFMzsAVyuQXLw8sGe sR1T+AFc9dRBH5RPC/eyx/K4wubfOYFN/HUqVuRU//LtKfzqDr2PKR15+KFAEN5/lxop X8EfBw4vq372Xw1hvT+rSLtncqv7BJ9vxxD5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Ph/YzWscoCU8sfIanN1Rdlhf6NZpKw7fQy/GbitP1ad838ThW0nNe5kZSejGHjfHca wTIU9KTuMiMKA6L5v7CjTj0u6UQgdjPvmXA25C1mzKsAjF9vOng2r03U+g6bowB/36Pn zpXxuTEXNgzG6BfPM6JP52MGs7mSu2MD01G+Q= Received: by 10.142.158.10 with SMTP id g10mr4367259wfe.45.1301759721147; Sat, 02 Apr 2011 08:55:21 -0700 (PDT) Received: from [192.168.1.16] (c-24-5-83-209.hsd1.ca.comcast.net [24.5.83.209]) by mx.google.com with ESMTPS id n4sm4599193wfl.2.2011.04.02.08.55.18 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 08:55:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <1484.31056.qm@web55807.mail.re3.yahoo.com> Date: Sat, 2 Apr 2011 08:55:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1484.31056.qm@web55807.mail.re3.yahoo.com> To: Francisco Corella , Eran Hammer-Lahav , Skylar Woodward , Phillip Hunt X-Mailer: Apple Mail (2.1084) Cc: OAuth WG Subject: [OAUTH-WG] to TLS or not on redirect on consumer websites :: security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 15:53:40 -0000 As has been pointed out in the discussions, if a website does not = employe TLS on connections on other connections, having TLS on the = redirect does not add security. Depending on the resource grant being given, the nature of the website, = not running TLS may be an acceptable security tradeoff. No being an IETF = security expert, I don't have an opinion on MUST or SHOULD language for = TLS on the redirect. This tradeoff should be well documented in the security considerations, = and this language I feel strongly should be in the core spec so that = implementors understand the risk. Examples where this is an acceptable tradeoff could be where access to = the resource is read-only, and the resource is publicly available = information. In this case, the resource is enabling the contextually = useful information for the user. A specific example of this would be = blog comments.=20= From eran@hueniverse.com Sat Apr 2 09:31:46 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B521C3A6842 for ; Sat, 2 Apr 2011 09:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tis2OFIqm9+1 for ; Sat, 2 Apr 2011 09:31:45 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id CB3F83A6821 for ; Sat, 2 Apr 2011 09:31:44 -0700 (PDT) Received: (qmail 7490 invoked from network); 2 Apr 2011 16:33:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Apr 2011 16:33:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 2 Apr 2011 09:33:25 -0700 From: Eran Hammer-Lahav To: Skylar Woodward , Phil Hunt Date: Sat, 2 Apr 2011 09:33:13 -0700 Thread-Topic: [OAUTH-WG] Authorization code security issue (reframed) Thread-Index: Acvw8cvuaCYhS9SjTpCLuLXlpARriwAYRb0Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664D9AB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <754693.84979.qm@web55801.mail.re3.yahoo.com> <555698.48529.qm@web37602.mail.mud.yahoo.com> <0095016D-7603-49D3-9E35-B1AA16C86E35@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 16:31:46 -0000 Google, Facebook, and Yahoo! already indicated they will not enforce such a= MUST. I could not get a clear answer from Twitter. However, no one representing this companies has bothered to express this vi= ew on the list, and to express how they would like the specification to han= dle this case. This is why I stopped advocating for it (personally, my own = product is already end-to-end TLS, and when we open it up for developers, w= ill not enforce it for personal installations). It is important to remember that this is ultimately within the discretion o= f the authorization server, and the only ramification (other than the secur= ity issue) is not being able to claim full conformance. But such a claim ju= st has no real meaning of value in the consumer space, only in enterprise/g= overnment/finance - so I doubt anyone will care if Kiva and the above vendo= rs allow some clients to be less secure than ideal. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Skylar Woodward > Sent: Friday, April 01, 2011 9:52 PM > To: Phil Hunt > Cc: Oleg Gryb; OAuth WG > Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) >=20 > Am I the only one still supporting SHOULD on this case? If someone else > supports this language, please speak up. Otherwise, it seems the group > SHOULD move forward with MUST. >=20 > As a provider, we (Kiva) must deal with the possibility of an ecosystem o= f > developer apps which can't feasibly serve HTTPS endpoints. However, we'r= e > perfectly capable of securing credential exchange and our ecosystem with > our own API/Network additions without holding up the working group on > this point. Alternatively, if others are interested in supporting develo= pers > who can't or won't establish HTTPS endpoints, I'm happy to continue the > discussion to work toward a solution (in this working group or side threa= d). >=20 >=20 >=20 > On Apr 1, 2011, at 2:12 PM, Phil Hunt wrote: >=20 > > Unfortunately neither solution suggested so far is acceptable. So a vot= e > from my perspective is premature. > > > > I'd like to keep working for a new solution. > > > > Phil > > phil.hunt@oracle.com > > > > > > > > > > On 2011-04-01, at 10:51 AM, Oleg Gryb wrote: > > > >> It's a very interesting discussion and I think, I understand both part= ies well > because consider myself belonging to both communities (enterprise and > networking). Still, I would vote in favor of MUST. > >> > >> Considering the big size of this mailing list and the big level of eng= agement > of its members, why don't we vote? > >> > >> The results of the vote should be taken into consideration by those wh= o > writes the final version. > >> > >> From: Francisco Corella > >> To: Eran Hammer-Lahav ; Mark Mcgloin > >> > >> Cc: OAuth WG ; oauth-bounces@ietf.org > >> Sent: Fri, April 1, 2011 9:22:32 AM > >> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) > >> > >> > So we have 2 different communities of Oauth developers that will > >> > never agree. > >> > > >> > SHOULD: Typically the social networking sites that need to cater > >> > for tail end developers by not enforcing TLS on redirect_uri. It is > >> > a risk to think that using strong language in the spec will help > >> > them appreciate the issues > >> > MUST: Typically enterprise organisations (I am in this camp). They > >> > can enforce indirectly by only supporting registered callback urls > >> > and ensure those use TLS > >> > >> Security is at least as necessary to social networking sites as to > >> enterprise sites. Think about what this means for Facebook. If you > >> are using Wifi in a cafe and use the Facebook login button to log in > >> to any application, a hacker can easily impersonate you. > >> > >> By the way, is somebody from Facebook reading this? If so, this is a > >> vulnerability that Facebook has right now, and you should do > >> something about it. At the very least you should change the examples > >> of redirect URIs in the developer documentation so that they use > >> https rather than http. > >> > >> Francisco > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sat Apr 2 09:39:48 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E676E3A6857 for ; Sat, 2 Apr 2011 09:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3ajkre2XmvX for ; Sat, 2 Apr 2011 09:39:48 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1E1A43A683D for ; Sat, 2 Apr 2011 09:39:48 -0700 (PDT) Received: (qmail 17446 invoked from network); 2 Apr 2011 16:41:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Apr 2011 16:41:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 2 Apr 2011 09:41:27 -0700 From: Eran Hammer-Lahav To: Dick Hardt , Francisco Corella , Skylar Woodward , Phillip Hunt Date: Sat, 2 Apr 2011 09:41:16 -0700 Thread-Topic: to TLS or not on redirect on consumer websites :: security considerations Thread-Index: AcvxTl+GTvsKuzEJT6+S+R4ALTO6fgABXilg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664D9AD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1484.31056.qm@web55807.mail.re3.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] to TLS or not on redirect on consumer websites :: security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 16:39:49 -0000 Another example I mentioned earlier is when the client does not expose the = protected resources back to the bearer of the code. For example, a Twitter = application sending you emails when someone stops following you. Since all = it does is get the code and then uses it internally (no user login function= ality), TLS adds NOTHING. In practice, the MUST use TLS is not really about the redirection endpoint,= but about ANY client endpoint used for user authentication (which is what = the code is used in all these attacks). A MUST means we take a stand on the= one such endpoint that is within our scope, but it doesn't, by itself, off= ers full protection of the protected resources granted if the client doesn'= t match that security level to the redirection endpoint. The only way to enforce that is with client certification by the authorizat= ion server vendor - something that is just completely impractical in the co= nsumer web space. For example, Citibank can audit (well, pay someone to) In= tuit tax products if they give them OAuth access, to make sure the entire t= ax product uses TLS without any exceptions (sometimes, a contract with a bi= g liability sum will work too). I am not expressing a position here, just want to make sure people understa= nd that regardless of using a MUST or SHOULD language in the document, the = complete security picture of the client matters much more. EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Saturday, April 02, 2011 8:55 AM > To: Francisco Corella; Eran Hammer-Lahav; Skylar Woodward; Phillip Hunt > Cc: OAuth WG > Subject: to TLS or not on redirect on consumer websites :: security > considerations >=20 >=20 > As has been pointed out in the discussions, if a website does not employe > TLS on connections on other connections, having TLS on the redirect does = not > add security. >=20 > Depending on the resource grant being given, the nature of the website, n= ot > running TLS may be an acceptable security tradeoff. No being an IETF secu= rity > expert, I don't have an opinion on MUST or SHOULD language for TLS on the > redirect. >=20 > This tradeoff should be well documented in the security considerations, a= nd > this language I feel strongly should be in the core spec so that implemen= tors > understand the risk. >=20 > Examples where this is an acceptable tradeoff could be where access to th= e > resource is read-only, and the resource is publicly available information= . In > this case, the resource is enabling the contextually useful information f= or the > user. A specific example of this would be blog comments. From fcorella@pomcor.com Sat Apr 2 10:47:04 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B893A6875 for ; Sat, 2 Apr 2011 10:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ4-oGgSnKHi for ; Sat, 2 Apr 2011 10:47:03 -0700 (PDT) Received: from web55803.mail.re3.yahoo.com (web55803.mail.re3.yahoo.com [216.252.110.49]) by core3.amsl.com (Postfix) with SMTP id 8573E3A6874 for ; Sat, 2 Apr 2011 10:47:03 -0700 (PDT) Received: (qmail 18509 invoked by uid 60001); 2 Apr 2011 17:48:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301766521; bh=rZs06gsAhWukJzICYJz1D5Q5nPepBCvxMWLdkS3NiKI=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=avgT6RFDJd61gANV9hl80VVsZmP2dQG+wtdXSwDbk4+QhickNP57BSMdVpJFoah4f0+RqkAD+9O2Oo8AyMAqetZktiNgN0ec+6u/w34ksmeQpZO0gWgb4PNkjlaEj9vTTtgwJtRXnEF/dJdQzWbIV83yguTec4j4g8gFalo8itA= Message-ID: <617134.17423.qm@web55803.mail.re3.yahoo.com> X-YMail-OSG: VtJUzhsVM1mcg53qHB2N39q4c4XXrnh5esa3fuHleS3xv2s DlKFls1g6ZOnfS0_yXyV5Odw5xcirfQ108YhvXbj6J7pNFb9QASMr4a9hRPE ZUVlVdsFI1wcMhNmbvKvQYNbBNTzk4_zCx76h.DRUdEKz1Cdi5lRRw1ww8KM RI_EhatAuiwu5.YirSqUZJxFPjPbllCcrhvatZvFJ3Q8TuzXZ56uKoPCej9z MqkqZgmBMx8nnrneq.6KksZjAgrWw6ZAs8IcVm6JzU6NZaYog7z6LNGaZEPj GVU4_6mdgzfYIska4kImhQ18GhVB.LHeSKQSvWbNWbjov0X3FHqsc.bxGdFM l5MixGg7cCcok2M4ezJgvWnGQ9vVS7PmwqLR8y2HTFY7lU2fZKKMs25NMJiU T7brx Received: from [174.65.103.16] by web55803.mail.re3.yahoo.com via HTTP; Sat, 02 Apr 2011 10:48:41 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Sat, 2 Apr 2011 10:48:41 -0700 (PDT) From: Francisco Corella To: Skylar Woodward , Phil Hunt , Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664D9AB@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-962372069-1301766521=:17423" Cc: Oleg Gryb , OAuth WG , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 17:47:04 -0000 --0-962372069-1301766521=:17423 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Eran, > Google, Facebook, and Yahoo! already indicated they will not enforce > such a MUST. I could not get a clear answer from Twitter. >=20 > However, no one representing this companies has bothered to express > this view on the list, and to express how they would like the > specification to handle this case. This is why I stopped advocating > for it (personally, my own product is already end-to-end TLS, and when > we open it up for developers, will not enforce it for personal > installations). Good.=A0 The IETF is not a consortium of companies.=A0 What the WG should debate is whether the IETF should endorse lack of security. Francisco --0-962372069-1301766521=:17423 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Skylar,

> I'm going to summarize (h= opefully faithfully) the attacks
> referenced here, with the hope of = attempting to sum up the
> scope of attacks being documented.

= Thank you for reading and summarizing the attacks.

> On Apr 1, 20= 11, at 1:29 PM, Francisco Corella wrote:
>
> > Skylar,
&= gt; >
> > > Right, but just so we are clear, the only case y= ou are
> > > discussing here is the MITM attack, which George, = I and
> > > others have recently outlined.
> >
>= > There several flavors of MITM attacks, and a passive attack.
> = > See
>
> This document describes the MITM attack, similar = to the one
> I just described. Furthermore, it goes on to describe th= e
> vulnerabilities of users on unsecured or public networks
> (particularly WiFi and malicious rouge WiFi access points)
> to MITM= attacks.
>
> > http://www.ietf.org/mail-archive/web/oauth/= current/msg04894.html,
>
> This document references the above = attack, but emphasizes
> the risk to applications using a provider se= rvice for
> Authentication who also fail to secure their application<= br>> (including redirect) with TLS.
>
> > http://www.iet= f.org/mail-archive/web/oauth/current/msg04900.html,

The difference b= etween 4894 and 4900 is that, whereas in
4900 the attacker intercepts th= e authorization code, as
we've been discussing, in 4894 the attacker int= erecpts a
session cookie.  But yes, both are attacks against the sa= me
callback endpoint unprotected by TLS.

> This document brief= ly describes attacks from the first
> document and mentions also a "p= assive" attack where the
> attacker "sniffs" the auth code rather than performing a
> MITM attack. The attack can only be succe= ssful if providers
> fail to revoke tokens/sessions for which the pro= vider sees a
> replay of auth codes.

When the same authorizat= ion code is received twice, the
specification suggests revoking the acce= ss token that was
issued first.  If the suggestion is followed, the= attack is
most likely to succeed.

> However, for all implemen= tations
> (again, assuming no TLS on the callback) it can "annoy" the=
> user by disrupting or breaking their sessions by use of
> au= th-code replay.
>
> > and the last two paragraphs of page 4= of
> > http://pomcor.com/techreports/DoubleRedirection.pdf.
&g= t;
> So for all attacks, I assume you would agree that risk is
&g= t; all but mitigated for applications running on a trusted
> corporat= e intranet (where Bob and client C are within the
> corporate intranet)

Placing all participants within a corporate intranet doe= s
not by itself mitigate the attacks, unless you assume all
intranet = users are trusted.  But that may not be case.  The
WiFi attack= s that I described can be mounted against an
intranet from a company par= king lot.

> or VPN on a public network.  In this
> cas= e, there would be no risk of MITM attacks unless the
> corporate netw= ork itself was compromised (in which case, the
> victim may have larg= er issues).  Also, for the "cafe attack"
> the risks would be no= minal for users accessing the public
> service through a protective V= PN (in which case the MITM
> attack would be much more expensive/diff= icult).

Would requiring use of a VPN be less of a burden than
req= uiring TLS for the callback endpoint?

Francisco

Eran,

> Google, Facebook, and Yahoo= ! already indicated they will not enforce
> such a MUST. I could not = get a clear answer from Twitter.
>
> However, no one represent= ing this companies has bothered to express
> this view on the list, a= nd to express how they would like the
> specification to handle this = case. This is why I stopped advocating
> for it (personally, my own p= roduct is already end-to-end TLS, and when
> we open it up for develo= pers, will not enforce it for personal
> installations).

Good.=   The IETF is not a consortium of companies.  What the WG should<= br>debate is whether the IETF should endorse lack of security.

Franc= isco

--0-962372069-1301766521=:17423-- From fcorella@pomcor.com Sat Apr 2 11:12:06 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A925728C122 for ; Sat, 2 Apr 2011 11:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz2ubKRXYoxh for ; Sat, 2 Apr 2011 11:12:06 -0700 (PDT) Received: from web55802.mail.re3.yahoo.com (web55802.mail.re3.yahoo.com [216.252.110.48]) by core3.amsl.com (Postfix) with SMTP id CCE2228C103 for ; Sat, 2 Apr 2011 11:12:05 -0700 (PDT) Received: (qmail 62092 invoked by uid 60001); 2 Apr 2011 18:13:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301768025; bh=7ThBtvOa7rM1W0H1mq5oxXm8OgirRsNe8SjRNnOD8NQ=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=uzQazL2xZ7kzKknrXHuOgONYxgBoP1L6UXul3GVrcM1l/b4XKrET2g3tQ9p7qwEv8HRXE2dbVm2wXM69gXb1phYJcHrXV3XiRcfwV4Tq2rlJ9DtGyqhprHrqj4P3cXmMuuKnr9myTlATeBaUubTwoJb2+mXXlr+LuwBIG2RFJvY= Message-ID: <81117.51614.qm@web55802.mail.re3.yahoo.com> X-YMail-OSG: i7DwNtQVM1lVxSTAGTeeRrUs7xLadGmA47YCSWWHAycshDG gYqMfmhKZ87mwtnVKpxKkea_lO2Gkyu57gnVHkAcjgM2vC9sgqwxLg7BQeD1 PQgdmchSDhCGCWPH2HdYlYp9hbDB83iw4XS.CV0A2r5B6p3b7tlkJyGpyk_N pFkXp6YttWNQe8dbLxf12DPDnryfdSgPymNa_ZnHOlpqpaVlbFZif0kOpFFX dgxLrX91QibH121skP9APtiXf.toaQkHOAG.UsdjSW5LQkhvX1GcDalmfeon PFRpGiCXS0.ju8d_nm.fseUfbPy3xLAHrWMcE8U9CC91cSVfRpVz6vk95P50 dozS6v_QJWmky1lcRUibwqILUvlLOAibrK2lUTM7VCeaLYY4ffv5zxdGMqkR cSNC. Received: from [174.65.103.16] by web55802.mail.re3.yahoo.com via HTTP; Sat, 02 Apr 2011 11:13:45 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Sat, 2 Apr 2011 11:13:45 -0700 (PDT) From: Francisco Corella To: Dick Hardt , Skylar Woodward , Phillip Hunt , Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664D9AD@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1201272733-1301768025=:51614" Cc: OAuth WG , "Karen P. Lewison" Subject: Re: [OAUTH-WG] to TLS or not on redirect on consumer websites :: security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 18:12:06 -0000 --0-1201272733-1301768025=:51614 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > Another example I mentioned earlier is when the client does > not expose the protected resources back to the bearer of the > code. For example, a Twitter application sending you emails > when someone stops following you. Since all it does is get > the code and then uses it internally (no user login > functionality), TLS adds NOTHING. I'm not sure I understand the example.=A0 Would the attacker be able to get emails when someone stops following the user? Would that be OK? Anyway, an application that accesses Twitter on the user's behalf is likely to be able to send tweets on the user's behalf.=A0 The attacks we've been discussing would allow the attacker to send tweets on the user's behalf.=A0 That's definitely not cool. User impersonation when Oauth is used for social login is not the only consequence of not requiring TSL for the callback endpoint. Francisco --0-1201272733-1301768025=:51614 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
> Another example I mentioned earlier is w= hen the client does
> not expose the protected resources back to the = bearer of the
> code. For example, a Twitter application sending you = emails
> when someone stops following you. Since all it does is get> the code and then uses it internally (no user login
> function= ality), TLS adds NOTHING.

I'm not sure I understand the example.&nbs= p; Would the attacker
be able to get emails when someone stops following= the user?
Would that be OK?

Anyway, an application that accesses= Twitter on the user's
behalf is likely to be able to send tweets on the= user's
behalf.  The attacks we've been discussing would allow the<= br>attacker to send tweets on the user's behalf.  That's
definitely= not cool.

User impersonation when Oauth is used for social login is
not the only consequence of not requiring TSL for the
callback en= dpoint.

Francisco

--0-1201272733-1301768025=:51614-- From recordond@gmail.com Sat Apr 2 11:35:19 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A0D3A6881 for ; Sat, 2 Apr 2011 11:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6g8aTBEnG3g for ; Sat, 2 Apr 2011 11:35:18 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 124D83A6873 for ; Sat, 2 Apr 2011 11:35:17 -0700 (PDT) Received: by vxg33 with SMTP id 33so4026256vxg.31 for ; Sat, 02 Apr 2011 11:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ytjRZsATqu09SsghzDDQOC6V1QGjh8s0ig6LkzYEfv4=; b=QCwDZpDWSQ0T/uq3V4I3J1SxQosd94bJ84KnvOiGAqCJOnzMMBnd1FYoMz2ijWV82N WiQ39LFH7tzj3GFntozBbz30ZO7jIViEvz2diiZwNrnRyC+g2oDX4cc9yQDu3LM5Zu7K MUQV6db+2oVR5SqCGFBvbAnksiBgiNAjn+2e0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NlvHLnBFnMfTsy4E25nPUHehoWpu9s5F7Y85frhn42pLUeiO6Fyj96VuIkg0fhHehU iMStxNTsEmodEiAMTixncvuxzww9Fu6rFqgiGrUkcPeUQB9ySDafZwhfcTkzpmhA5H1f yABjfrqCKBCIHRSjZQUNHyupku1ehxUHJSOlg= MIME-Version: 1.0 Received: by 10.52.67.73 with SMTP id l9mr7092304vdt.287.1301769417918; Sat, 02 Apr 2011 11:36:57 -0700 (PDT) Received: by 10.52.164.227 with HTTP; Sat, 2 Apr 2011 11:36:57 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664D9AB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <754693.84979.qm@web55801.mail.re3.yahoo.com> <555698.48529.qm@web37602.mail.mud.yahoo.com> <0095016D-7603-49D3-9E35-B1AA16C86E35@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234465664D9AB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 2 Apr 2011 11:36:57 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav , Francisco Corella , Skylar Woodward , Phil Hunt , Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 18:35:20 -0000 If this is changed to a MUST, Facebook will be in violation of the specification moving forward. It is untenable to require all of our *client* developers to implement TLS endpoints though we certainly support developers who wish to do so. This is very different than offerring our entire API (and now site as opt-in) over TLS as the server. I feel like we need to write the appropriate security considerations even with a MUST because many deployers will ignore the requirement. It's far more valuable to document the risk and explain ways to help mitigate it than just changing a SHOULD to an ignored MUST. --David On Sat, Apr 2, 2011 at 9:33 AM, Eran Hammer-Lahav wro= te: > Google, Facebook, and Yahoo! already indicated they will not enforce such= a MUST. I could not get a clear answer from Twitter. > > However, no one representing this companies has bothered to express this = view on the list, and to express how they would like the specification to h= andle this case. This is why I stopped advocating for it (personally, my ow= n product is already end-to-end TLS, and when we open it up for developers,= will not enforce it for personal installations). > > It is important to remember that this is ultimately within the discretion= of the authorization server, and the only ramification (other than the sec= urity issue) is not being able to claim full conformance. But such a claim = just has no real meaning of value in the consumer space, only in enterprise= /government/finance - so I doubt anyone will care if Kiva and the above ven= dors allow some clients to be less secure than ideal. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Skylar Woodward >> Sent: Friday, April 01, 2011 9:52 PM >> To: Phil Hunt >> Cc: Oleg Gryb; OAuth WG >> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) >> >> Am I the only one still supporting SHOULD on this case? If someone else >> supports this language, please speak up. Otherwise, it seems the group >> SHOULD move forward with MUST. >> >> As a provider, we (Kiva) must deal with the possibility of an ecosystem = of >> developer apps which can't feasibly serve HTTPS endpoints. =A0However, w= e're >> perfectly capable of securing credential exchange and our ecosystem with >> our own API/Network additions without holding up the working group on >> this point. =A0Alternatively, if others are interested in supporting dev= elopers >> who can't or won't establish HTTPS endpoints, I'm happy to continue the >> discussion to work toward a solution (in this working group or side thre= ad). >> >> >> >> On Apr 1, 2011, at 2:12 PM, Phil Hunt wrote: >> >> > Unfortunately neither solution suggested so far is acceptable. So a vo= te >> from my perspective is premature. >> > >> > I'd like to keep working for a new solution. >> > >> > Phil >> > phil.hunt@oracle.com >> > >> > >> > >> > >> > On 2011-04-01, at 10:51 AM, Oleg Gryb wrote: >> > >> >> It's a very interesting discussion and I think, I understand both par= ties well >> because consider myself belonging to both communities (enterprise and >> networking). Still, I would vote in favor of MUST. >> >> >> >> Considering the big size of this mailing list and the big level of en= gagement >> of its members, why don't we vote? >> >> >> >> The results of the vote should be taken into consideration by those w= ho >> writes the final version. >> >> >> >> From: Francisco Corella >> >> To: Eran Hammer-Lahav ; Mark Mcgloin >> >> >> >> Cc: OAuth WG ; oauth-bounces@ietf.org >> >> Sent: Fri, April 1, 2011 9:22:32 AM >> >> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) >> >> >> >> > So we have 2 different communities of Oauth developers that will >> >> > never agree. >> >> > >> >> > SHOULD: Typically the social networking sites that need to cater >> >> > for tail end developers by not enforcing TLS on redirect_uri. It is >> >> > a risk to think that using strong language in the spec will help >> >> > them appreciate the issues >> >> > MUST: Typically enterprise organisations (I am in this camp). They >> >> > can enforce indirectly by only supporting registered callback urls >> >> > and ensure those use TLS >> >> >> >> Security is at least as necessary to social networking sites as to >> >> enterprise sites. =A0Think about what this means for Facebook. =A0If = you >> >> are using Wifi in a cafe and use the Facebook login button to log in >> >> to any application, a hacker can easily impersonate you. >> >> >> >> By the way, is somebody from Facebook reading this? =A0If so, this is= a >> >> vulnerability that Facebook has right now, and you should do >> >> something about it. =A0At the very least you should change the exampl= es >> >> of redirect URIs in the developer documentation so that they use >> >> https rather than http. >> >> >> >> Francisco >> >> >> >> _______________________________________________ >> >> OAuth mailing 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 eran@hueniverse.com Sat Apr 2 11:45:11 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF7D3A67CF for ; Sat, 2 Apr 2011 11:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwswvEb2li0l for ; Sat, 2 Apr 2011 11:45:05 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EB23B3A6452 for ; Sat, 2 Apr 2011 11:45:04 -0700 (PDT) Received: (qmail 2819 invoked from network); 2 Apr 2011 18:46:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Apr 2011 18:46:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 2 Apr 2011 11:46:45 -0700 From: Eran Hammer-Lahav To: "fcorella@pomcor.com" , Skylar Woodward , Phil Hunt Date: Sat, 2 Apr 2011 11:46:33 -0700 Thread-Topic: [OAUTH-WG] Authorization code security issue (reframed) Thread-Index: AcvxXjVv9yGMYzPIStqycVES5ItiugABg9pA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664D9B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664D9AB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <617134.17423.qm@web55803.mail.re3.yahoo.com> In-Reply-To: <617134.17423.qm@web55803.mail.re3.yahoo.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_90C41DD21FB7C64BB94121FBBC2E7234465664D9B5P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: Oleg Gryb , OAuth WG , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 18:45:11 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664D9B5P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think your statement that 'the IETF should endorse lack of security= ' is accurate or helpful. I completely rejects the notion that a SHOULD with strong language explaini= ng the risk is any less "secure" than a MUST. The only impact of using a MUST vs. a SHOULD is that companies deploying it= without requiring TLS on the redirection endpoint will not be able to clai= m full compliance if we use a MUST, but will be able to if we use a SHOULD. RFC 2616 defines compliance as follows: An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant." If we used a SHOULD for TLS, and added such a language, it will enable the = definition of three classes of implementations: non-compliant, unconditiona= lly compliant (your definition of secure), and conditionally compliant (wha= t Facebook, Yahoo, Google, and Kiva are likely to deploy). But my point is that trying to paint the SHOULD option with strong security= guidance as 'the IETF endorsing an insecure protocol' or 'destroy the cred= ibility of OAuth outside the silly social networking circle' (I'm paraphras= ing but the spirit of the comments is accurate) is just an overblown reacti= on and scare tactic. Both options are legitimate and produce the same deployment reality. They o= nly differ in how the spec talks about security and how implementers can ta= lk about their conformance. EHL From: Francisco Corella [mailto:fcorella@pomcor.com] Sent: Saturday, April 02, 2011 10:49 AM To: Skylar Woodward; Phil Hunt; Eran Hammer-Lahav Cc: Oleg Gryb; OAuth WG; Karen P. Lewison Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) Eran, > Google, Facebook, and Yahoo! already indicated they will not enforce > such a MUST. I could not get a clear answer from Twitter. > > However, no one representing this companies has bothered to express > this view on the list, and to express how they would like the > specification to handle this case. This is why I stopped advocating > for it (personally, my own product is already end-to-end TLS, and when > we open it up for developers, will not enforce it for personal > installations). Good. The IETF is not a consortium of companies. What the WG should debate is whether the IETF should endorse lack of security. Francisco --_000_90C41DD21FB7C64BB94121FBBC2E7234465664D9B5P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I donR= 17;t think your statement that ‘the IETF should endorse lack of secur= ity’ is accurate or helpful.

 

I complete= ly rejects the notion that a SHOULD with strong language explaining the ris= k is any less “secure” than a MUST.

 

The only impact of using a MUST vs. a SHOULD is that companies deploying= it without requiring TLS on the redirection endpoint will not be able to c= laim full compliance if we use a MUST, but will be able to if we use a SHOU= LD.

 

RFC 2616 defines compliance as follows:

 

   An implementation is not compliant if it fai= ls to satisfy one or more

  = ; of the MUST or REQUIRED level requirements for the protocols it

   implements. An implementation tha= t satisfies all the MUST or REQUIRED

=    level and all the SHOULD level requirements for its protocols = is said

   to be "unco= nditionally compliant"; one that satisfies all the MUST

   level requirements but not all the SHO= ULD level requirements for its

 =   protocols is said to be "conditionally compliant."

 

If we used a SHOULD for TLS, and added such a langua= ge, it will enable the definition of three classes of implementations: non-= compliant, unconditionally compliant (your definition of secure), and condi= tionally compliant (what Facebook, Yahoo, Google, and Kiva are likely to de= ploy).

 

But my point is that trying to paint t= he SHOULD option with strong security guidance as ‘the IETF endorsing= an insecure protocol’ or ‘destroy the credibility of OAuth out= side the silly social networking circle’ (I’m paraphrasing but = the spirit of the comments is accurate) is just an overblown reaction and s= care tactic.

 

Both options are legitimate and = produce the same deployment reality. They only differ in how the spec talks= about security and how implementers can talk about their conformance.=

 

EHL

 

 

 

From: Francisco Corella [mailto:fcorella@= pomcor.com]
Sent: Saturday, April 02, 2011 10:49 AM
To: Skylar Woodward; Phil Hunt; Eran Hammer-Lahav
Cc: Oleg Gryb; OA= uth WG; Karen P. Lewison
Subject: Re: [OAUTH-WG] Authorization co= de security issue (reframed)

 

Eran,

>= ; Google, Facebook, and Yahoo! already indicated they will not enforce
&= gt; such a MUST. I could not get a clear answer from Twitter.
>
&= gt; However, no one representing this companies has bothered to express
= > this view on the list, and to express how they would like the
> = specification to handle this case. This is why I stopped advocating
>= for it (personally, my own product is already end-to-end TLS, and when
= > we open it up for developers, will not enforce it for personal
>= installations).

Good.  The IETF is not a consortium of compani= es.  What the WG should
debate is whether the IETF should endorse l= ack of security.

Francisco

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664D9B5P3PW5EX1MB01E_-- From eran@hueniverse.com Sat Apr 2 12:05:25 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4483A63EC for ; Sat, 2 Apr 2011 12:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7b23qHY8W1m for ; Sat, 2 Apr 2011 12:05:24 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 956053A63D2 for ; Sat, 2 Apr 2011 12:05:24 -0700 (PDT) Received: (qmail 6925 invoked from network); 2 Apr 2011 19:07:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Apr 2011 19:07:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 2 Apr 2011 12:07:05 -0700 From: Eran Hammer-Lahav To: "fcorella@pomcor.com" , Dick Hardt , Skylar Woodward , Phillip Hunt Date: Sat, 2 Apr 2011 12:06:54 -0700 Thread-Topic: to TLS or not on redirect on consumer websites :: security considerations Thread-Index: AcvxYbVukz7A9XW8QTOYKptFxvL1LwABXmpg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664D9B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664D9AD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <81117.51614.qm@web55802.mail.re3.yahoo.com> In-Reply-To: <81117.51614.qm@web55802.mail.re3.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG , "Karen P. Lewison" Subject: Re: [OAUTH-WG] to TLS or not on redirect on consumer websites :: security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 19:05:25 -0000 > -----Original Message----- > From: Francisco Corella [mailto:fcorella@pomcor.com] > Sent: Saturday, April 02, 2011 11:14 AM > To: Dick Hardt; Skylar Woodward; Phillip Hunt; Eran Hammer-Lahav > Cc: OAuth WG; Karen P. Lewison > Subject: RE: to TLS or not on redirect on consumer websites :: security > considerations >=20 > > Another example I mentioned earlier is when the client does not expose > > the protected resources back to the bearer of the code. For example, a > > Twitter application sending you emails when someone stops following > > you. Since all it does is get the code and then uses it internally (no > > user login functionality), TLS adds NOTHING. >=20 > I'm not sure I understand the example.=A0 Would the attacker be able to g= et > emails when someone stops following the user? > Would that be OK? No. The attacker will accomplish nothing other than to finish the flow on b= ehalf of the legitimate user. 1. User is asked for email where to notify 2. User is redirected to Twitter to grant access 3. Someone comes back to the client with a valid code 4. Client uses code to get an access token and does not expose any data to = the entity delivering the code > Anyway, an application that accesses Twitter on the user's behalf is like= ly to > be able to send tweets on the user's behalf.=A0 The attacks we've been > discussing would allow the attacker to send tweets on the user's > behalf.=A0 That's definitely not cool. >=20 > User impersonation when Oauth is used for social login is not the only > consequence of not requiring TSL for the callback endpoint. The only consequence is compromising the *client* login/authentication secu= rity. I'm not trying to play it down, but I we need to be clear. This is no= t a compromise of the protected resources or authorization server. In your examples, it is done via stealing the authorization code. In other = examples (due to the same lack of TLS security on the client) it is due to = setting insecure session cookies. Any kind of incomplete client security is= bad and will produce the exact same attack opportunities if it enables a M= ITM to interject itself into any of the client's login or authentication fl= ows. IOW, for this security hole to be closed, clients MUST use TLS throughout t= he entire site, not just their redirection. You are demanding that the enti= re web moved to use TLS for all login and authentication of bearer credenti= als. That's a good goal, but the issue at hand is not whether the attacks a= re valid - they are. It is only what is the best LANGUAGE to use in order t= o move the web forward. Your solution is to force offenders to explicitly violate the protocol, but= other's suggesting a more relax approach will produce the same result over= time. The problem with your approach is that it already failed. Enough hig= h profile companies on the consumer web front have said that they plan to i= gnore this MUST. I think it is much better for the future of web security f= or this document to reflect reality and find more productive ways to impact= change. EHL From phil.hunt@oracle.com Sat Apr 2 12:18:07 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6103A67EF for ; Sat, 2 Apr 2011 12:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.863 X-Spam-Level: X-Spam-Status: No, score=-5.863 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru3E7rAJyFj0 for ; Sat, 2 Apr 2011 12:18:06 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 929CA3A6783 for ; Sat, 2 Apr 2011 12:18:06 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p32JJi0w000904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Apr 2011 19:19:45 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p32JJhDc012558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Apr 2011 19:19:43 GMT Received: from abhmt014.oracle.com (abhmt014.oracle.com [141.146.116.23]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p32JJgmE004446; Sat, 2 Apr 2011 14:19:42 -0500 Received: from [192.168.1.71] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 02 Apr 2011 12:19:42 -0700 References: <90C41DD21FB7C64BB94121FBBC2E7234465664D9AB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <617134.17423.qm@web55803.mail.re3.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234465664D9B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664D9B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Type: multipart/alternative; boundary=Apple-Mail-6--805250147 Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (8G4) From: Phillip Hunt Date: Sat, 2 Apr 2011 12:19:37 -0700 To: Eran Hammer-Lahav X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4D9776D0.0054:SCFSTAT5015188, ss=1, pt=DBB_66871, fgs=0 Cc: Oleg Gryb , OAuth WG , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 19:18:07 -0000 --Apple-Mail-6--805250147 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For the record, I can except SHOULD. But my very strong feeling is this lead= s to much more lengthy and complicated language. I believe we have already crossed the line where it is no longer easy for de= ployers to figure out if deployments are secure. It is now a spec challengin= g to even subject matter experts.=20 If we take the current implementers as evidence it shows we have little or n= o security either due to misunderstandings or business decisions to accept r= isk for flexibility.=20 It is not time to be idealistic but rather realistic.=20 It looks to me that it is time to either redo authorization to avoid TLS (so= mehow) or consider splitting into secure/non-secure profiles to satisfy ever= yone's needs. (not my preference) Any other ideas? Phil Sent from my phone.=20 On 2011-04-02, at 11:46, Eran Hammer-Lahav wrote: > I don=E2=80=99t think your statement that =E2=80=98the IETF should endorse= lack of security=E2=80=99 is accurate or helpful. >=20 > =20 >=20 > I completely rejects the notion that a SHOULD with strong language explain= ing the risk is any less =E2=80=9Csecure=E2=80=9D than a MUST. >=20 > =20 >=20 > The only impact of using a MUST vs. a SHOULD is that companies deploying i= t without requiring TLS on the redirection endpoint will not be able to clai= m full compliance if we use a MUST, but will be able to if we use a SHOULD. >=20 > =20 >=20 > RFC 2616 defines compliance as follows: >=20 > =20 >=20 > An implementation is not compliant if it fails to satisfy one or more >=20 > of the MUST or REQUIRED level requirements for the protocols it >=20 > implements. An implementation that satisfies all the MUST or REQUIRED >=20 > level and all the SHOULD level requirements for its protocols is said >=20 > to be "unconditionally compliant"; one that satisfies all the MUST >=20 > level requirements but not all the SHOULD level requirements for its >=20 > protocols is said to be "conditionally compliant." >=20 > =20 >=20 > If we used a SHOULD for TLS, and added such a language, it will enable the= definition of three classes of implementations: non-compliant, unconditiona= lly compliant (your definition of secure), and conditionally compliant (what= Facebook, Yahoo, Google, and Kiva are likely to deploy). >=20 > =20 >=20 > But my point is that trying to paint the SHOULD option with strong securit= y guidance as =E2=80=98the IETF endorsing an insecure protocol=E2=80=99 or =E2= =80=98destroy the credibility of OAuth outside the silly social networking c= ircle=E2=80=99 (I=E2=80=99m paraphrasing but the spirit of the comments is a= ccurate) is just an overblown reaction and scare tactic. >=20 > =20 >=20 > Both options are legitimate and produce the same deployment reality. They o= nly differ in how the spec talks about security and how implementers can tal= k about their conformance. >=20 > =20 >=20 > EHL >=20 > =20 >=20 > =20 >=20 > =20 >=20 > From: Francisco Corella [mailto:fcorella@pomcor.com]=20 > Sent: Saturday, April 02, 2011 10:49 AM > To: Skylar Woodward; Phil Hunt; Eran Hammer-Lahav > Cc: Oleg Gryb; OAuth WG; Karen P. Lewison > Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) >=20 > =20 >=20 > Eran, >=20 > > Google, Facebook, and Yahoo! already indicated they will not enforce > > such a MUST. I could not get a clear answer from Twitter. > >=20 > > However, no one representing this companies has bothered to express > > this view on the list, and to express how they would like the > > specification to handle this case. This is why I stopped advocating > > for it (personally, my own product is already end-to-end TLS, and when > > we open it up for developers, will not enforce it for personal > > installations). >=20 > Good. The IETF is not a consortium of companies. What the WG should > debate is whether the IETF should endorse lack of security. >=20 > Francisco >=20 > =20 --Apple-Mail-6--805250147 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
For the record, I can except SHOULD. Bu= t my very strong feeling is this leads to much more lengthy and complicated l= anguage.

I believe we have already crossed the line= where it is no longer easy for deployers to figure out if deployments are s= ecure. It is now a spec challenging to even subject matter experts. 

If we take the current implementers as evidence it sh= ows we have little or no security either due to misunderstandings or busines= s decisions to accept risk for flexibility. 

I= t is not time to be idealistic but rather realistic. 

It looks to me that it is time to either redo authorization to avoid= TLS (somehow) or consider splitting into secure/non-secure profiles to sati= sfy everyone's needs. (not my preference)

Any other= ideas?

Phil

Sent from my phone. 

On 2011-04-02, at 11:46, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I don=E2=80=99t think your statemen= t that =E2=80=98the IETF should endorse lack of security=E2=80=99 is accurat= e or helpful.

 

I completely rejects the notion that a SHOULD with strong language e= xplaining the risk is any less =E2=80=9Csecure=E2=80=9D than a MUST.

 

The only imp= act of using a MUST vs. a SHOULD is that companies deploying it without requ= iring TLS on the redirection endpoint will not be able to claim full complia= nce if we use a MUST, but will be able to if we use a SHOULD.

 

RFC 2616 defines co= mpliance as follows:

 

 = ;  An implementation is not compliant if it fails to satisfy one or mor= e

   of the MUST o= r REQUIRED level requirements for the protocols it

   implements. An implementation that sati= sfies all the MUST or REQUIRED

<= span style=3D"font-size:10.0pt;font-family:"Courier New";color:bla= ck">   level and all the SHOULD level requirements for its protoco= ls is said

   to b= e "unconditionally compliant"; one that satisfies all the MUST

   level requirements but not a= ll the SHOULD level requirements for its

   protocols is said to be "conditionally compliant.= "

 

If w= e used a SHOULD for TLS, and added such a language, it will enable the defin= ition of three classes of implementations: non-compliant, unconditionally co= mpliant (your definition of secure), and conditionally compliant (what Faceb= ook, Yahoo, Google, and Kiva are likely to deploy).

 

But my point is that trying to p= aint the SHOULD option with strong security guidance as =E2=80=98the IETF en= dorsing an insecure protocol=E2=80=99 or =E2=80=98destroy the credibility of= OAuth outside the silly social networking circle=E2=80=99 (I=E2=80=99m para= phrasing but the spirit of the comments is accurate) is just an overblown re= action and scare tactic.

 

Both options are legitimate and produce the same deployme= nt reality. They only differ in how the spec talks about security and how im= plementers can talk about their conformance.

 

EHL

 

 

 

From: Fra= ncisco Corella [mailto:fcorella@pomcor.com]
Sent: Saturday, April= 02, 2011 10:49 AM
To: Skylar Woodward; Phil Hunt; Eran Hammer-Lah= av
Cc: Oleg Gryb; OAuth WG; Karen P. Lewison
Subject: Re= : [OAUTH-WG] Authorization code security issue (reframed)<= /p>

 

<= td valign=3D"top" style=3D"padding:0in 0in 0in 0in">

Eran,

> Google, Facebook, and Yahoo!= already indicated they will not enforce
> such a MUST. I could not ge= t a clear answer from Twitter.
>
> However, no one representing= this companies has bothered to express
> this view on the list, and t= o express how they would like the
> specification to handle this case.= This is why I stopped advocating
> for it (personally, my own product= is already end-to-end TLS, and when
> we open it up for developers, w= ill not enforce it for personal
> installations).

Good.  T= he IETF is not a consortium of companies.  What the WG should
debate= is whether the IETF should endorse lack of security.

Francisco<= /o:p>

&= nbsp;

= --Apple-Mail-6--805250147-- From eran@hueniverse.com Sat Apr 2 12:45:38 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A293A6840 for ; Sat, 2 Apr 2011 12:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtuXAoXYnOAK for ; Sat, 2 Apr 2011 12:45:37 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BE2D23A688A for ; Sat, 2 Apr 2011 12:45:36 -0700 (PDT) Received: (qmail 25819 invoked from network); 2 Apr 2011 19:47:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Apr 2011 19:47:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 2 Apr 2011 12:47:13 -0700 From: Eran Hammer-Lahav To: Phillip Hunt Date: Sat, 2 Apr 2011 12:47:02 -0700 Thread-Topic: [OAUTH-WG] Authorization code security issue (reframed) Thread-Index: Acvxau6t+IVGLGZHRl+NGUhhVxnuOgAAUKlw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664D9B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664D9AB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <617134.17423.qm@web55803.mail.re3.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234465664D9B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664D9B8P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: Oleg Gryb , OAuth WG , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 19:45:38 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664D9B8P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHRoaW5rIGEgU0hPVUxEIGxlYWRzIHRvIG1vcmUgdGhhbiAyLTMgbGluZXMgY2xl YXJseSB3YXJuaW5nIGFnYWluc3QgYSBNSVRNIGF0dGFjayBvbiB0aGUgYXV0aG9yaXphdGlvbiBj b2RlIG9yIHRoZSByZXR1cm5lZCBzY3JpcHQgKGltcGxpY2l0IGdyYW50KS4gVGhlIGF0dGFjayBp cyBzaW1wbGUgYW5kIHRoZSB3YXJuaW5nIGlzIGVxdWFsbHkgc2ltcGxlLg0KDQpEaWZmZXJlbnQg Y29tcG9uZW50cyBvZiB0aGUgcHJvdG9jb2wgaGF2ZSBkaWZmZXJlbnQgc2VjdXJpdHkgaXNzdWVz IGFuZCBjb21wbGV4aXR5LiBUaGlzIGlzIGp1c3QgdGhlIG5hdHVyZSBvZiB0aGUgd29yayB3aGVy ZSBtYW55IGRpZmZlcmVudCBwYXJ0aWVzIHdpdGggdmFzdGx5IGRpZmZlcmVudCBuZWVkcyBhcmUg dHJ5aW5nIHRvIGNyZWF0ZSBhIHNpbmdsZSBmcmFtZXdvcmsuIFRoZSBiZXN0IGV4YW1wbGUgb2Yg dGhpcyBkaXZlcnNpdHkgYXJlIHRoZSB0d28gd2F5cyBwZW9wbGUgYXJlIGFza2luZyB0aGUgcHJv dG9jb2wgdG8gc3VwcG9ydCBjbGllbnQgYXV0aGVudGljYXRpb246IHBhc3N3b3JkIGFuZCBhbiBh c3NlcnRpb24gbWV0aG9kLiBJdCBpcyB0cml2aWFsIHRvIHdyaXRlIGFib3V0IHRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBvZiBhIHBhc3N3b3JkLCBpdCBpcyBub3QgdG8gd3JpdGUgYSBjb21w bGV0ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGFib3V0IGNsaWVudCBhc3NlcnRpb24gYXV0aGVu dGljYXRpb24sIHVubGVzcyB0aGUgbGlzdCBvZiBzdXBwb3J0ZWQgYXNzZXJ0aW9ucyBpcyB3ZWxs IGRlZmluZWQgKHdoaWNoIHdvdWxkIGRlZmVhdCB0aGUgZ29hbHMgb2YgdGhvc2UgcmVxdWVzdGlu ZyB0aGlzKS4NCg0KVGhpcyB3b3JrIGxlYXZlcyBtdWNoIHVuc3BlY2lmaWVkIGFuZCB0aGVyZWZv cmUgd2lsbCBuZWVkIHRvIGJlIHByb2ZpbGVkIG9yIGV4dGVuZGVkLiBJdCBpcyB0aGUgbmF0dXJl IG9mIGJ1aWxkaW5nIGEgZnJhbWV3b3JrLCBub3QgYSBmaW5pdGUgcHJvdG9jb2wgKHdoaWNoIGlz IHdoYXQgMS4wIGlzKS4gQnkgZGVmaW5pdGlvbiwgYSBmcmFtZXdvcmsgaXMganVzdCB0aGUgZm91 bmRhdGlvbiBhbmQgaGFzIGxpbWl0ZWQgd2VsbC1kZWZpbmVkIHByb3BlcnRpZXMuDQoNCjxyYW50 Pg0KUGVyc29uYWxseSwgSSBmaW5kIG1vc3Qgb2YgdGhlIGVudGVycHJpc2UgcmVxdWlyZW1lbnRz IGZvciBPQXV0aCB0byBiZSBhbiBhYm9taW5hdGlvbi4gVGhlIG5vbi1jb25zdW1lciB3ZWIgd29y bGQgaGFzIGhpamFja2VkIGEgc3VjY2Vzc2Z1bCBjb21tdW5pdHkgcHJvdG9jb2wgYW5kIGFkZGVk IHNvIG11Y2ggY3JhcCB0byBpdCBzbyB0aGF0IHRoZXkgY2FuIHdoaXRld2FzaCB0aGVpciBvd24g cHJvcHJpZXRhcnkgcHJvdG9jb2xzIGFuZCBhcHBlYXIgbW9yZSBvcGVuIGFuZCB0cmVuZHkuIFNp bmNlIHRoaXMgaXMgYW4gSUVURiB3b3JraW5nIGdyb3VwLCB0aGVyZSBpcyBub3RoaW5nIEkgY2Fu IGRvIGFib3V0IGl0IGhlcmUsIG90aGVyIHRoYW4gdHJ5IHRvIGtlZXAgc3R1ZmYgb3V0IG9mIHRo ZSB2MiBzcGVjaWZpY2F0aW9uIHRocm91Z2ggY29uc2Vuc3VzLg0KDQpCdXQgdGhlIGVudGVycHJp c2Ugd29ybGQgY2Fu4oCZdCBjb21wbGFpbiBhYm91dCB0aGlzIHByb3RvY29sIG5vdCBtZWFzdXJp bmcgdXAgdG8gdGhlaXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIHdoZW4gaXQgd2FzIG5ldmVyIG1l YW50IHRvIGJlIGFuIGVudGVycHJpc2UgcHJvdG9jb2wuIEl0IHdhcyBhICp3ZWIqIGFwcGxpY2F0 aW9uIHByb3RvY29sLiBUaGUgcmVjZW50IG1vdmUgZnJvbSB0aGUgYXBwbGljYXRpb24gYXJlYSB0 byB0aGUgc2VjdXJpdHkgYXJlYSBpcyB0aGUgbW9zdCByZWNlbnQgZGVtb25zdHJhdGlvbiBvZiBo b3cgZmFyIHRoaXMgd29yayBoYXMgbW92ZWQgZnJvbSBpdHMgb3JpZ2luYWwgdXNlIGNhc2VzICh3 aGVuIHRoaXMgV0cgd2FzIGNyZWF0ZWQpLg0KPC9yYW50Pg0KDQpFSEwNCg0KRnJvbTogUGhpbGxp cCBIdW50IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQpTZW50OiBTYXR1cmRheSwgQXBy aWwgMDIsIDIwMTEgMTI6MjAgUE0NClRvOiBFcmFuIEhhbW1lci1MYWhhdg0KQ2M6IGZjb3JlbGxh QHBvbWNvci5jb207IFNreWxhciBXb29kd2FyZDsgT2xlZyBHcnliOyBPQXV0aCBXRzsgS2FyZW4g UC4gTGV3aXNvbg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQXV0aG9yaXphdGlvbiBjb2RlIHNl Y3VyaXR5IGlzc3VlIChyZWZyYW1lZCkNCg0KRm9yIHRoZSByZWNvcmQsIEkgY2FuIGV4Y2VwdCBT SE9VTEQuIEJ1dCBteSB2ZXJ5IHN0cm9uZyBmZWVsaW5nIGlzIHRoaXMgbGVhZHMgdG8gbXVjaCBt b3JlIGxlbmd0aHkgYW5kIGNvbXBsaWNhdGVkIGxhbmd1YWdlLg0KDQpJIGJlbGlldmUgd2UgaGF2 ZSBhbHJlYWR5IGNyb3NzZWQgdGhlIGxpbmUgd2hlcmUgaXQgaXMgbm8gbG9uZ2VyIGVhc3kgZm9y IGRlcGxveWVycyB0byBmaWd1cmUgb3V0IGlmIGRlcGxveW1lbnRzIGFyZSBzZWN1cmUuIEl0IGlz IG5vdyBhIHNwZWMgY2hhbGxlbmdpbmcgdG8gZXZlbiBzdWJqZWN0IG1hdHRlciBleHBlcnRzLg0K DQpJZiB3ZSB0YWtlIHRoZSBjdXJyZW50IGltcGxlbWVudGVycyBhcyBldmlkZW5jZSBpdCBzaG93 cyB3ZSBoYXZlIGxpdHRsZSBvciBubyBzZWN1cml0eSBlaXRoZXIgZHVlIHRvIG1pc3VuZGVyc3Rh bmRpbmdzIG9yIGJ1c2luZXNzIGRlY2lzaW9ucyB0byBhY2NlcHQgcmlzayBmb3IgZmxleGliaWxp dHkuDQoNCkl0IGlzIG5vdCB0aW1lIHRvIGJlIGlkZWFsaXN0aWMgYnV0IHJhdGhlciByZWFsaXN0 aWMuDQoNCkl0IGxvb2tzIHRvIG1lIHRoYXQgaXQgaXMgdGltZSB0byBlaXRoZXIgcmVkbyBhdXRo b3JpemF0aW9uIHRvIGF2b2lkIFRMUyAoc29tZWhvdykgb3IgY29uc2lkZXIgc3BsaXR0aW5nIGlu dG8gc2VjdXJlL25vbi1zZWN1cmUgcHJvZmlsZXMgdG8gc2F0aXNmeSBldmVyeW9uZSdzIG5lZWRz LiAobm90IG15IHByZWZlcmVuY2UpDQoNCkFueSBvdGhlciBpZGVhcz8NCg0KUGhpbA0KDQpTZW50 IGZyb20gbXkgcGhvbmUuDQoNCk9uIDIwMTEtMDQtMDIsIGF0IDExOjQ2LCBFcmFuIEhhbW1lci1M YWhhdiA8ZXJhbkBodWVuaXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+IHdy b3RlOg0KSSBkb27igJl0IHRoaW5rIHlvdXIgc3RhdGVtZW50IHRoYXQg4oCYdGhlIElFVEYgc2hv dWxkIGVuZG9yc2UgbGFjayBvZiBzZWN1cml0eeKAmSBpcyBhY2N1cmF0ZSBvciBoZWxwZnVsLg0K DQpJIGNvbXBsZXRlbHkgcmVqZWN0cyB0aGUgbm90aW9uIHRoYXQgYSBTSE9VTEQgd2l0aCBzdHJv bmcgbGFuZ3VhZ2UgZXhwbGFpbmluZyB0aGUgcmlzayBpcyBhbnkgbGVzcyDigJxzZWN1cmXigJ0g dGhhbiBhIE1VU1QuDQoNClRoZSBvbmx5IGltcGFjdCBvZiB1c2luZyBhIE1VU1QgdnMuIGEgU0hP VUxEIGlzIHRoYXQgY29tcGFuaWVzIGRlcGxveWluZyBpdCB3aXRob3V0IHJlcXVpcmluZyBUTFMg b24gdGhlIHJlZGlyZWN0aW9uIGVuZHBvaW50IHdpbGwgbm90IGJlIGFibGUgdG8gY2xhaW0gZnVs bCBjb21wbGlhbmNlIGlmIHdlIHVzZSBhIE1VU1QsIGJ1dCB3aWxsIGJlIGFibGUgdG8gaWYgd2Ug dXNlIGEgU0hPVUxELg0KDQpSRkMgMjYxNiBkZWZpbmVzIGNvbXBsaWFuY2UgYXMgZm9sbG93czoN Cg0KICAgQW4gaW1wbGVtZW50YXRpb24gaXMgbm90IGNvbXBsaWFudCBpZiBpdCBmYWlscyB0byBz YXRpc2Z5IG9uZSBvciBtb3JlDQogICBvZiB0aGUgTVVTVCBvciBSRVFVSVJFRCBsZXZlbCByZXF1 aXJlbWVudHMgZm9yIHRoZSBwcm90b2NvbHMgaXQNCiAgIGltcGxlbWVudHMuIEFuIGltcGxlbWVu dGF0aW9uIHRoYXQgc2F0aXNmaWVzIGFsbCB0aGUgTVVTVCBvciBSRVFVSVJFRA0KICAgbGV2ZWwg YW5kIGFsbCB0aGUgU0hPVUxEIGxldmVsIHJlcXVpcmVtZW50cyBmb3IgaXRzIHByb3RvY29scyBp cyBzYWlkDQogICB0byBiZSAidW5jb25kaXRpb25hbGx5IGNvbXBsaWFudCI7IG9uZSB0aGF0IHNh dGlzZmllcyBhbGwgdGhlIE1VU1QNCiAgIGxldmVsIHJlcXVpcmVtZW50cyBidXQgbm90IGFsbCB0 aGUgU0hPVUxEIGxldmVsIHJlcXVpcmVtZW50cyBmb3IgaXRzDQogICBwcm90b2NvbHMgaXMgc2Fp ZCB0byBiZSAiY29uZGl0aW9uYWxseSBjb21wbGlhbnQuIg0KDQpJZiB3ZSB1c2VkIGEgU0hPVUxE IGZvciBUTFMsIGFuZCBhZGRlZCBzdWNoIGEgbGFuZ3VhZ2UsIGl0IHdpbGwgZW5hYmxlIHRoZSBk ZWZpbml0aW9uIG9mIHRocmVlIGNsYXNzZXMgb2YgaW1wbGVtZW50YXRpb25zOiBub24tY29tcGxp YW50LCB1bmNvbmRpdGlvbmFsbHkgY29tcGxpYW50ICh5b3VyIGRlZmluaXRpb24gb2Ygc2VjdXJl KSwgYW5kIGNvbmRpdGlvbmFsbHkgY29tcGxpYW50ICh3aGF0IEZhY2Vib29rLCBZYWhvbywgR29v Z2xlLCBhbmQgS2l2YSBhcmUgbGlrZWx5IHRvIGRlcGxveSkuDQoNCkJ1dCBteSBwb2ludCBpcyB0 aGF0IHRyeWluZyB0byBwYWludCB0aGUgU0hPVUxEIG9wdGlvbiB3aXRoIHN0cm9uZyBzZWN1cml0 eSBndWlkYW5jZSBhcyDigJh0aGUgSUVURiBlbmRvcnNpbmcgYW4gaW5zZWN1cmUgcHJvdG9jb2zi gJkgb3Ig4oCYZGVzdHJveSB0aGUgY3JlZGliaWxpdHkgb2YgT0F1dGggb3V0c2lkZSB0aGUgc2ls bHkgc29jaWFsIG5ldHdvcmtpbmcgY2lyY2xl4oCZIChJ4oCZbSBwYXJhcGhyYXNpbmcgYnV0IHRo ZSBzcGlyaXQgb2YgdGhlIGNvbW1lbnRzIGlzIGFjY3VyYXRlKSBpcyBqdXN0IGFuIG92ZXJibG93 biByZWFjdGlvbiBhbmQgc2NhcmUgdGFjdGljLg0KDQpCb3RoIG9wdGlvbnMgYXJlIGxlZ2l0aW1h dGUgYW5kIHByb2R1Y2UgdGhlIHNhbWUgZGVwbG95bWVudCByZWFsaXR5LiBUaGV5IG9ubHkgZGlm ZmVyIGluIGhvdyB0aGUgc3BlYyB0YWxrcyBhYm91dCBzZWN1cml0eSBhbmQgaG93IGltcGxlbWVu dGVycyBjYW4gdGFsayBhYm91dCB0aGVpciBjb25mb3JtYW5jZS4NCg0KRUhMDQoNCg0KDQpGcm9t OiBGcmFuY2lzY28gQ29yZWxsYSBbbWFpbHRvOmZjb3JlbGxhQHBvbWNvci5jb21dDQpTZW50OiBT YXR1cmRheSwgQXByaWwgMDIsIDIwMTEgMTA6NDkgQU0NClRvOiBTa3lsYXIgV29vZHdhcmQ7IFBo aWwgSHVudDsgRXJhbiBIYW1tZXItTGFoYXYNCkNjOiBPbGVnIEdyeWI7IE9BdXRoIFdHOyBLYXJl biBQLiBMZXdpc29uDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBdXRob3JpemF0aW9uIGNvZGUg c2VjdXJpdHkgaXNzdWUgKHJlZnJhbWVkKQ0KDQpFcmFuLA0KDQo+IEdvb2dsZSwgRmFjZWJvb2ss IGFuZCBZYWhvbyEgYWxyZWFkeSBpbmRpY2F0ZWQgdGhleSB3aWxsIG5vdCBlbmZvcmNlDQo+IHN1 Y2ggYSBNVVNULiBJIGNvdWxkIG5vdCBnZXQgYSBjbGVhciBhbnN3ZXIgZnJvbSBUd2l0dGVyLg0K Pg0KPiBIb3dldmVyLCBubyBvbmUgcmVwcmVzZW50aW5nIHRoaXMgY29tcGFuaWVzIGhhcyBib3Ro ZXJlZCB0byBleHByZXNzDQo+IHRoaXMgdmlldyBvbiB0aGUgbGlzdCwgYW5kIHRvIGV4cHJlc3Mg aG93IHRoZXkgd291bGQgbGlrZSB0aGUNCj4gc3BlY2lmaWNhdGlvbiB0byBoYW5kbGUgdGhpcyBj YXNlLiBUaGlzIGlzIHdoeSBJIHN0b3BwZWQgYWR2b2NhdGluZw0KPiBmb3IgaXQgKHBlcnNvbmFs bHksIG15IG93biBwcm9kdWN0IGlzIGFscmVhZHkgZW5kLXRvLWVuZCBUTFMsIGFuZCB3aGVuDQo+ IHdlIG9wZW4gaXQgdXAgZm9yIGRldmVsb3BlcnMsIHdpbGwgbm90IGVuZm9yY2UgaXQgZm9yIHBl cnNvbmFsDQo+IGluc3RhbGxhdGlvbnMpLg0KDQpHb29kLiAgVGhlIElFVEYgaXMgbm90IGEgY29u c29ydGl1bSBvZiBjb21wYW5pZXMuICBXaGF0IHRoZSBXRyBzaG91bGQNCmRlYmF0ZSBpcyB3aGV0 aGVyIHRoZSBJRVRGIHNob3VsZCBlbmRvcnNlIGxhY2sgb2Ygc2VjdXJpdHkuDQoNCkZyYW5jaXNj bw0KDQoNCg== --_000_90C41DD21FB7C64BB94121FBBC2E7234465664D9B8P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJh bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVh ZD48Ym9keSBiZ2NvbG9yPXdoaXRlIGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48 ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5JIGRvbuKAmXQgdGhpbmsgYSBTSE9VTEQgbGVhZHMgdG8gbW9yZSB0aGFuIDItMyBs aW5lcyBjbGVhcmx5IHdhcm5pbmcgYWdhaW5zdCBhIE1JVE0gYXR0YWNrIG9uIHRoZSBhdXRob3Jp emF0aW9uIGNvZGUgb3IgdGhlIHJldHVybmVkIHNjcmlwdCAoaW1wbGljaXQgZ3JhbnQpLiBUaGUg YXR0YWNrIGlzIHNpbXBsZSBhbmQgdGhlIHdhcm5pbmcgaXMgZXF1YWxseSBzaW1wbGUuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5EaWZmZXJlbnQgY29tcG9uZW50cyBvZiB0aGUgcHJvdG9jb2wgaGF2ZSBk aWZmZXJlbnQgc2VjdXJpdHkgaXNzdWVzIGFuZCBjb21wbGV4aXR5LiBUaGlzIGlzIGp1c3QgdGhl IG5hdHVyZSBvZiB0aGUgd29yayB3aGVyZSBtYW55IGRpZmZlcmVudCBwYXJ0aWVzIHdpdGggdmFz dGx5IGRpZmZlcmVudCBuZWVkcyBhcmUgdHJ5aW5nIHRvIGNyZWF0ZSBhIHNpbmdsZSBmcmFtZXdv cmsuIFRoZSBiZXN0IGV4YW1wbGUgb2YgdGhpcyBkaXZlcnNpdHkgYXJlIHRoZSB0d28gd2F5cyBw ZW9wbGUgYXJlIGFza2luZyB0aGUgcHJvdG9jb2wgdG8gc3VwcG9ydCBjbGllbnQgYXV0aGVudGlj YXRpb246IHBhc3N3b3JkIGFuZCBhbiBhc3NlcnRpb24gbWV0aG9kLiBJdCBpcyB0cml2aWFsIHRv IHdyaXRlIGFib3V0IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiBhIHBhc3N3b3JkLCBp dCBpcyBub3QgdG8gd3JpdGUgYSBjb21wbGV0ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGFib3V0 IGNsaWVudCBhc3NlcnRpb24gYXV0aGVudGljYXRpb24sIHVubGVzcyB0aGUgbGlzdCBvZiBzdXBw b3J0ZWQgYXNzZXJ0aW9ucyBpcyB3ZWxsIGRlZmluZWQgKHdoaWNoIHdvdWxkIGRlZmVhdCB0aGUg Z29hbHMgb2YgdGhvc2UgcmVxdWVzdGluZyB0aGlzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoaXMg d29yayBsZWF2ZXMgbXVjaCB1bnNwZWNpZmllZCBhbmQgdGhlcmVmb3JlIHdpbGwgbmVlZCB0byBi ZSBwcm9maWxlZCBvciBleHRlbmRlZC4gSXQgaXMgdGhlIG5hdHVyZSBvZiBidWlsZGluZyBhIGZy YW1ld29yaywgbm90IGEgZmluaXRlIHByb3RvY29sICh3aGljaCBpcyB3aGF0IDEuMCBpcykuIEJ5 IGRlZmluaXRpb24sIGEgZnJhbWV3b3JrIGlzIGp1c3QgdGhlIGZvdW5kYXRpb24gYW5kIGhhcyBs aW1pdGVkIHdlbGwtZGVmaW5lZCBwcm9wZXJ0aWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jmx0O3Jh bnQmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPlBlcnNvbmFsbHksIEkgZmluZCBtb3N0IG9mIHRoZSBlbnRlcnByaXNlIHJl cXVpcmVtZW50cyBmb3IgT0F1dGggdG8gYmUgYW4gYWJvbWluYXRpb24uIFRoZSBub24tY29uc3Vt ZXIgd2ViIHdvcmxkIGhhcyBoaWphY2tlZCBhIHN1Y2Nlc3NmdWwgY29tbXVuaXR5IHByb3RvY29s IGFuZCBhZGRlZCBzbyBtdWNoIGNyYXAgdG8gaXQgc28gdGhhdCB0aGV5IGNhbiB3aGl0ZXdhc2gg dGhlaXIgb3duIHByb3ByaWV0YXJ5IHByb3RvY29scyBhbmQgYXBwZWFyIG1vcmUgb3BlbiBhbmQg dHJlbmR5LiBTaW5jZSB0aGlzIGlzIGFuIElFVEYgd29ya2luZyBncm91cCwgdGhlcmUgaXMgbm90 aGluZyBJIGNhbiBkbyBhYm91dCBpdCBoZXJlLCBvdGhlciB0aGFuIHRyeSB0byBrZWVwIHN0dWZm IG91dCBvZiB0aGUgdjIgc3BlY2lmaWNhdGlvbiB0aHJvdWdoIGNvbnNlbnN1cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkJ1dCB0aGUgZW50ZXJwcmlzZSB3b3JsZCBjYW7igJl0IGNvbXBsYWluIGFib3V0 IHRoaXMgcHJvdG9jb2wgbm90IG1lYXN1cmluZyB1cCB0byB0aGVpciBzZWN1cml0eSByZXF1aXJl bWVudHMgd2hlbiBpdCB3YXMgbmV2ZXIgbWVhbnQgdG8gYmUgYW4gZW50ZXJwcmlzZSBwcm90b2Nv bC4gSXQgd2FzIGEgKjxiPndlYjwvYj4qIGFwcGxpY2F0aW9uIHByb3RvY29sLiBUaGUgcmVjZW50 IG1vdmUgZnJvbSB0aGUgYXBwbGljYXRpb24gYXJlYSB0byB0aGUgc2VjdXJpdHkgYXJlYSBpcyB0 aGUgbW9zdCByZWNlbnQgZGVtb25zdHJhdGlvbiBvZiBob3cgZmFyIHRoaXMgd29yayBoYXMgbW92 ZWQgZnJvbSBpdHMgb3JpZ2luYWwgdXNlIGNhc2VzICh3aGVuIHRoaXMgV0cgd2FzIGNyZWF0ZWQp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz4mbHQ7L3JhbnQmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FSEw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+IFBoaWxsaXAgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t XSA8YnI+PGI+U2VudDo8L2I+IFNhdHVyZGF5LCBBcHJpbCAwMiwgMjAxMSAxMjoyMCBQTTxicj48 Yj5Ubzo8L2I+IEVyYW4gSGFtbWVyLUxhaGF2PGJyPjxiPkNjOjwvYj4gZmNvcmVsbGFAcG9tY29y LmNvbTsgU2t5bGFyIFdvb2R3YXJkOyBPbGVnIEdyeWI7IE9BdXRoIFdHOyBLYXJlbiBQLiBMZXdp c29uPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBBdXRob3JpemF0aW9uIGNvZGUg c2VjdXJpdHkgaXNzdWUgKHJlZnJhbWVkKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+Rm9yIHRoZSByZWNvcmQsIEkgY2FuIGV4Y2VwdCBTSE9VTEQuIEJ1dCBteSB2ZXJ5 IHN0cm9uZyBmZWVsaW5nIGlzIHRoaXMgbGVhZHMgdG8gbXVjaCBtb3JlIGxlbmd0aHkgYW5kIGNv bXBsaWNhdGVkIGxhbmd1YWdlLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PkkgYmVsaWV2ZSB3ZSBoYXZlIGFscmVhZHkgY3Jvc3NlZCB0aGUgbGluZSB3aGVyZSBpdCBpcyBu byBsb25nZXIgZWFzeSBmb3IgZGVwbG95ZXJzIHRvIGZpZ3VyZSBvdXQgaWYgZGVwbG95bWVudHMg YXJlIHNlY3VyZS4gSXQgaXMgbm93IGEgc3BlYyBjaGFsbGVuZ2luZyB0byBldmVuIHN1YmplY3Qg bWF0dGVyIGV4cGVydHMuJm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+SWYgd2UgdGFrZSB0aGUgY3VycmVudCBpbXBsZW1lbnRlcnMgYXMgZXZpZGVuY2UgaXQgc2hv d3Mgd2UgaGF2ZSBsaXR0bGUgb3Igbm8gc2VjdXJpdHkgZWl0aGVyIGR1ZSB0byBtaXN1bmRlcnN0 YW5kaW5ncyBvciBidXNpbmVzcyBkZWNpc2lvbnMgdG8gYWNjZXB0IHJpc2sgZm9yIGZsZXhpYmls aXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkl0IGlzIG5v dCB0aW1lIHRvIGJlIGlkZWFsaXN0aWMgYnV0IHJhdGhlciByZWFsaXN0aWMuJm5ic3A7PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SXQgbG9va3MgdG8gbWUgdGhhdCBpdCBp cyB0aW1lIHRvIGVpdGhlciByZWRvIGF1dGhvcml6YXRpb24gdG8gYXZvaWQgVExTIChzb21laG93 KSBvciBjb25zaWRlciBzcGxpdHRpbmcgaW50byBzZWN1cmUvbm9uLXNlY3VyZSBwcm9maWxlcyB0 byBzYXRpc2Z5IGV2ZXJ5b25lJ3MgbmVlZHMuIChub3QgbXkgcHJlZmVyZW5jZSk8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Bbnkgb3RoZXIgaWRlYXM/PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPlBoaWw8bzpwPjwvbzpwPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5TZW50IGZyb20gbXkgcGhvbmUuJm5ic3A7PG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206 MTIuMHB0Jz48YnI+T24gMjAxMS0wNC0wMiwgYXQgMTE6NDYsIEVyYW4gSGFtbWVyLUxhaGF2ICZs dDs8YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+ZXJhbkBodWVuaXZlcnNlLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgZG9u4oCZdCB0aGluayB5b3VyIHN0 YXRlbWVudCB0aGF0IOKAmHRoZSBJRVRGIHNob3VsZCBlbmRvcnNlIGxhY2sgb2Ygc2VjdXJpdHni gJkgaXMgYWNjdXJhdGUgb3IgaGVscGZ1bC48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGNvbXBs ZXRlbHkgcmVqZWN0cyB0aGUgbm90aW9uIHRoYXQgYSBTSE9VTEQgd2l0aCBzdHJvbmcgbGFuZ3Vh Z2UgZXhwbGFpbmluZyB0aGUgcmlzayBpcyBhbnkgbGVzcyDigJxzZWN1cmXigJ0gdGhhbiBhIE1V U1QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIG9ubHkgaW1wYWN0IG9mIHVzaW5nIGEgTVVT VCB2cy4gYSBTSE9VTEQgaXMgdGhhdCBjb21wYW5pZXMgZGVwbG95aW5nIGl0IHdpdGhvdXQgcmVx dWlyaW5nIFRMUyBvbiB0aGUgcmVkaXJlY3Rpb24gZW5kcG9pbnQgd2lsbCBub3QgYmUgYWJsZSB0 byBjbGFpbSBmdWxsIGNvbXBsaWFuY2UgaWYgd2UgdXNlIGEgTVVTVCwgYnV0IHdpbGwgYmUgYWJs ZSB0byBpZiB3ZSB1c2UgYSBTSE9VTEQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UkZDIDI2MTYg ZGVmaW5lcyBjb21wbGlhbmNlIGFzIGZvbGxvd3M6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyBB biBpbXBsZW1lbnRhdGlvbiBpcyBub3QgY29tcGxpYW50IGlmIGl0IGZhaWxzIHRvIHNhdGlzZnkg b25lIG9yIG1vcmU8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xv cjpibGFjayc+Jm5ic3A7Jm5ic3A7IG9mIHRoZSBNVVNUIG9yIFJFUVVJUkVEIGxldmVsIHJlcXVp cmVtZW50cyBmb3IgdGhlIHByb3RvY29scyBpdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciO2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgaW1wbGVtZW50cy4gQW4gaW1w bGVtZW50YXRpb24gdGhhdCBzYXRpc2ZpZXMgYWxsIHRoZSBNVVNUIG9yIFJFUVVJUkVEPC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPiZuYnNwOyZu YnNwOyBsZXZlbCBhbmQgYWxsIHRoZSBTSE9VTEQgbGV2ZWwgcmVxdWlyZW1lbnRzIGZvciBpdHMg cHJvdG9jb2xzIGlzIHNhaWQ8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijtjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7IHRvIGJlICZxdW90O3VuY29uZGl0aW9uYWxseSBj b21wbGlhbnQmcXVvdDs7IG9uZSB0aGF0IHNhdGlzZmllcyBhbGwgdGhlIE1VU1Q8L3NwYW4+PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7 IGxldmVsIHJlcXVpcmVtZW50cyBidXQgbm90IGFsbCB0aGUgU0hPVUxEIGxldmVsIHJlcXVpcmVt ZW50cyBmb3IgaXRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29s b3I6YmxhY2snPiZuYnNwOyZuYnNwOyBwcm90b2NvbHMgaXMgc2FpZCB0byBiZSAmcXVvdDtjb25k aXRpb25hbGx5IGNvbXBsaWFudC4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JZiB3ZSB1 c2VkIGEgU0hPVUxEIGZvciBUTFMsIGFuZCBhZGRlZCBzdWNoIGEgbGFuZ3VhZ2UsIGl0IHdpbGwg ZW5hYmxlIHRoZSBkZWZpbml0aW9uIG9mIHRocmVlIGNsYXNzZXMgb2YgaW1wbGVtZW50YXRpb25z OiBub24tY29tcGxpYW50LCB1bmNvbmRpdGlvbmFsbHkgY29tcGxpYW50ICh5b3VyIGRlZmluaXRp b24gb2Ygc2VjdXJlKSwgYW5kIGNvbmRpdGlvbmFsbHkgY29tcGxpYW50ICh3aGF0IEZhY2Vib29r LCBZYWhvbywgR29vZ2xlLCBhbmQgS2l2YSBhcmUgbGlrZWx5IHRvIGRlcGxveSkuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+QnV0IG15IHBvaW50IGlzIHRoYXQgdHJ5aW5nIHRvIHBhaW50IHRoZSBT SE9VTEQgb3B0aW9uIHdpdGggc3Ryb25nIHNlY3VyaXR5IGd1aWRhbmNlIGFzIOKAmHRoZSBJRVRG IGVuZG9yc2luZyBhbiBpbnNlY3VyZSBwcm90b2NvbOKAmSBvciDigJhkZXN0cm95IHRoZSBjcmVk aWJpbGl0eSBvZiBPQXV0aCBvdXRzaWRlIHRoZSBzaWxseSBzb2NpYWwgbmV0d29ya2luZyBjaXJj bGXigJkgKEnigJltIHBhcmFwaHJhc2luZyBidXQgdGhlIHNwaXJpdCBvZiB0aGUgY29tbWVudHMg aXMgYWNjdXJhdGUpIGlzIGp1c3QgYW4gb3ZlcmJsb3duIHJlYWN0aW9uIGFuZCBzY2FyZSB0YWN0 aWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Qm90aCBvcHRpb25zIGFyZSBsZWdpdGltYXRlIGFu ZCBwcm9kdWNlIHRoZSBzYW1lIGRlcGxveW1lbnQgcmVhbGl0eS4gVGhleSBvbmx5IGRpZmZlciBp biBob3cgdGhlIHNwZWMgdGFsa3MgYWJvdXQgc2VjdXJpdHkgYW5kIGhvdyBpbXBsZW1lbnRlcnMg Y2FuIHRhbGsgYWJvdXQgdGhlaXIgY29uZm9ybWFuY2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ RUhMPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz4gRnJhbmNpc2NvIENvcmVsbGEgW21haWx0bzpmY29yZWxsYUBwb21jb3IuY29tXSA8 YnI+PGI+U2VudDo8L2I+IFNhdHVyZGF5LCBBcHJpbCAwMiwgMjAxMSAxMDo0OSBBTTxicj48Yj5U bzo8L2I+IFNreWxhciBXb29kd2FyZDsgUGhpbCBIdW50OyBFcmFuIEhhbW1lci1MYWhhdjxicj48 Yj5DYzo8L2I+IE9sZWcgR3J5YjsgT0F1dGggV0c7IEthcmVuIFAuIExld2lzb248YnI+PGI+U3Vi amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEF1dGhvcml6YXRpb24gY29kZSBzZWN1cml0eSBpc3N1 ZSAocmVmcmFtZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJs ZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTA+PHRyPjx0ZCB2YWxpZ249dG9w IHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+RXJhbiw8YnI+ PGJyPiZndDsgR29vZ2xlLCBGYWNlYm9vaywgYW5kIFlhaG9vISBhbHJlYWR5IGluZGljYXRlZCB0 aGV5IHdpbGwgbm90IGVuZm9yY2U8YnI+Jmd0OyBzdWNoIGEgTVVTVC4gSSBjb3VsZCBub3QgZ2V0 IGEgY2xlYXIgYW5zd2VyIGZyb20gVHdpdHRlci48YnI+Jmd0OyA8YnI+Jmd0OyBIb3dldmVyLCBu byBvbmUgcmVwcmVzZW50aW5nIHRoaXMgY29tcGFuaWVzIGhhcyBib3RoZXJlZCB0byBleHByZXNz PGJyPiZndDsgdGhpcyB2aWV3IG9uIHRoZSBsaXN0LCBhbmQgdG8gZXhwcmVzcyBob3cgdGhleSB3 b3VsZCBsaWtlIHRoZTxicj4mZ3Q7IHNwZWNpZmljYXRpb24gdG8gaGFuZGxlIHRoaXMgY2FzZS4g VGhpcyBpcyB3aHkgSSBzdG9wcGVkIGFkdm9jYXRpbmc8YnI+Jmd0OyBmb3IgaXQgKHBlcnNvbmFs bHksIG15IG93biBwcm9kdWN0IGlzIGFscmVhZHkgZW5kLXRvLWVuZCBUTFMsIGFuZCB3aGVuPGJy PiZndDsgd2Ugb3BlbiBpdCB1cCBmb3IgZGV2ZWxvcGVycywgd2lsbCBub3QgZW5mb3JjZSBpdCBm b3IgcGVyc29uYWw8YnI+Jmd0OyBpbnN0YWxsYXRpb25zKS48YnI+PGJyPkdvb2QuJm5ic3A7IFRo ZSBJRVRGIGlzIG5vdCBhIGNvbnNvcnRpdW0gb2YgY29tcGFuaWVzLiZuYnNwOyBXaGF0IHRoZSBX RyBzaG91bGQ8YnI+ZGViYXRlIGlzIHdoZXRoZXIgdGhlIElFVEYgc2hvdWxkIGVuZG9yc2UgbGFj ayBvZiBzZWN1cml0eS48YnI+PGJyPkZyYW5jaXNjbzxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48 L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9ib2R5 PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664D9B8P3PW5EX1MB01E_-- From skylar@kiva.org Sat Apr 2 12:48:36 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C563A6840 for ; Sat, 2 Apr 2011 12:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOED5PFH8fvN for ; Sat, 2 Apr 2011 12:48:36 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by core3.amsl.com (Postfix) with SMTP id E295C3A6768 for ; Sat, 2 Apr 2011 12:48:34 -0700 (PDT) Received: from source ([209.85.160.178]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKTZd99xFr8ukoCF3Fa8ftE42gpl+afRxN@postini.com; Sat, 02 Apr 2011 12:50:17 PDT Received: by gyd12 with SMTP id 12so2120779gyd.37 for ; Sat, 02 Apr 2011 12:50:15 -0700 (PDT) Received: by 10.236.191.7 with SMTP id f7mr7447395yhn.89.1301773815379; Sat, 02 Apr 2011 12:50:15 -0700 (PDT) Received: from [192.168.2.8] (74-128-24-154.dhcp.insightbb.com [74.128.24.154]) by mx.google.com with ESMTPS id l49sm1661000yhn.33.2011.04.02.12.50.13 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 12:50:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Sat, 2 Apr 2011 15:50:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <94AC3DFD-4C3B-4320-9FE1-F09B92CBB8F3@kiva.org> References: <90C41DD21FB7C64BB94121FBBC2E7234465664D9AB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <617134.17423.qm@web55803.mail.re3.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234465664D9B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Phillip Hunt X-Mailer: Apple Mail (2.1084) Cc: "Karen P. Lewison" , Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 19:48:37 -0000 On Apr 2, 2011, at 3:19 PM, Phillip Hunt wrote: > If we take the current implementers as evidence it shows we have = little or no security either due to misunderstandings or business = decisions to accept risk for flexibility.=20 >=20 This type of language is also not helpful for moving us forward. I'd = like to see the discussion focused on the development of a useful = specification that also meets the challenge of being open (working with = many different use cases and contributors) as opposed to subjectively = evaluating the polices or relative qualities of individual companies. = This is the reason we are working together in an open community to = collaborate, rather than each company developing their own proprietary = solution. I'm actually quite proud that nearly since our inception Kiva has always = protected every bit of consumer-private data via HTTPS, including pages = with private data and connections bearing secure session cookies. = However, the default security we've put in place for every user may be = more security than they care about. Opening this data via API allows new = uses of the data outside the current constraints of the core product. As = an example, every user's lending profile is currently private and = secured over HTTPS. If a third party app wants to allow users to share = their complete lending profiles to the public internet (or to one's = friends on a social network running over HTTP only), such an API can = allow that. If OAuth can't serve as the permissions mechanism to enable = such sharing or flexibility of data it would be a shame. It's really = outside the scope of this spec to police the policies of developer = programs or their effectiveness in communicating to their users the = risks or nature of the apps in their ecosystems. I hope we can return to a productive discussion in striking a balance = between a flexible and effective specification. I think most of us = understand the risks of the MITM attacks being described, yet = sensational language and judgements are being tossed about - and for = what purpose I don't understand.= From recordond@gmail.com Sat Apr 2 12:57:00 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58343A68A6 for ; Sat, 2 Apr 2011 12:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eTaciv4td97 for ; Sat, 2 Apr 2011 12:56:59 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 43C023A689E for ; Sat, 2 Apr 2011 12:56:59 -0700 (PDT) Received: by vws12 with SMTP id 12so4045327vws.31 for ; Sat, 02 Apr 2011 12:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WPRZJpBQGvfPOdPZ5zloYdYvMekh0LzOEaaVRGcqNWc=; b=X+PXwqJa/Hv9TcFZjB+JfsCAVSN9C+VvxZ2Rd75monnUI60MkZWF5J4UAFuRBRcOP+ wl8HeTUeBi0KWYxeve5/GKnE4eVOCog6aKZ04XhiI+EpdhvJ/8rKdrOGwV+zjYSf7s87 t/Vh0z/KAZGkhffxYU7Na0J373lEFwCYZD1TA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Cmuk2VpDHesBxyg2jkkqv5WDzlDEWAHF1EKFkOHxSDdDEyWWLJnZC4q9mx3eUHVEkV z29Zx/P18R2hzNX8Qp8W6B1F1m1qT1d909wtTn9TC4C80XLQSmel2uG0ZbheiOxWHOo3 oQipIFNaz1Gkrrjx3J3rKfVttf0klaiGCxtDg= MIME-Version: 1.0 Received: by 10.52.171.111 with SMTP id at15mr2275316vdc.167.1301774319517; Sat, 02 Apr 2011 12:58:39 -0700 (PDT) Received: by 10.52.164.227 with HTTP; Sat, 2 Apr 2011 12:58:39 -0700 (PDT) In-Reply-To: <4D957DF9.50708@stpeter.im> References: <4D957DF9.50708@stpeter.im> Date: Sat, 2 Apr 2011 12:58:39 -0700 Message-ID: From: David Recordon To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] moving to Security Area X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 19:57:00 -0000 I can't say I understand this change when we're so close to being finished. On Fri, Apr 1, 2011 at 12:25 AM, Peter Saint-Andre wrote: > As discussed in the WG session at Prague just now, in discussion with > the Security Area Directors I have decided to move the OAuth Working > Group from the Applications Area to the Security Area of the IETF. The > rationale is that all of the most important work remaining for the WG to > produce OAuth 2.0 is security-related. Moving the WG to the Security > Area will enable us to receive all of the right security reviews as > early as possible before submitting the base specification to the IESG. > > Stephen Farrell of the Security Area will be your new AD, and I will > stay on as Applications Area advisor. > > Let's complete the important work of the OAuth WG and do the best we can > to make HTTP-based authorization more secure. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From dick.hardt@gmail.com Sat Apr 2 16:50:10 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C133A68F4 for ; Sat, 2 Apr 2011 16:50:10 -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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjNNziRyedXa for ; Sat, 2 Apr 2011 16:50:09 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id E3DD83A68F6 for ; Sat, 2 Apr 2011 16:50:08 -0700 (PDT) Received: by pzk30 with SMTP id 30so1225093pzk.31 for ; Sat, 02 Apr 2011 16:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=jExS9vnkuCUxmPFKmnfi03I5E1UHKho51OX6Adm3LD4=; b=OD2ne954Kd+NgNq9I2SwWOdE0LvZa5m1rZqsRZf7oPoFzwF4eDORMbAbaLs2LKuwMg 2PAQF/5IlCjGVpgM1K3cW25cvn1A6D0sMWVpJjPY5wGGHG2w+CTVAHACnsuDYEk1yL/5 wracnubfc9MqajNGM2CuUMGqGEg7t4bLBThvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=BXu7dpKZMMS2IXdIFVHciqCgF1pL2mTjKJ78Ya0bLxzlKl3YQMPasmOHX7w12bZ5K+ JVH/wEFNzD7dq+8tCSg7nLRkoZIJ32uDH7rE12Gag1BE/kYrGj04o0NA3rSPm37oFEeu 42Ch/PSkNwXKS1FIqnMWP8OIijT9BdDtXWzfY= Received: by 10.142.208.16 with SMTP id f16mr4788844wfg.58.1301788310291; Sat, 02 Apr 2011 16:51:50 -0700 (PDT) Received: from [192.168.1.16] (c-24-5-83-209.hsd1.ca.comcast.net [24.5.83.209]) by mx.google.com with ESMTPS id x11sm5148845wfd.1.2011.04.02.16.51.48 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 16:51:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Sat, 2 Apr 2011 16:51:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <70D64E19-5C42-4B7C-B536-879815D83590@gmail.com> References: <4D957DF9.50708@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: OAuth WG Subject: Re: [OAUTH-WG] moving to Security Area X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 23:50:10 -0000 I also am confused by change like this when we are at WGLC. I was under the impression that once the WG finished last call, the IETF = security mafia experts would be reviewing the spec -- so it is unclear = what advantage this has for getting the spec finished. On 2011-04-02, at 12:58 PM, David Recordon wrote: > I can't say I understand this change when we're so close to being = finished. >=20 > On Fri, Apr 1, 2011 at 12:25 AM, Peter Saint-Andre = wrote: >> As discussed in the WG session at Prague just now, in discussion with >> the Security Area Directors I have decided to move the OAuth Working >> Group from the Applications Area to the Security Area of the IETF. = The >> rationale is that all of the most important work remaining for the WG = to >> produce OAuth 2.0 is security-related. Moving the WG to the Security >> Area will enable us to receive all of the right security reviews as >> early as possible before submitting the base specification to the = IESG. >>=20 >> Stephen Farrell of the Security Area will be your new AD, and I will >> stay on as Applications Area advisor. >>=20 >> Let's complete the important work of the OAuth WG and do the best we = can >> to make HTTP-based authorization more secure. >>=20 >> Peter >>=20 >> -- >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Sat Apr 2 17:01:37 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39AB73A68F3 for ; Sat, 2 Apr 2011 17:01:37 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrqzsJXtaaS9 for ; Sat, 2 Apr 2011 17:01:36 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 04CD53A68F1 for ; Sat, 2 Apr 2011 17:01:35 -0700 (PDT) Received: by pzk30 with SMTP id 30so1226724pzk.31 for ; Sat, 02 Apr 2011 17:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=GM75Ks31tDZdsZ8Qk+aKc+jT41/wbyAUdWYgo0NVPnA=; b=JTVGVm0eo4vkaMY3oT1gCD2I3ktXxrRjelRdNorTP7MXpw826ZsLJ/A+C8bj6asSw4 Q+Qvo4E+nwfslsoBnSIcJWs6dr/j+g9c4mlzMQp6Okks9FB1aIwzzmSkCDiij1HpExz7 t8miJ6TI35+tsp/LiMFQI/AIyEx2dFZr39HjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=PiqeNwAOX29W6oITK/SX8FMqhebjxYevdbD4M6bLLrvgywtczkHmnPQYsMAFzhPXoF ghxAiaPOiWnFqmdRedcoYIGBz0AX6QBeNPw9D/ADbSEmscD+xKkLO5GGa3luC39hJgR+ 8+mUZo+CiZSyrpEPU99nLvXFtKpD7lzSuv04g= Received: by 10.142.157.13 with SMTP id f13mr4366935wfe.392.1301788997463; Sat, 02 Apr 2011 17:03:17 -0700 (PDT) Received: from [192.168.1.16] (c-24-5-83-209.hsd1.ca.comcast.net [24.5.83.209]) by mx.google.com with ESMTPS id 25sm5151205wfb.22.2011.04.02.17.03.14 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 17:03:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-117--788237233 From: Dick Hardt In-Reply-To: <81117.51614.qm@web55802.mail.re3.yahoo.com> Date: Sat, 2 Apr 2011 17:03:13 -0700 Message-Id: <90B7461C-848C-4DE5-94DF-8AB1781AA4DC@gmail.com> References: <81117.51614.qm@web55802.mail.re3.yahoo.com> To: fcorella@pomcor.com X-Mailer: Apple Mail (2.1084) Cc: "Karen P. Lewison" , OAuth WG Subject: Re: [OAUTH-WG] to TLS or not on redirect on consumer websites :: security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 00:01:37 -0000 --Apple-Mail-117--788237233 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-04-02, at 11:13 AM, Francisco Corella wrote: >=20 > > Another example I mentioned earlier is when the client does > > not expose the protected resources back to the bearer of the > > code. For example, a Twitter application sending you emails > > when someone stops following you. Since all it does is get > > the code and then uses it internally (no user login > > functionality), TLS adds NOTHING. >=20 > I'm not sure I understand the example. Would the attacker > be able to get emails when someone stops following the user? > Would that be OK? I can do that without any authorization from the user.=20 > Anyway, an application that accesses Twitter on the user's > behalf is likely to be able to send tweets on the user's > behalf. The attacks we've been discussing would allow the > attacker to send tweets on the user's behalf. That's > definitely not cool. Maybe you should stop using Twitter as anyone that can MITM your session = can tweet as you since Twitter does not enforce HTTPS on twitter.com Am I missing something in your statement? ... or did you respond without = thinking this through? -- Dick= --Apple-Mail-117--788237233 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

> Another example I = mentioned earlier is when the client does
> not expose the = protected resources back to the bearer of the
> code. For example, a = Twitter application sending you emails
> when someone stops = following you. Since all it does is get
> the code and then uses = it internally (no user login
> functionality), TLS = adds NOTHING.

I'm not sure I understand the example.  Would the = attacker
be able to get emails when someone stops following the = user?
Would that be = OK?

I can do that without any = authorization from the user. 

Anyway, an application that accesses Twitter on the = user's
behalf is likely to be able to send tweets on the = user's
behalf.  The attacks we've been discussing would = allow the
attacker to send tweets on the user's behalf. =  That's
definitely not = cool.

Maybe you should stop = using Twitter as anyone that can MITM your session can tweet as you = since Twitter does not enforce HTTPS on twitter.com

Am = I missing something in your statement? ... or did you respond without = thinking this through?

-- = Dick
= --Apple-Mail-117--788237233-- From prateek.mishra@oracle.com Mon Apr 4 08:56:01 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A70E28C133 for ; Mon, 4 Apr 2011 08:56:01 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SXWfITpBfNu for ; Mon, 4 Apr 2011 08:55:53 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A9B8C28C114 for ; Mon, 4 Apr 2011 08:55:53 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p34FvYqw027330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 15:57:35 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p34FvXFh032455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2011 15:57:34 GMT Received: from abhmt018.oracle.com (abhmt018.oracle.com [141.146.116.27]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p34FvXDd010559; Mon, 4 Apr 2011 10:57:33 -0500 Received: from [10.154.34.28] (/10.154.34.28) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 08:57:32 -0700 Message-ID: <4D99EA6C.8060003@oracle.com> Date: Mon, 04 Apr 2011 11:57:32 -0400 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: fcorella@pomcor.com References: <133605.76951.qm@web55802.mail.re3.yahoo.com> In-Reply-To: <133605.76951.qm@web55802.mail.re3.yahoo.com> Content-Type: multipart/alternative; boundary="------------030407040308060108000402" X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4D99EA6E.0076:SCFSTAT5015188,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 15:56:01 -0000 This is a multi-part message in MIME format. --------------030407040308060108000402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Francisco, You are right, I was in error to suggest that it was a MUST. I think my main concern was that security considerations should not be based on polling developers/deployers of an existing or legacy protocol. SAML does include some additional countermeasures though - for example (lines 595-596, profiles document) - that specifically deal with the artifact being leaked - [quote] The identity provider MUST ensure that only the service provider to whom the message has been issued is given the message as the result of an request. [\quote] - prateek > Hi Prateek, > > > I would like to strongly disagree with this proposal. > > > > It amounts to explicitly making OAuth 2.0 insecure so as to > > satisfy some mysterious and unspecified set of legacy OAuth > > 1.0 deployments. > > > > The SAML web SSO (artifact) profile - which shares many > > characteristics with the initial steps in OAuth - requires > > precisely such a counter-measure and is widely implemented > > in 1000s of deployments. > > What counter-measure is this? Can you provide a reference? > Section 4.1.3.5 of > http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf > recommends TLS but does not require it. > > Francisco > > --------------030407040308060108000402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Francisco,

You are right, I was in error to suggest that it was a MUST.

 I think my main concern was that security considerations should not be based on polling developers/deployers of an existing or legacy protocol.

SAML does include some additional countermeasures though - for example (lines 595-596, profiles document) - that specifically deal with the
artifact being leaked -

[quote]
The identity provider MUST ensure that only the service provider to whom the <Response> message has
been issued is given the message as the result of an <ArtifactResolve> request.
[\quote]

- prateek
Hi Prateek,

> I would like to strongly disagree with this proposal.
>
> It amounts to explicitly making OAuth 2.0 insecure so as to
> satisfy some mysterious and unspecified set of legacy OAuth
> 1.0 deployments.
>
> The SAML web SSO (artifact) profile - which shares many
> characteristics with the initial steps in OAuth - requires
> precisely such a counter-measure and is widely implemented
> in 1000s of deployments.

What counter-measure is this?  Can you provide a reference?
Section 4.1.3.5 of
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
recommends TLS but does not require it.

Francisco
--------------030407040308060108000402-- From torsten@lodderstedt.net Mon Apr 4 09:46:45 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4A628C118 for ; Mon, 4 Apr 2011 09:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbX5Uu2c2BDO for ; Mon, 4 Apr 2011 09:46:44 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by core3.amsl.com (Postfix) with ESMTP id 77F9928C110 for ; Mon, 4 Apr 2011 09:46:44 -0700 (PDT) Received: from [80.187.101.251] (helo=[192.168.43.164]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Q6mwz-0006Q5-Ey; Mon, 04 Apr 2011 18:48:25 +0200 Message-ID: <4D99F650.607@lodderstedt.net> Date: Mon, 04 Apr 2011 18:48:16 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marius Scurtescu References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:46:45 -0000 +1 Am 01.04.2011 03:00, schrieb Marius Scurtescu: > On Thu, Mar 31, 2011 at 4:56 PM, Phil Hunt wrote: >> Done. >> >> It isn't quite what the flow shows in the earlier diagram. I was originally avoiding client type and trying to focus on section 4 options. >> >> But this should be a better diagram. >> >> http://independentidentity.blogspot.com/2011/03/oauth-flows-extended.html > A native app with no client secret is still advised to use the > implicit grant, which is wrong IMO. > > The right question I think is "does the client need long term offline access"? > > JavaScript clients typically don't need offline access (only with the > user at the browser). Some native apps and web apps could be OK with a > short term offline access, one off import for example. > > Marius From phil.hunt@oracle.com Mon Apr 4 09:50:42 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C695228C139 for ; Mon, 4 Apr 2011 09:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb8Cjp4QkPfn for ; Mon, 4 Apr 2011 09:50:40 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 25C813A681B for ; Mon, 4 Apr 2011 09:50:40 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p34GqLA0014642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 16:52:22 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p34GqK3M026284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2011 16:52:20 GMT Received: from abhmt021.oracle.com (abhmt021.oracle.com [141.146.116.30]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p34GqJQ0014606; Mon, 4 Apr 2011 11:52:20 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 09:52:19 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-59--641293219 From: Phil Hunt In-Reply-To: <4D99EA6C.8060003@oracle.com> Date: Mon, 4 Apr 2011 09:52:17 -0700 Message-Id: References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> To: Prateek Mishra X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4D99F745.0094:SCFSTAT5015188,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:50:42 -0000 --Apple-Mail-59--641293219 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Apologies for the long message (again). I have attempted to sum things = up and bring out the issue without using any existing service or party = as an example of problems. It seems some have taken offence to my = previous message pushing for a solution. As a result it was not = productive. I apologize. Hopefully this message sticks to the issue of = developing an appropriate counter measure to threats as that is my only = intent. As Prateek clarified in the previous message to Francisco, SAML also = uses SHOULD, but artifact security is achieved by an additional = counter-measure... > The identity provider MUST ensure that only the service provider to = whom the message has > been issued is given the message as the result of an = request. Yet, in OAuth the client app is not unique for a particular set of = client credentials we currently have no way to verify that the correct = client got the code. This has been the mechanism that the community has = been assuming solves the problem. Client credentials do not always work = to protect the authorization code because in OAuth you can have many = many clients with the same credential. For example everyone with the = same mobile app likely has the same client credential. Thus a copy of a = valid client app which is easy to obtain becomes the hacker's attack = vector. So, the client credential is not an effective counter in this = case. Several have commented that there are other supplementary techniques for = protection, but in my view, most of them work indirectly and/or depend = on correct collective configuration of several components. Some of these = are: tokens may be used one time; tokens are invalidated if used a = second time, tokens are sufficiently unique, etc. All of these will = help. But none are designed to directly counter the attack. In fact the = best one - token invalidation carries the additional problem of = unreliable service for the legitimate client. The hacker can deny = service to anyone in the room simply by re-using any tokens seen. =46rom my perspective, the "easy" solution was to increase the = requirements on TLS from SHOULD to MUST to prevent eavesdropping of the = code. This was echoed by several others. I agree this will not work for = everyone. Many have made strong arguments for why they can't use it. But = without a MUST we are still missing a direct counter to the threat. I don't want to change things at this late date, but maybe this means = introducing some form of mutual authentication -- some way for the = requesting client "instance" to prove that they are the copy eligible to = use an authorization code.=20 To end this discussion, I propose we vote on the proposal from Eran plus = one new option... 1. Include a normative MUST use TLS for the client redirection URI = endpoint. 2. Include a normative SHOULD use TLS for the client redirection URI = endpoint with strong language explaining the various attacks possible if = the endpoint is not made secure. 3. Keep current language of SHOULD, but develop a direct counter-measure = to token theft such as specific client instance identification or mutual = authentication. Phil phil.hunt@oracle.com On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: > Francisco, >=20 > You are right, I was in error to suggest that it was a MUST. >=20 > I think my main concern was that security considerations should not = be based on polling developers/deployers of an existing or legacy = protocol. >=20 > SAML does include some additional countermeasures though - for example = (lines 595-596, profiles document) - that specifically deal with the > artifact being leaked -=20 >=20 > [quote] > The identity provider MUST ensure that only the service provider to = whom the message has > been issued is given the message as the result of an = request. > [\quote] >=20 > - prateek >> Hi Prateek, >>=20 >> > I would like to strongly disagree with this proposal. >> >=20 >> > It amounts to explicitly making OAuth 2.0 insecure so as to >> > satisfy some mysterious and unspecified set of legacy OAuth >> > 1.0 deployments. >> >=20 >> > The SAML web SSO (artifact) profile - which shares many >> > characteristics with the initial steps in OAuth - requires >> > precisely such a counter-measure and is widely implemented >> > in 1000s of deployments. >>=20 >> What counter-measure is this? Can you provide a reference? >> Section 4.1.3.5 of=20 >> = http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >> recommends TLS but does not require it. >>=20 >> Francisco >>=20 >>=20 --Apple-Mail-59--641293219 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The identity provider MUST ensure = that only the service provider to whom the <Response> message = has
been issued is given the message as the result of an = <ArtifactResolve> request.

Yet, = in OAuth the client app is not unique for a particular set of client = credentials we currently have no way to verify that the correct client = got the code. This has been the mechanism that the community has been = assuming solves the problem. Client credentials do not always work to = protect the authorization code because in OAuth you can have many = many clients with the same credential. For example everyone with the = same mobile app likely has the same client credential. Thus a copy of a = valid client app which is easy to obtain becomes the hacker's attack = vector. So, the client credential is not an effective counter in this = case.

Several have commented that there are = other supplementary techniques for protection, but in my view, most of = them work indirectly and/or depend on correct collective configuration = of several components. Some of these are: tokens may be used one time; = tokens are invalidated if used a second time, tokens are sufficiently = unique, etc.  All of these will help. But none are designed to = directly counter the attack. In fact the best one - token invalidation = carries the additional problem of unreliable service for the legitimate = client. The hacker can deny service to anyone in the room simply by = re-using any tokens seen.

=46rom my = perspective, the "easy" solution was to increase the requirements on TLS = from SHOULD to MUST to prevent eavesdropping of the code. This was = echoed by several others. I agree this will not work for everyone. = Many have made strong arguments for why they can't use it. But = without a MUST we are still missing a direct counter to the = threat.

I don't want to change things at this = late date, but maybe this means introducing some form of mutual = authentication -- some way for the requesting client "instance" to prove = that they are the copy eligible to use an authorization = code. 

To end this discussion, I propose = we vote on the proposal from Eran plus one new option...
1. Include a normative MUST use = TLS for the client redirection URI endpoint.
2. Include a normative SHOULD use = TLS for the client redirection URI endpoint with strong language = explaining the various attacks possible if the endpoint is not made = secure.

Phil

On 2011-04-04, at 8:57 AM, Prateek Mishra wrote:

Francisco,

You are right, I was in error to suggest that it was a MUST.

 I think my main concern was that security considerations should = not be based on polling developers/deployers of an existing or legacy = protocol.

SAML does include some additional countermeasures though - for example (lines 595-596, profiles document) - that specifically deal with the
artifact being leaked -

[quote]
The identity provider MUST ensure that only the service provider to whom the <Response> message has
been issued is given the message as the result of an <ArtifactResolve> request.
[\quote]

- prateek
Hi Prateek,

> I would like to strongly disagree with this proposal.
>
> It amounts to explicitly making OAuth 2.0 insecure so as to
> satisfy some mysterious and unspecified set of legacy OAuth
> 1.0 deployments.
>
> The SAML web SSO (artifact) profile - which shares many
> characteristics with the initial steps in OAuth - requires
> precisely such a counter-measure and is widely implemented
> in 1000s of deployments.

What counter-measure is this?  Can you provide a reference?
Section 4.1.3.5 of
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.p= df
recommends TLS but does not require it.

Francisco

= --Apple-Mail-59--641293219-- From beaton@google.com Mon Apr 4 10:09:23 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791C03A6A04 for ; Mon, 4 Apr 2011 10:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JoMYY89Q173 for ; Mon, 4 Apr 2011 10:09:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8DCE23A6A03 for ; Mon, 4 Apr 2011 10:09:22 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p34HB4a5022510 for ; Mon, 4 Apr 2011 10:11:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301937064; bh=a1zm6rv0BL7e5HrrPw0QdRKI//A=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Wcy1ElpC0D//h5q4svREQNYPPb7MOV9Q+vsBpKmeTH6YdezIZaDa6+n6ysodkcTeT nK4DCrxGWsOGVn89y4noA== Received: from pxi17 (pxi17.prod.google.com [10.243.27.17]) by wpaz1.hot.corp.google.com with ESMTP id p34HB2EM021912 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 4 Apr 2011 10:11:03 -0700 Received: by pxi17 with SMTP id 17so2373744pxi.6 for ; Mon, 04 Apr 2011 10:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u20vW3teNovS0GLl4DpDZaVJam9FwxoFVPBd7UW6YI8=; b=iLA7tAgPrNJTmMckrgmPfeLNba0NUFryoGsaub7mV+uOr34etvnzqpK4tiirwmJeCt ZPoWc8+gvVjWJvPdrhLQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qFgsGVbnSNZvGNwTBgy3zr5MdC5qh3GvdMZyQDQA+wUeTy1HAhdOTDMhMjHxL8QW/J v18SkYlCNHb5DlXQeTDQ== MIME-Version: 1.0 Received: by 10.142.193.11 with SMTP id q11mr6359016wff.355.1301937062472; Mon, 04 Apr 2011 10:11:02 -0700 (PDT) Received: by 10.142.213.7 with HTTP; Mon, 4 Apr 2011 10:11:02 -0700 (PDT) In-Reply-To: References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> Date: Mon, 4 Apr 2011 10:11:02 -0700 Message-ID: From: Brian Eaton To: Phil Hunt Content-Type: multipart/alternative; boundary=000e0cd1582e20ee9c04a01ad869 X-System-Of-Record: true Cc: OAuth WG , Prateek Mishra Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:09:23 -0000 --000e0cd1582e20ee9c04a01ad869 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 4, 2011 at 9:52 AM, Phil Hunt wrote: > As Prateek clarified in the previous message to Francisco, SAML also uses > SHOULD, but artifact security is achieved by an additional > counter-measure... > > The identity provider MUST ensure that only the service provider to whom > the message has > been issued is given the message as the result of an > request. > > The problem with the SAML comparison is that SAML does not attempt to address the problems of installed applications. That was all deferred to WS-Trust. OAuth2 does solve both the web app and installed app problems. I think it's really important that we recognize that installed applications have a very different set of security problems than web sites. For example, for web sites we need to deal with the risk of RP compromise and all of the refresh tokens being stolen. That's not an issue for installed apps, because there is no central database of refresh tokens to compromise. For installed apps, on the other hand, there is no good system for reliably identifying a client. For web apps we've got two separate good systems (same-origin policy and client secret) for identifying RPs. One other interesting aspect of client applications is that it's very easy for client apps to use a protected channel to receive the callback URL. There is lively debate about which protected channel to use, but almost everyone agrees there is at least one good option. If you redo your analysis from the perspective that client applications have different security risks than web applications, do you reach happier conclusions? Cheers, Brian --000e0cd1582e20ee9c04a01ad869 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Apr 4, 2011 at 9:52 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
=
As Prateek clarified in the previo= us message to Francisco, SAML also uses SHOULD, but artifact security is ac= hieved by an additional counter-measure...
The identity provider MUST ensure= that only the service provider to whom the <Response> message hasbeen issued is given the message as the result of an <ArtifactResolve&g= t; request.
The problem with the SAML compar= ison is that SAML does not attempt to address the problems of installed app= lications. =A0That was all deferred to WS-Trust. =A0OAuth2 does solve both = the web app and installed app problems.

I think it's really important that we recognize tha= t installed applications have a very different set of security problems tha= n web sites. =A0For example, for web sites we need to deal with the risk of= RP compromise and all of the refresh tokens being stolen. =A0That's no= t an issue for installed apps, because there is no central database of refr= esh tokens to compromise. =A0For installed apps, on the other hand, there i= s no good system for reliably identifying a client. =A0For web apps we'= ve got two separate good systems (same-origin policy and client secret) for= identifying RPs.

One other interesting aspect of client applications is = that it's very easy for client apps to use a protected channel to recei= ve the callback URL. =A0There is lively debate about which protected channe= l to use, but almost everyone agrees there is at least one good option.

If you redo your analysis from the perspective that cli= ent applications have different security risks than web applications, do yo= u reach happier conclusions?
=A0
Cheers,
Bria= n
--000e0cd1582e20ee9c04a01ad869-- From kris.selden@gmail.com Mon Apr 4 10:45:42 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FADF3A6A22 for ; Mon, 4 Apr 2011 10:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVYUvy0WbxjW for ; Mon, 4 Apr 2011 10:45:41 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 025033A6A05 for ; Mon, 4 Apr 2011 10:45:37 -0700 (PDT) Received: by pvh1 with SMTP id 1so900774pvh.31 for ; Mon, 04 Apr 2011 10:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=wPQ4js8tIw/5OUl9byqoM2NL8qySg89XdJo8tU4HUkc=; b=cqJwlfyrYGN7gN6ukWRF3a00biuFgLBQttdawS/swqXPwJzN0KlLp5BYIi5mzXPZHr bixx4htkJdbKeXRnivzIIrIlJFKDtbETVP2Lz3MiI+xJx+pmJoq0rqsWNgsHTNzpDW0T Bnfw+1NYvcxeNVGKdx0MVcx8GFeH72BKZU6gw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=B7dAAxTA25tmBxYXnJMCyorm1nd/Rc5pz4cCY57UeE89jXqQsvf+kRjFA3/o8KPZvo TONYhb49YaFU5cvAHeZixUvkqlAAQDYvuvhFIhvFIBCWJIWQdpkTXi9Ua0FGq98kethn caEGGOark078pO/JuXOLB1RKhunPheC6Qxldc= Received: by 10.142.173.1 with SMTP id v1mr128781wfe.366.1301939240624; Mon, 04 Apr 2011 10:47:20 -0700 (PDT) Received: from [172.16.176.22] ([74.212.130.213]) by mx.google.com with ESMTPS id m10sm7840757wfl.23.2011.04.04.10.47.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 10:47:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Kris Selden In-Reply-To: Date: Mon, 4 Apr 2011 10:47:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> To: Marius Scurtescu X-Mailer: Apple Mail (2.1082) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:45:42 -0000 A typical iPhone app cannot be shipped with a client secret and rightly = or wrongly users expect to only have to enter their credentials once. What is the best profile to use for an app that can't have a client = secret and needs a refresh token or a long lived access token? Why doesn't implicit_grant have a refresh_token? I would think a = non-expiring access_token like FB offline_access would be worse option = since it is transmitted to more end points. A lot of FB Connect sites request offline_access when you connect. Like = Foursquare, Quora, Gowalla for example. On Mar 31, 2011, at 6:00 PM, Marius Scurtescu wrote: > On Thu, Mar 31, 2011 at 4:56 PM, Phil Hunt = wrote: >> Done. >>=20 >> It isn't quite what the flow shows in the earlier diagram. I was = originally avoiding client type and trying to focus on section 4 = options. >>=20 >> But this should be a better diagram. >>=20 >> = http://independentidentity.blogspot.com/2011/03/oauth-flows-extended.html >=20 > A native app with no client secret is still advised to use the > implicit grant, which is wrong IMO. >=20 > The right question I think is "does the client need long term offline = access"? >=20 > JavaScript clients typically don't need offline access (only with the > user at the browser). Some native apps and web apps could be OK with a > short term offline access, one off import for example. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From oleg_gryb@yahoo.com Mon Apr 4 10:50:58 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8712A3A686E for ; Mon, 4 Apr 2011 10:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmos3MKqz8Pz for ; Mon, 4 Apr 2011 10:50:56 -0700 (PDT) Received: from web37607.mail.mud.yahoo.com (web37607.mail.mud.yahoo.com [209.191.87.90]) by core3.amsl.com (Postfix) with SMTP id A522B3A6859 for ; Mon, 4 Apr 2011 10:50:56 -0700 (PDT) Received: (qmail 54456 invoked by uid 60001); 4 Apr 2011 17:52:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301939554; bh=hS7xyuRcUyVsKU0zjLBFOdCki2XVj7NCv/zYVMA8vhU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1kxANZJoagSLOkYd2B3+eVcXrRtOf5NIm3oxX1G2ngQzibwrQDtQnhUeL053FG7kdxpkgCsZMUiS/NdcUXRqRawDTa34ng7mKuS7EB/1bgVu/m0chZxg93/f/bNC8bXZn2mPKC9CzC50rMeg6iscvElQP41X+1PP7FjYLB8aBuE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ffeU1RuOw2oynnA5u90GFPMTsJ8CTKtsKIO6p7R6C6a5t/lMHh4KaoVgqi6c7h8IgbNGN9jZGtT/flF6wZfRBso4JDE46C//22cVbCVWbIDOUAt8UC9rs7YrnOfkWIfFxJf/Xf0TqV1G/K5/kXr9JjJb9bZGsmbe0lw18hnHuyQ=; Message-ID: <188405.40029.qm@web37607.mail.mud.yahoo.com> X-YMail-OSG: .5jkuwkVM1msRR9_CM7tFUJueZRU2GGftWuNM65NGx8T6Wi GSO9ePbJ71A_eX9PUYNQ2PCcrk84bCqSJj_AUZzhzJ76nidEUULpj.FlT85n BmJ8R16Our9sZfdEhq9Vl1wc3nsjWeTWe57fbNCnJetbuHDArC4nffMqsPYk gfDdMScpwPUvnS8C20nS1ZTylAyBfpP4XO0AhAjY.Nb0TWvWiyfR.Z_HQfOu _lflfQ3ohng3sTwAvyviK6qFI0MleaZbM864mBNgXfMV9NKYLtKZS5MvFmk. P6AOSo4IxWjgBEi0D05oVFgDqIYK8Q6hL78yooGnWF9V37KHRG0VRbw8bIvg l8pPRwJAYgkgellI26o5v1mGyUoxmFrBCUIQmFC.z6gQQfjRqW3TXhMEHxjf V5TVEjSJn56Cw Received: from [208.240.243.170] by web37607.mail.mud.yahoo.com via HTTP; Mon, 04 Apr 2011 10:52:34 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> Date: Mon, 4 Apr 2011 10:52:34 -0700 (PDT) From: Oleg Gryb To: Phil Hunt , Prateek Mishra In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-368524153-1301939554=:40029" Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:50:58 -0000 --0-368524153-1301939554=:40029 Content-Type: text/plain; charset=us-ascii After looking into exiting (and working) implementations of OAuth 1.0 in mobile world I have strong doubts about possibility of implementing what was suggested in option #3. In my view, two conditions are needed to achieve that: 1. Something unique stored on a mobile client. 2. That something should be a secret, so other (malicious) clients could not reuse it. Distribution of that "unique secrets" should be automated in the mobile world and is usually included to mobile application activation process, but that activation process can't make conditions 1 & 2 above met in full, becuase: 1. As soon as secrets are distributed to a mobile device they are not quite secret any more 2. As soon as the secret becomes known, a simulator or other mobile device can be used to spoof the traffic I would consider option #3 as an illusion until somebody comes up with a solution that would address the described issues. BTW, the draft of "OAuth Dynamic Client Registration Protocol" (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on Feb. 12 and I didn't see any attempts to re-vitalise it. I think it would be better and more beneficial for the community to return to this protocol rather than inventing a new method of "mutual authentication". > >From: Phil Hunt >To: Prateek Mishra >Cc: OAuth WG >Sent: Mon, April 4, 2011 9:52:17 AM >Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) > > >Apologies for the long message (again). I have attempted to sum things up and >bring out the issue without using any existing service or party as an example of >problems. It seems some have taken offence to my previous message pushing for a >solution. As a result it was not productive. I apologize. Hopefully this >message sticks to the issue of developing an appropriate counter measure to >threats as that is my only intent. > > >As Prateek clarified in the previous message to Francisco, SAML also uses >SHOULD, but artifact security is achieved by an additional counter-measure... >The identity provider MUST ensure that only the service provider to whom the > message has >>been issued is given the message as the result of an request. >Yet, in OAuth the client app is not unique for a particular set of client >credentials we currently have no way to verify that the correct client got the >code. This has been the mechanism that the community has been assuming solves >the problem. Client credentials do not always work to protect the authorization >code because in OAuth you can havemany many clients with the same credential. >For example everyone with the same mobile app likely has the same client >credential. Thus a copy of a valid client app which is easy to obtain becomes >the hacker's attack vector. So, the client credential is not an effective >counter in this case. > > >Several have commented that there are other supplementary techniques for >protection, but in my view, most of them work indirectly and/or depend on >correct collective configuration of several components. Some of these are: >tokens may be used one time; tokens are invalidated if used a second time, >tokens are sufficiently unique, etc. All of these will help. But none are >designed to directly counter the attack. In fact the best one - token >invalidation carries the additional problem of unreliable service for the >legitimate client. The hacker can deny service to anyone in the room simply by >re-using any tokens seen. > > >From my perspective, the "easy" solution was to increase the requirements on TLS >from SHOULD to MUST to prevent eavesdropping of the code. This was echoed by >several others. Iagree this will not work for everyone. Many have made strong >arguments for why they can't use it. But without a MUST we are still missing a >direct counter to the threat. > > >I don't want to change things at this late date, but maybe this means >introducing some form of mutual authentication -- some way for the requesting >client "instance" to prove that they are the copy eligible to use an >authorization code. > > >To end this discussion, I propose we vote on the proposal from Eran plus one new >option... >1. Include a normative MUST use TLS for the client redirection URI endpoint. >2. Include a normative SHOULD use TLS for the client redirection URI endpoint >with strong language explaining the various attacks possible if the endpoint is >not made secure. >3. Keep current language of SHOULD, but develop a direct counter-measure to >token theft such as specific client instance identification or mutual >authentication. > > >Phil >phil.hunt@oracle.com > > > > >On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: > >Francisco, >> >>You are right, I was in error to suggest that it was a MUST. >> >> I think my main concern was that security considerations should not be based on >>polling developers/deployers of an existing or legacy protocol. >> >>SAML does include some additional countermeasures though - for example (lines >>595-596, profiles document) - that specifically deal with the >>artifact being leaked - >> >>[quote] >>The identity provider MUST ensure that only the service provider to whom the >> message has >>been issued is given the message as the result of an request. >>[\quote] >> >>- prateek >> >>Hi Prateek, >>> >>>> I would like to strongly disagree with this proposal. >>>> >>>> It amounts to explicitly making OAuth 2.0 insecure so as to >>>> satisfy some mysterious and unspecified set of legacy OAuth >>>> 1.0 deployments. >>>> >>>> The SAML web SSO (artifact) profile - which shares many >>>> characteristics with the initial steps in OAuth - requires >>>> precisely such a counter-measure and is widely implemented >>>> in 1000s of deployments. >>> >>>What counter-measure is this? Can you provide a reference? >>>Section 4.1.3.5 of >>>http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>>recommends TLS but does not require it. >>> >>>Francisco >>> >>> >>> > --0-368524153-1301939554=:40029 Content-Type: text/html; charset=us-ascii
After looking into exiting (and working) implementations of OAuth 1.0 in mobile world I have strong doubts about possibility of implementing what was suggested in option #3.

In my view, two conditions are needed to achieve that:

1. Something unique stored on a mobile client.
2. That something should be a secret, so other (malicious) clients could not reuse it.

Distribution of that "unique secrets" should be automated in the mobile world and is usually included to mobile application
activation process, but that activation process can't make conditions 1 & 2 above met in full, becuase:

1. As soon as secrets are distributed to a mobile device they are not quite secret any more
2. As soon as the secret becomes known, a simulator or other mobile device can be used to spoof the traffic

I would consider option #3 as an illusion until somebody comes up with a solution that would address the described issues.

BTW, the draft of "OAuth Dynamic Client Registration Protocol" (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on Feb. 12 and I didn't see any attempts to re-vitalise it. I think it would be better and more beneficial for the community to return to this protocol rather than inventing a new method of "mutual authentication".




From: Phil Hunt <phil.hunt@oracle.com>
To: Prateek Mishra <prateek.mishra@oracle.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Mon, April 4, 2011 9:52:17 AM
Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)

Apologies for the long message (again). I have attempted to sum things up and bring out the issue without using any existing service or party as an example of problems. It seems some have taken offence to my previous message pushing for a solution. As a result it was not productive. I apologize.  Hopefully this message sticks to the issue of developing an appropriate counter measure to threats as that is my only intent.

As Prateek clarified in the previous message to Francisco, SAML also uses SHOULD, but artifact security is achieved by an additional counter-measure...
The identity provider MUST ensure that only the service provider to whom the <Response> message has
been issued is given the message as the result of an <ArtifactResolve> request.

Yet, in OAuth the client app is not unique for a particular set of client credentials we currently have no way to verify that the correct client got the code. This has been the mechanism that the community has been assuming solves the problem. Client credentials do not always work to protect the authorization code because in OAuth you can have many many clients with the same credential. For example everyone with the same mobile app likely has the same client credential. Thus a copy of a valid client app which is easy to obtain becomes the hacker's attack vector. So, the client credential is not an effective counter in this case.

Several have commented that there are other supplementary techniques for protection, but in my view, most of them work indirectly and/or depend on correct collective configuration of several components. Some of these are: tokens may be used one time; tokens are invalidated if used a second time, tokens are sufficiently unique, etc.  All of these will help. But none are designed to directly counter the attack. In fact the best one - token invalidation carries the additional problem of unreliable service for the legitimate client. The hacker can deny service to anyone in the room simply by re-using any tokens seen.

From my perspective, the "easy" solution was to increase the requirements on TLS from SHOULD to MUST to prevent eavesdropping of the code. This was echoed by several others. I agree this will not work for everyone. Many have made strong arguments for why they can't use it. But without a MUST we are still missing a direct counter to the threat.

I don't want to change things at this late date, but maybe this means introducing some form of mutual authentication -- some way for the requesting client "instance" to prove that they are the copy eligible to use an authorization code. 

To end this discussion, I propose we vote on the proposal from Eran plus one new option...
1. Include a normative MUST use TLS for the client redirection URI endpoint.
2. Include a normative SHOULD use TLS for the client redirection URI endpoint with strong language explaining the various attacks possible if the endpoint is not made secure.
3. Keep current language of SHOULD, but develop a direct counter-measure to token theft such as specific client instance identification or mutual authentication.

Phil

On 2011-04-04, at 8:57 AM, Prateek Mishra wrote:

Francisco,

You are right, I was in error to suggest that it was a MUST.

 I think my main concern was that security considerations should not be based on polling developers/deployers of an existing or legacy protocol.

SAML does include some additional countermeasures though - for example (lines 595-596, profiles document) - that specifically deal with the
artifact being leaked -

[quote]
The identity provider MUST ensure that only the service provider to whom the <Response> message has
been issued is given the message as the result of an <ArtifactResolve> request.
[\quote]

- prateek
Hi Prateek,

> I would like to strongly disagree with this proposal.
>
> It amounts to explicitly making OAuth 2.0 insecure so as to
> satisfy some mysterious and unspecified set of legacy OAuth
> 1.0 deployments.
>
> The SAML web SSO (artifact) profile - which shares many
> characteristics with the initial steps in OAuth - requires
> precisely such a counter-measure and is widely implemented
> in 1000s of deployments.

What counter-measure is this?  Can you provide a reference?
Section 4.1.3.5 of
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
recommends TLS but does not require it.

Francisco

--0-368524153-1301939554=:40029-- From phil.hunt@oracle.com Mon Apr 4 11:00:55 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273953A69C1 for ; Mon, 4 Apr 2011 11:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BddN7iA1j1P for ; Mon, 4 Apr 2011 11:00:54 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id DF0E43A69BC for ; Mon, 4 Apr 2011 11:00:53 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p34I2XOY004316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 18:02:35 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p34I2VI0011101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2011 18:02:32 GMT Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p34I2U85031865; Mon, 4 Apr 2011 13:02:30 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 11:02:30 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> Date: Mon, 4 Apr 2011 11:02:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9E68D140-ED3D-4C62-A6A1-5CE1CDB5C5D9@oracle.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> To: Kris Selden X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4D9A07B8.00F1:SCFSTAT5015188,ss=1,fgs=0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:00:55 -0000 See below... Phil phil.hunt@oracle.com On 2011-04-04, at 10:47 AM, Kris Selden wrote: > A typical iPhone app cannot be shipped with a client secret and = rightly or wrongly users expect to only have to enter their credentials = once. My understanding (and I'm not an iOS expert) is that each iOS = application has a secure keystore where the client credential could be = stored. I am told this is fairly straight forward. The client app would = issue a call out to the external safari browser for the authorization = with a redirect back to the app registered (local redirect) such as = myapp://authorization_code Note that in security considerations it is recommended against having an = app collect user credentials directly. It is always preferred to use the = external browser. This is so that the user can see the UI as being legit = and that appropriate security measures are in place. It also protects = the client app from problems that might occur from screen scraping a = service provider UI that is subject to change. >=20 > What is the best profile to use for an app that can't have a client = secret and needs a refresh token or a long lived access token? You can use the typical client credential flow as per my comment above. = If no client credential you are forced to use "Implicit" which I don't = believe was intended for these types of apps. Note that Implicit also is = restricted to uid/password type user credential. >=20 > Why doesn't implicit_grant have a refresh_token? I would think a = non-expiring access_token like FB offline_access would be worse option = since it is transmitted to more end points. The issuing of a token in Implicit flow depends solely on the = authentication of the end-user. Without client credentials you can't = authenticate the client to refresh the token. Thus you must repeat the = implicit flow every time. >=20 > A lot of FB Connect sites request offline_access when you connect. = Like Foursquare, Quora, Gowalla for example. >=20 > On Mar 31, 2011, at 6:00 PM, Marius Scurtescu wrote: >=20 >> On Thu, Mar 31, 2011 at 4:56 PM, Phil Hunt = wrote: >>> Done. >>>=20 >>> It isn't quite what the flow shows in the earlier diagram. I was = originally avoiding client type and trying to focus on section 4 = options. >>>=20 >>> But this should be a better diagram. >>>=20 >>> = http://independentidentity.blogspot.com/2011/03/oauth-flows-extended.html >>=20 >> A native app with no client secret is still advised to use the >> implicit grant, which is wrong IMO. >>=20 >> The right question I think is "does the client need long term offline = access"? >>=20 >> JavaScript clients typically don't need offline access (only with the >> user at the browser). Some native apps and web apps could be OK with = a >> short term offline access, one off import for example. >>=20 >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From skylar@kiva.org Mon Apr 4 11:19:45 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 885EC3A63D2 for ; Mon, 4 Apr 2011 11:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6bPmdELa2qN for ; Mon, 4 Apr 2011 11:19:41 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by core3.amsl.com (Postfix) with SMTP id 8E85A3A63CB for ; Mon, 4 Apr 2011 11:19:41 -0700 (PDT) Received: from source ([74.125.83.51]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKTZoMI0FfeFavkRYDVLJvFog+2dskZOIB@postini.com; Mon, 04 Apr 2011 11:21:24 PDT Received: by gwj17 with SMTP id 17so2539621gwj.38 for ; Mon, 04 Apr 2011 11:21:23 -0700 (PDT) Received: by 10.236.173.169 with SMTP id v29mr4878505yhl.192.1301941283212; Mon, 04 Apr 2011 11:21:23 -0700 (PDT) Received: from [192.168.2.8] (74-128-24-154.dhcp.insightbb.com [74.128.24.154]) by mx.google.com with ESMTPS id h4sm2414107yhm.80.2011.04.04.11.21.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 11:21:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <9E68D140-ED3D-4C62-A6A1-5CE1CDB5C5D9@oracle.com> Date: Mon, 4 Apr 2011 14:21:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2597C1CF-1067-404A-BFE3-DE8F55A77EA6@kiva.org> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <9E68D140-ED3D-4C62-A6A1-5CE1CDB5C5D9@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1084) Cc: Kris Selden , oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:19:45 -0000 Having worked many years with native Internet consumer software = applications, and having worked in those teams in attempt to secure = client secrets (be they keys or obfuscated dynamic algorithms), I can = say with reasonable confidence that it is impossible to secure client = credentials for publicly available applications (where the same = credential is shared against all instances of the application). Both = iPhone and PlayStation represent some of the most formidable efforts to = secure secrets or data in publicly distributed consumer products. = Systems on these have been successfully broken and this will continue to = be the case. Even if someone has a new technology to propose that they = think can prove this wrong, there is no reliable record of success for = hiding secrets in the field. We should assume any system distributed for = public review can be reverse engineered, and secrets obtained. I propose that for the sake of this discussion, we continue with the = assumption that no native apps with public distribution are able to have = client secrets. (Btw, Kris seemed to be suggesting that users could be prompted to enter = a (unique?) app ID and client secret, but this would complicate = usability, working against the goals of OAuth in the first place. I'd = agree - if native app users had to enter a custom client secret, they = might as well obtain their own private access token and enter it = instead, by passing OAuth completely). On Apr 4, 2011, at 2:02 PM, Phil Hunt wrote: > On 2011-04-04, at 10:47 AM, Kris Selden wrote: >=20 >> A typical iPhone app cannot be shipped with a client secret and = rightly or wrongly users expect to only have to enter their credentials = once. >=20 > My understanding (and I'm not an iOS expert) is that each iOS = application has a secure keystore where the client credential could be = stored. I am told this is fairly straight forward. The client app would = issue a call out to the external safari browser for the authorization = with a redirect back to the app registered (local redirect) such as = myapp://authorization_code From phil.hunt@oracle.com Mon Apr 4 11:21:39 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8BD93A63D2 for ; Mon, 4 Apr 2011 11:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMxZlTeiJj1H for ; Mon, 4 Apr 2011 11:21:37 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A64073A63CB for ; Mon, 4 Apr 2011 11:21:37 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p34INHg9026861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 18:23:18 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p34INGK2026862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2011 18:23:16 GMT Received: from abhmt021.oracle.com (abhmt021.oracle.com [141.146.116.30]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p34ING9I007048; Mon, 4 Apr 2011 13:23:16 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 11:23:15 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-67--635837174 From: Phil Hunt In-Reply-To: <188405.40029.qm@web37607.mail.mud.yahoo.com> Date: Mon, 4 Apr 2011 11:23:13 -0700 Message-Id: References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> To: Oleg Gryb X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4D9A0C95.004B:SCFSTAT5015188,ss=1,fgs=0 Cc: OAuth WG , Prateek Mishra Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:21:40 -0000 --Apple-Mail-67--635837174 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have been wondering if we can combine a couple of things such as a = client generated transaction secret and use limited TLS to achieve a = fix. Note: this would address a hacker sniffing a returned = authorization code, but it probably does little for the MITM scenario = that was also outlined. 1. The client app generate a random number or sequence of characters, = lets call it "request_id", then that value would be included and = securely (using TLS) transmitted in the authorization request. 2. The authorization server does its usual thing and returns, preferably = securely but not necessarily, the authorization code to the client app. 3. Upon requesting an access_token, the client app also includes the = same request_id in its secure request to the token endpoint. 4. The token server verifies that the "request_id" matches the = request_id supplied in the authorize request (in addition to all the = other processing). Since both requests are sent securely a sniffing client cannot obtain = the client request_id even though it might be able to obtain the = authorization code being returned. What this might allow is that the client can transmit a secret protected = by TLS in its outbound request, but can accept non-secure delivery of = the authorization code. The token server then has a means to verify = that the client exchanging the authorization code is the same one that = made the initial request. This is off the top of my head, I am sure the proposal is likely not yet = a complete solution, but maybe someone can build on that. Phil phil.hunt@oracle.com On 2011-04-04, at 10:52 AM, Oleg Gryb wrote: > After looking into exiting (and working) implementations of OAuth 1.0 = in mobile world I have strong doubts about possibility of implementing = what was suggested in option #3.=20 >=20 > In my view, two conditions are needed to achieve that: >=20 > 1. Something unique stored on a mobile client. > 2. That something should be a secret, so other (malicious) clients = could not reuse it. >=20 > Distribution of that "unique secrets" should be automated in the = mobile world and is usually included to mobile application=20 > activation process, but that activation process can't make conditions = 1 & 2 above met in full, becuase: >=20 > 1. As soon as secrets are distributed to a mobile device they are not = quite secret any more > 2. As soon as the secret becomes known, a simulator or other mobile = device can be used to spoof the traffic >=20 > I would consider option #3 as an illusion until somebody comes up with = a solution that would address the described issues. >=20 > BTW, the draft of "OAuth Dynamic Client Registration Protocol" = (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on = Feb. 12 and I didn't see any attempts to re-vitalise it. I think it = would be better and more beneficial for the community to return to this = protocol rather than inventing a new method of "mutual authentication".=20= >=20 >=20 >=20 >=20 > From: Phil Hunt > To: Prateek Mishra > Cc: OAuth WG > Sent: Mon, April 4, 2011 9:52:17 AM > Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) >=20 > Apologies for the long message (again). I have attempted to sum things = up and bring out the issue without using any existing service or party = as an example of problems. It seems some have taken offence to my = previous message pushing for a solution. As a result it was not = productive. I apologize. Hopefully this message sticks to the issue of = developing an appropriate counter measure to threats as that is my only = intent. >=20 > As Prateek clarified in the previous message to Francisco, SAML also = uses SHOULD, but artifact security is achieved by an additional = counter-measure... >> The identity provider MUST ensure that only the service provider to = whom the message has >> been issued is given the message as the result of an = request. >=20 > Yet, in OAuth the client app is not unique for a particular set of = client credentials we currently have no way to verify that the correct = client got the code. This has been the mechanism that the community has = been assuming solves the problem. Client credentials do not always work = to protect the authorization code because in OAuth you can have many = many clients with the same credential. For example everyone with the = same mobile app likely has the same client credential. Thus a copy of a = valid client app which is easy to obtain becomes the hacker's attack = vector. So, the client credential is not an effective counter in this = case. >=20 > Several have commented that there are other supplementary techniques = for protection, but in my view, most of them work indirectly and/or = depend on correct collective configuration of several components. Some = of these are: tokens may be used one time; tokens are invalidated if = used a second time, tokens are sufficiently unique, etc. All of these = will help. But none are designed to directly counter the attack. In fact = the best one - token invalidation carries the additional problem of = unreliable service for the legitimate client. The hacker can deny = service to anyone in the room simply by re-using any tokens seen. >=20 > =46rom my perspective, the "easy" solution was to increase the = requirements on TLS from SHOULD to MUST to prevent eavesdropping of the = code. This was echoed by several others. I agree this will not work for = everyone. Many have made strong arguments for why they can't use it. But = without a MUST we are still missing a direct counter to the threat. >=20 > I don't want to change things at this late date, but maybe this means = introducing some form of mutual authentication -- some way for the = requesting client "instance" to prove that they are the copy eligible to = use an authorization code.=20 >=20 > To end this discussion, I propose we vote on the proposal from Eran = plus one new option... > 1. Include a normative MUST use TLS for the client redirection URI = endpoint. > 2. Include a normative SHOULD use TLS for the client redirection URI = endpoint with strong language explaining the various attacks possible if = the endpoint is not made secure. > 3. Keep current language of SHOULD, but develop a direct = counter-measure to token theft such as specific client instance = identification or mutual authentication. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: >=20 >> Francisco, >>=20 >> You are right, I was in error to suggest that it was a MUST. >>=20 >> I think my main concern was that security considerations should not = be based on polling developers/deployers of an existing or legacy = protocol. >>=20 >> SAML does include some additional countermeasures though - for = example (lines 595-596, profiles document) - that specifically deal with = the >> artifact being leaked -=20 >>=20 >> [quote] >> The identity provider MUST ensure that only the service provider to = whom the message has >> been issued is given the message as the result of an = request. >> [\quote] >>=20 >> - prateek >>> Hi Prateek, >>>=20 >>> > I would like to strongly disagree with this proposal. >>> >=20 >>> > It amounts to explicitly making OAuth 2.0 insecure so as to >>> > satisfy some mysterious and unspecified set of legacy OAuth >>> > 1.0 deployments. >>> >=20 >>> > The SAML web SSO (artifact) profile - which shares many >>> > characteristics with the initial steps in OAuth - requires >>> > precisely such a counter-measure and is widely implemented >>> > in 1000s of deployments. >>>=20 >>> What counter-measure is this? Can you provide a reference? >>> Section 4.1.3.5 of=20 >>> = http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>> recommends TLS but does not require it. >>>=20 >>> Francisco >>>=20 >>>=20 >=20 >=20 --Apple-Mail-67--635837174 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have been wondering if we can combine a couple of things such as a = client generated transaction secret and use limited TLS to achieve a = fix.  Note: this would address a hacker sniffing a returned = authorization code, but it probably does little for the MITM scenario = that was also outlined.

1. The client app generate a = random number or sequence of characters, lets call it "request_id", then = that value would be included and securely (using TLS) transmitted in the = authorization request.
2. The authorization server does its = usual thing and returns, preferably securely but not necessarily, the = authorization code to the client app.
3. Upon requesting an = access_token, the client app also includes the same request_id in its = secure request to the token endpoint.
4. The token server = verifies that the "request_id" matches the request_id supplied in the = authorize request (in addition to all the other = processing).

Since both requests are sent = securely a sniffing client cannot obtain the client request_id even = though it might be able to obtain the authorization code being = returned.

What this might allow is that the = client can transmit a secret protected by TLS in its outbound request, = but can accept non-secure delivery of the authorization code.  The = token server then has a means to verify that the client exchanging the = authorization code is the same one that made the initial = request.

This is off the top of my head, I am = sure the proposal is likely not yet a complete solution, but maybe = someone can build on that.


On 2011-04-04, at 10:52 AM, Oleg Gryb wrote:

After looking into exiting (and working) = implementations of OAuth 1.0 in mobile world I have strong doubts about = possibility of implementing what was suggested in option #3. 

In my view, two = conditions are needed to achieve that:

1. Something unique stored = on a mobile client.
2. That something should be a secret, so other = (malicious) clients could not reuse it.

Distribution of that = "unique secrets" should be automated in the mobile world and is usually = included to mobile application 
activation process, but = that activation process can't make conditions 1 & 2 above met in = full, becuase:

1. As soon as secrets are distributed to a mobile = device they are not quite secret any more
2. As soon as the secret = becomes known, a simulator or other mobile device can be used to spoof = the traffic

I would consider option #3 as an illusion until = somebody comes up with a solution that would address the described = issues.

BTW, the draft of "OAuth Dynamic Client = Registration Protocol" (http://tools= .ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on Feb. 12 and = I didn't see any attempts to re-vitalise it. I think it would be better = and more beneficial for the community to return to this protocol rather = than inventing a new method of "mutual authentication". 




From: Phil Hunt <phil.hunt@oracle.com>
To: Prateek Mishra <prateek.mishra@oracle.com>= ;
Cc: OAuth WG <oauth@ietf.org>
Sent: Mon, April 4, 2011 9:52:17 = AM
Subject: Re: [OAUTH-WG] = Authorization code security issue (reframed)

Apologies for the long message (again). I have = attempted to sum things up and bring out the issue without using any = existing service or party as an example of problems. It seems some have = taken offence to my previous message pushing for a solution. As a result = it was not productive. I apologize.  Hopefully this message sticks = to the issue of developing an appropriate counter measure to threats as = that is my only intent.
As Prateek clarified in the = previous message to Francisco, SAML also uses SHOULD, but artifact = security is achieved by an additional counter-measure...
The = identity provider MUST ensure that only the service provider to whom the = <Response> message has
been issued is given the message as the = result of an <ArtifactResolve> = request.

Yet, in OAuth = the client app is not unique for a particular set of client credentials = we currently have no way to verify that the correct client got the code. = This has been the mechanism that the community has been assuming solves = the problem. Client credentials do not always work to protect the = authorization code because in OAuth you can have many many clients with the = same credential. For example everyone with the same mobile app = likely has the same client credential. Thus a copy of a valid client app = which is easy to obtain becomes the hacker's attack vector. So, the = client credential is not an effective counter in this case.

Several have = commented that there are other supplementary techniques for protection, = but in my view, most of them work indirectly and/or depend on correct = collective configuration of several components. Some of these are: = tokens may be used one time; tokens are invalidated if used a second = time, tokens are sufficiently unique, etc.  All of these will help. = But none are designed to directly counter the attack. In fact the best = one - token invalidation carries the additional problem of unreliable = service for the legitimate client. The hacker can deny service to anyone = in the room simply by re-using any tokens seen.

=46rom my = perspective, the "easy" solution was to increase the requirements on TLS = from SHOULD to MUST to prevent eavesdropping of the code. This was = echoed by several others. I agree this will not work = for everyone. Many = have made strong arguments for why they can't use it. But without a MUST = we are still missing a direct counter to the threat.

I don't want = to change things at this late date, but maybe this means introducing = some form of mutual authentication -- some way for the requesting client = "instance" to prove that they are the copy eligible to use an = authorization code. 
To end this discussion, I = propose we vote on the proposal from Eran plus one new = option...
1. Include a normative = MUST use TLS for the client redirection URI endpoint.
2. Include a normative SHOULD use TLS for the client = redirection URI endpoint with strong language explaining the various = attacks possible if the endpoint is not made secure.
3. Keep current language of SHOULD, but develop a = direct counter-measure to token theft such as specific client instance = identification or mutual authentication.

Phil

On 2011-04-04, at 8:57 AM, Prateek Mishra = wrote:

Francisco,

You are right, = I was in error to suggest that it was a MUST.

 I think my = main concern was that security considerations should not be based on = polling developers/deployers of an existing or legacy = protocol.

SAML does include some additional countermeasures = though - for example (lines 595-596, profiles document) - that = specifically deal with the
artifact being leaked - 

[quote]
The = identity provider MUST ensure that only the service provider to whom the = <Response> message has
been issued is given the message as the = result of an <ArtifactResolve> request.
[\quote]

- = prateek
 
> It amounts to = explicitly making OAuth 2.0 insecure so as to
> satisfy some = mysterious and unspecified set of legacy OAuth
> 1.0 = deployments.
> 
> The SAML web SSO = (artifact) profile - which shares many
> characteristics with the = initial steps in OAuth - requires
> precisely such a = counter-measure and is widely implemented
> in 1000s of = deployments.

What counter-measure is this?  Can you provide = a reference?
Section 4.1.3.5 of 
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.p= df
recommends TLS but does not require = it.

Francisco





= --Apple-Mail-67--635837174-- From mscurtescu@google.com Mon Apr 4 11:28:39 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7DD3A6405 for ; Mon, 4 Apr 2011 11:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.921 X-Spam-Level: X-Spam-Status: No, score=-105.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpnDzBazlbJB for ; Mon, 4 Apr 2011 11:28:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2BEB13A63D2 for ; Mon, 4 Apr 2011 11:28:38 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p34IUJTv001159 for ; Mon, 4 Apr 2011 11:30:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301941820; bh=HDowctoAyYiGegOdSYRr2p4VyFk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Xa+0LNnm0LWYKd4i+eE3LdjauyxTvto+t4vEgdIq8mPRJDZ5U0lbRx0y6k860IcVN VBcmexvUzO8eczDiz1Efg== Received: from ywg8 (ywg8.prod.google.com [10.192.7.8]) by hpaq14.eem.corp.google.com with ESMTP id p34ITHh6006119 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 4 Apr 2011 11:30:18 -0700 Received: by ywg8 with SMTP id 8so3369347ywg.20 for ; Mon, 04 Apr 2011 11:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Jb7Nq3qIJMgOrDBShAE7MZ+d0x1hGt5wTMFBeIujLls=; b=UYoyb9k1yfMmyH3EmVROh+BaQj/hztASmHvoVB1k56qrGq9UVovVbNxKKoXMA1aSwO N4nounb91M/SrBXotbkw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=hL02pCjeQUzjk8mfyf/UMCvyAcpuKn0G5kvGDoTYpRbTEWQLJ2cMUvekL902W49P3K XQnf5JWUW0jM2oc43rww== Received: by 10.101.65.13 with SMTP id s13mr5367624ank.148.1301941818124; Mon, 04 Apr 2011 11:30:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.34.4 with HTTP; Mon, 4 Apr 2011 11:29:58 -0700 (PDT) In-Reply-To: <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> From: Marius Scurtescu Date: Mon, 4 Apr 2011 11:29:58 -0700 Message-ID: To: Kris Selden Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:28:39 -0000 On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wrote: > A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once. > > What is the best profile to use for an app that can't have a client secret and needs a refresh token or a long lived access token? The authorization code grant, aka web server flow. The spec is misleading in this respect IMO. Marius From skylar@kiva.org Mon Apr 4 11:46:09 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C823A659C for ; Mon, 4 Apr 2011 11:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYkbozYmixXL for ; Mon, 4 Apr 2011 11:46:07 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by core3.amsl.com (Postfix) with SMTP id EC8633A63D2 for ; Mon, 4 Apr 2011 11:46:06 -0700 (PDT) Received: from source ([209.85.213.54]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKTZoSVbMFzA9+mGo16x3rNdm/a1r86p/Y@postini.com; Mon, 04 Apr 2011 11:47:50 PDT Received: by mail-yw0-f54.google.com with SMTP id 9so3017533ywf.41 for ; Mon, 04 Apr 2011 11:47:49 -0700 (PDT) Received: by 10.91.163.25 with SMTP id q25mr7167364ago.189.1301942869008; Mon, 04 Apr 2011 11:47:49 -0700 (PDT) Received: from [192.168.2.8] (74-128-24-154.dhcp.insightbb.com [74.128.24.154]) by mx.google.com with ESMTPS id x32sm5642582ana.38.2011.04.04.11.47.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 11:47:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Mon, 4 Apr 2011 14:47:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> To: Phil Hunt X-Mailer: Apple Mail (2.1084) Cc: Oleg Gryb , OAuth WG , Prateek Mishra Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:46:09 -0000 How does the client app transmit the nonce (random number) to the web = browser for redirect to the provider? If the client app does not support = HTTPS, it can't set up a secure session on its own to give the = browser/user something to pass on during the provider authorization. To me, this is nothing different that a unique value of "state" which = robust clients will already use to differentiate request flows. Such a = state variable would be exposed both on its way and back of the = provider's redirect. In any case, I see HTTPS as the simple solution here. I question if it = is in the scope of OAuth to provide a mechanism to the community to = protect against such MITM attacks between a hosted web application and = the web browser. If the nature of the data requires such protection, = the app developer (or the provider) can work to provide such security = outside of HTTPS. In the right context, tunneling customer traffic = through a provider-provided VPN could be considered a reasonable = protection for the cases folks have outlined. It just doesn't seem like = a popular need at this point, and there seem to be no easy wins for = hosted clients unable to register with a certificate authority. On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote: > I have been wondering if we can combine a couple of things such as a = client generated transaction secret and use limited TLS to achieve a = fix. Note: this would address a hacker sniffing a returned = authorization code, but it probably does little for the MITM scenario = that was also outlined. >=20 > 1. The client app generate a random number or sequence of characters, = lets call it "request_id", then that value would be included and = securely (using TLS) transmitted in the authorization request. > 2. The authorization server does its usual thing and returns, = preferably securely but not necessarily, the authorization code to the = client app. > 3. Upon requesting an access_token, the client app also includes the = same request_id in its secure request to the token endpoint. > 4. The token server verifies that the "request_id" matches the = request_id supplied in the authorize request (in addition to all the = other processing). >=20 > Since both requests are sent securely a sniffing client cannot obtain = the client request_id even though it might be able to obtain the = authorization code being returned. >=20 > What this might allow is that the client can transmit a secret = protected by TLS in its outbound request, but can accept non-secure = delivery of the authorization code. The token server then has a means = to verify that the client exchanging the authorization code is the same = one that made the initial request. >=20 > This is off the top of my head, I am sure the proposal is likely not = yet a complete solution, but maybe someone can build on that. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-04-04, at 10:52 AM, Oleg Gryb wrote: >=20 >> After looking into exiting (and working) implementations of OAuth 1.0 = in mobile world I have strong doubts about possibility of implementing = what was suggested in option #3.=20 >>=20 >> In my view, two conditions are needed to achieve that: >>=20 >> 1. Something unique stored on a mobile client. >> 2. That something should be a secret, so other (malicious) clients = could not reuse it. >>=20 >> Distribution of that "unique secrets" should be automated in the = mobile world and is usually included to mobile application=20 >> activation process, but that activation process can't make conditions = 1 & 2 above met in full, becuase: >>=20 >> 1. As soon as secrets are distributed to a mobile device they are not = quite secret any more >> 2. As soon as the secret becomes known, a simulator or other mobile = device can be used to spoof the traffic >>=20 >> I would consider option #3 as an illusion until somebody comes up = with a solution that would address the described issues. >>=20 >> BTW, the draft of "OAuth Dynamic Client Registration Protocol" = (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on = Feb. 12 and I didn't see any attempts to re-vitalise it. I think it = would be better and more beneficial for the community to return to this = protocol rather than inventing a new method of "mutual authentication".=20= >>=20 >>=20 >>=20 >>=20 >> From: Phil Hunt >> To: Prateek Mishra >> Cc: OAuth WG >> Sent: Mon, April 4, 2011 9:52:17 AM >> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) >>=20 >> Apologies for the long message (again). I have attempted to sum = things up and bring out the issue without using any existing service or = party as an example of problems. It seems some have taken offence to my = previous message pushing for a solution. As a result it was not = productive. I apologize. Hopefully this message sticks to the issue of = developing an appropriate counter measure to threats as that is my only = intent. >>=20 >> As Prateek clarified in the previous message to Francisco, SAML also = uses SHOULD, but artifact security is achieved by an additional = counter-measure... >>> The identity provider MUST ensure that only the service provider to = whom the message has >>> been issued is given the message as the result of an = request. >>=20 >> Yet, in OAuth the client app is not unique for a particular set of = client credentials we currently have no way to verify that the correct = client got the code. This has been the mechanism that the community has = been assuming solves the problem. Client credentials do not always work = to protect the authorization code because in OAuth you can have many = many clients with the same credential. For example everyone with the = same mobile app likely has the same client credential. Thus a copy of a = valid client app which is easy to obtain becomes the hacker's attack = vector. So, the client credential is not an effective counter in this = case. >>=20 >> Several have commented that there are other supplementary techniques = for protection, but in my view, most of them work indirectly and/or = depend on correct collective configuration of several components. Some = of these are: tokens may be used one time; tokens are invalidated if = used a second time, tokens are sufficiently unique, etc. All of these = will help. But none are designed to directly counter the attack. In fact = the best one - token invalidation carries the additional problem of = unreliable service for the legitimate client. The hacker can deny = service to anyone in the room simply by re-using any tokens seen. >>=20 >> =46rom my perspective, the "easy" solution was to increase the = requirements on TLS from SHOULD to MUST to prevent eavesdropping of the = code. This was echoed by several others. I agree this will not work for = everyone. Many have made strong arguments for why they can't use it. But = without a MUST we are still missing a direct counter to the threat. >>=20 >> I don't want to change things at this late date, but maybe this means = introducing some form of mutual authentication -- some way for the = requesting client "instance" to prove that they are the copy eligible to = use an authorization code.=20 >>=20 >> To end this discussion, I propose we vote on the proposal from Eran = plus one new option... >> 1. Include a normative MUST use TLS for the client redirection URI = endpoint. >> 2. Include a normative SHOULD use TLS for the client redirection URI = endpoint with strong language explaining the various attacks possible if = the endpoint is not made secure. >> 3. Keep current language of SHOULD, but develop a direct = counter-measure to token theft such as specific client instance = identification or mutual authentication. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: >>=20 >>> Francisco, >>>=20 >>> You are right, I was in error to suggest that it was a MUST. >>>=20 >>> I think my main concern was that security considerations should not = be based on polling developers/deployers of an existing or legacy = protocol. >>>=20 >>> SAML does include some additional countermeasures though - for = example (lines 595-596, profiles document) - that specifically deal with = the >>> artifact being leaked -=20 >>>=20 >>> [quote] >>> The identity provider MUST ensure that only the service provider to = whom the message has >>> been issued is given the message as the result of an = request. >>> [\quote] >>>=20 >>> - prateek >>>> Hi Prateek, >>>>=20 >>>> > I would like to strongly disagree with this proposal. >>>> >=20 >>>> > It amounts to explicitly making OAuth 2.0 insecure so as to >>>> > satisfy some mysterious and unspecified set of legacy OAuth >>>> > 1.0 deployments. >>>> >=20 >>>> > The SAML web SSO (artifact) profile - which shares many >>>> > characteristics with the initial steps in OAuth - requires >>>> > precisely such a counter-measure and is widely implemented >>>> > in 1000s of deployments. >>>>=20 >>>> What counter-measure is this? Can you provide a reference? >>>> Section 4.1.3.5 of=20 >>>> = http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>>> recommends TLS but does not require it. >>>>=20 >>>> Francisco >>>>=20 >>>>=20 >>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From skylar@kiva.org Mon Apr 4 11:52:42 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86EB3A65A5 for ; Mon, 4 Apr 2011 11:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy1RxLqV4s+v for ; Mon, 4 Apr 2011 11:52:39 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by core3.amsl.com (Postfix) with SMTP id 960E73A659C for ; Mon, 4 Apr 2011 11:52:39 -0700 (PDT) Received: from source ([209.85.160.178]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKTZoT3mi1DeCFQYejQbKnISWN2MnrKMj3@postini.com; Mon, 04 Apr 2011 11:54:22 PDT Received: by gyd12 with SMTP id 12so2786831gyd.37 for ; Mon, 04 Apr 2011 11:54:21 -0700 (PDT) Received: by 10.101.176.33 with SMTP id d33mr290anp.2.1301943261458; Mon, 04 Apr 2011 11:54:21 -0700 (PDT) Received: from [192.168.2.8] (74-128-24-154.dhcp.insightbb.com [74.128.24.154]) by mx.google.com with ESMTPS id b3sm5648236ana.50.2011.04.04.11.54.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 11:54:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Mon, 4 Apr 2011 14:54:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> To: Marius Scurtescu X-Mailer: Apple Mail (2.1084) Cc: Kris Selden , oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:52:42 -0000 I agree with Marius' points. We plan to support the auth-code flow for = native apps as well. There is no reason why native apps can't perform a = successful auth-code flow, they just do so without client credentials. = However, the spec doesn't make it clear that this is viable option. skylar On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote: > On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden = wrote: >> A typical iPhone app cannot be shipped with a client secret and = rightly or wrongly users expect to only have to enter their credentials = once. >>=20 >> What is the best profile to use for an app that can't have a client = secret and needs a refresh token or a long lived access token? >=20 > The authorization code grant, aka web server flow. >=20 > The spec is misleading in this respect IMO. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Mon Apr 4 12:02:06 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246313A6765 for ; Mon, 4 Apr 2011 12:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BByZiUzUrs-Y for ; Mon, 4 Apr 2011 12:02:04 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id DCB293A66B4 for ; Mon, 4 Apr 2011 12:02:03 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p34J3hYn001694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 19:03:44 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p34J3f8f026224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2011 19:03:42 GMT Received: from abhmt016.oracle.com (abhmt016.oracle.com [141.146.116.25]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p34J3flj008220; Mon, 4 Apr 2011 14:03:41 -0500 Received: from [192.168.1.136] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 12:03:40 -0700 References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> In-Reply-To: <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Type: text/plain; charset=us-ascii Message-Id: <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8G4) From: Phillip Hunt Date: Mon, 4 Apr 2011 12:03:38 -0700 To: Skylar Woodward X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4D9A160E.0183:SCFSTAT5015188,ss=1,fgs=0 Cc: Oleg Gryb , OAuth WG , Prateek Mishra Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:02:06 -0000 It doesn't require client side ssl.=20 Phil Sent from my phone.=20 On 2011-04-04, at 11:47, Skylar Woodward wrote: > How does the client app transmit the nonce (random number) to the web brow= ser for redirect to the provider? If the client app does not support HTTPS, i= t can't set up a secure session on its own to give the browser/user somethin= g to pass on during the provider authorization. >=20 > To me, this is nothing different that a unique value of "state" which robu= st clients will already use to differentiate request flows. Such a state var= iable would be exposed both on its way and back of the provider's redirect. >=20 >=20 > In any case, I see HTTPS as the simple solution here. I question if it is i= n the scope of OAuth to provide a mechanism to the community to protect agai= nst such MITM attacks between a hosted web application and the web browser. = If the nature of the data requires such protection, the app developer (or t= he provider) can work to provide such security outside of HTTPS. In the rig= ht context, tunneling customer traffic through a provider-provided VPN could= be considered a reasonable protection for the cases folks have outlined. I= t just doesn't seem like a popular need at this point, and there seem to be n= o easy wins for hosted clients unable to register with a certificate authori= ty. >=20 >=20 >=20 > On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote: >=20 >> I have been wondering if we can combine a couple of things such as a clie= nt generated transaction secret and use limited TLS to achieve a fix. Note:= this would address a hacker sniffing a returned authorization code, but it p= robably does little for the MITM scenario that was also outlined. >>=20 >> 1. The client app generate a random number or sequence of characters, let= s call it "request_id", then that value would be included and securely (usin= g TLS) transmitted in the authorization request. >> 2. The authorization server does its usual thing and returns, preferably s= ecurely but not necessarily, the authorization code to the client app. >> 3. Upon requesting an access_token, the client app also includes the same= request_id in its secure request to the token endpoint. >> 4. The token server verifies that the "request_id" matches the request_id= supplied in the authorize request (in addition to all the other processing)= . >>=20 >> Since both requests are sent securely a sniffing client cannot obtain the= client request_id even though it might be able to obtain the authorization c= ode being returned. >>=20 >> What this might allow is that the client can transmit a secret protected b= y TLS in its outbound request, but can accept non-secure delivery of the aut= horization code. The token server then has a means to verify that the clien= t exchanging the authorization code is the same one that made the initial re= quest. >>=20 >> This is off the top of my head, I am sure the proposal is likely not yet a= complete solution, but maybe someone can build on that. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-04-04, at 10:52 AM, Oleg Gryb wrote: >>=20 >>> After looking into exiting (and working) implementations of OAuth 1.0 in= mobile world I have strong doubts about possibility of implementing what wa= s suggested in option #3.=20 >>>=20 >>> In my view, two conditions are needed to achieve that: >>>=20 >>> 1. Something unique stored on a mobile client. >>> 2. That something should be a secret, so other (malicious) clients could= not reuse it. >>>=20 >>> Distribution of that "unique secrets" should be automated in the mobile w= orld and is usually included to mobile application=20 >>> activation process, but that activation process can't make conditions 1 &= 2 above met in full, becuase: >>>=20 >>> 1. As soon as secrets are distributed to a mobile device they are not qu= ite secret any more >>> 2. As soon as the secret becomes known, a simulator or other mobile devi= ce can be used to spoof the traffic >>>=20 >>> I would consider option #3 as an illusion until somebody comes up with a= solution that would address the described issues. >>>=20 >>> BTW, the draft of "OAuth Dynamic Client Registration Protocol" (http://t= ools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on Feb. 12 and I d= idn't see any attempts to re-vitalise it. I think it would be better and mor= e beneficial for the community to return to this protocol rather than invent= ing a new method of "mutual authentication".=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> From: Phil Hunt >>> To: Prateek Mishra >>> Cc: OAuth WG >>> Sent: Mon, April 4, 2011 9:52:17 AM >>> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) >>>=20 >>> Apologies for the long message (again). I have attempted to sum things u= p and bring out the issue without using any existing service or party as an e= xample of problems. It seems some have taken offence to my previous message p= ushing for a solution. As a result it was not productive. I apologize. Hope= fully this message sticks to the issue of developing an appropriate counter m= easure to threats as that is my only intent. >>>=20 >>> As Prateek clarified in the previous message to Francisco, SAML also use= s SHOULD, but artifact security is achieved by an additional counter-measure= ... >>>> The identity provider MUST ensure that only the service provider to who= m the message has >>>> been issued is given the message as the result of an r= equest. >>>=20 >>> Yet, in OAuth the client app is not unique for a particular set of clien= t credentials we currently have no way to verify that the correct client got= the code. This has been the mechanism that the community has been assuming s= olves the problem. Client credentials do not always work to protect the auth= orization code because in OAuth you can have many many clients with the same= credential. For example everyone with the same mobile app likely has the sa= me client credential. Thus a copy of a valid client app which is easy to obt= ain becomes the hacker's attack vector. So, the client credential is not an e= ffective counter in this case. >>>=20 >>> Several have commented that there are other supplementary techniques for= protection, but in my view, most of them work indirectly and/or depend on c= orrect collective configuration of several components. Some of these are: to= kens may be used one time; tokens are invalidated if used a second time, tok= ens are sufficiently unique, etc. All of these will help. But none are desi= gned to directly counter the attack. In fact the best one - token invalidati= on carries the additional problem of unreliable service for the legitimate c= lient. The hacker can deny service to anyone in the room simply by re-using a= ny tokens seen. >>>=20 >>> =46rom my perspective, the "easy" solution was to increase the requireme= nts on TLS from SHOULD to MUST to prevent eavesdropping of the code. This wa= s echoed by several others. I agree this will not work for everyone. Many ha= ve made strong arguments for why they can't use it. But without a MUST we ar= e still missing a direct counter to the threat. >>>=20 >>> I don't want to change things at this late date, but maybe this means in= troducing some form of mutual authentication -- some way for the requesting c= lient "instance" to prove that they are the copy eligible to use an authoriz= ation code.=20 >>>=20 >>> To end this discussion, I propose we vote on the proposal from Eran plus= one new option... >>> 1. Include a normative MUST use TLS for the client redirection URI endpo= int. >>> 2. Include a normative SHOULD use TLS for the client redirection URI end= point with strong language explaining the various attacks possible if the en= dpoint is not made secure. >>> 3. Keep current language of SHOULD, but develop a direct counter-measure= to token theft such as specific client instance identification or mutual au= thentication. >>>=20 >>> Phil >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: >>>=20 >>>> Francisco, >>>>=20 >>>> You are right, I was in error to suggest that it was a MUST. >>>>=20 >>>> I think my main concern was that security considerations should not be b= ased on polling developers/deployers of an existing or legacy protocol. >>>>=20 >>>> SAML does include some additional countermeasures though - for example (= lines 595-596, profiles document) - that specifically deal with the >>>> artifact being leaked -=20 >>>>=20 >>>> [quote] >>>> The identity provider MUST ensure that only the service provider to who= m the message has >>>> been issued is given the message as the result of an r= equest. >>>> [\quote] >>>>=20 >>>> - prateek >>>>> Hi Prateek, >>>>>=20 >>>>>> I would like to strongly disagree with this proposal. >>>>>>=20 >>>>>> It amounts to explicitly making OAuth 2.0 insecure so as to >>>>>> satisfy some mysterious and unspecified set of legacy OAuth >>>>>> 1.0 deployments. >>>>>>=20 >>>>>> The SAML web SSO (artifact) profile - which shares many >>>>>> characteristics with the initial steps in OAuth - requires >>>>>> precisely such a counter-measure and is widely implemented >>>>>> in 1000s of deployments. >>>>>=20 >>>>> What counter-measure is this? Can you provide a reference? >>>>> Section 4.1.3.5 of=20 >>>>> http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf= >>>>> recommends TLS but does not require it. >>>>>=20 >>>>> Francisco >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From Michael.Jones@microsoft.com Mon Apr 4 12:04:43 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 845CD3A67AA for ; Mon, 4 Apr 2011 12:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ycJgDp9+eCZ for ; Mon, 4 Apr 2011 12:04:42 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 9B5CA3A6452 for ; Mon, 4 Apr 2011 12:04:42 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 4 Apr 2011 12:06:24 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.38]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0270.002; Mon, 4 Apr 2011 12:06:24 -0700 From: Mike Jones To: Skylar Woodward , Marius Scurtescu Thread-Topic: Guidance on Native Applications in the Framework Spec (was Flowchart for legs of OAuth) Thread-Index: Acvy+2PM0mazYfusS8qdLymhVsK+oA== Date: Mon, 4 Apr 2011 19:06:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252CA711@TK5EX14MBXC203.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.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Kris Selden , "oauth@ietf.org" Subject: [OAUTH-WG] Guidance on Native Applications in the Framework Spec (was Flowchart for legs of OAuth) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:04:43 -0000 One of the results at the OAuth meeting on Friday was that non-normative te= xt describing how to use OAuth with native applications will be restored to= the framework draft. We could start with the text from past drafts, but i= t can likely be improved upon as well. Marius, as someone who has extensively deployed an OAuth protocol with nati= ve apps, what would you like the draft to say about this? (Others with act= ual deployments, please respond as well if you have things to add!) Thanks, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of S= kylar Woodward Sent: Monday, April 04, 2011 11:54 AM To: Marius Scurtescu Cc: Kris Selden; oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth I agree with Marius' points. We plan to support the auth-code flow for nati= ve apps as well. There is no reason why native apps can't perform a succes= sful auth-code flow, they just do so without client credentials. However, = the spec doesn't make it clear that this is viable option. skylar On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote: > On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wrot= e: >> A typical iPhone app cannot be shipped with a client secret and rightly = or wrongly users expect to only have to enter their credentials once. >>=20 >> What is the best profile to use for an app that can't have a client secr= et and needs a refresh token or a long lived access token? >=20 > The authorization code grant, aka web server flow. >=20 > The spec is misleading in this respect IMO. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From skylar@kiva.org Mon Apr 4 12:06:42 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979B63A6452 for ; Mon, 4 Apr 2011 12:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9T+se00PUqL for ; Mon, 4 Apr 2011 12:06:40 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by core3.amsl.com (Postfix) with SMTP id AD3B93A6407 for ; Mon, 4 Apr 2011 12:06:39 -0700 (PDT) Received: from source ([74.125.83.45]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKTZoXJR+9eYe6i0fVhBNCyeUuWQeLh16i@postini.com; Mon, 04 Apr 2011 12:08:22 PDT Received: by gwb19 with SMTP id 19so2835717gwb.18 for ; Mon, 04 Apr 2011 12:08:21 -0700 (PDT) Received: by 10.236.184.67 with SMTP id r43mr10585045yhm.222.1301944100883; Mon, 04 Apr 2011 12:08:20 -0700 (PDT) Received: from [192.168.2.8] (74-128-24-154.dhcp.insightbb.com [74.128.24.154]) by mx.google.com with ESMTPS id f32sm2439789yhc.28.2011.04.04.12.08.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 12:08:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> Date: Mon, 4 Apr 2011 15:08:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> To: Phillip Hunt X-Mailer: Apple Mail (2.1084) Cc: Oleg Gryb , OAuth WG , Prateek Mishra Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:06:42 -0000 Maybe you can explain your example in more detail then? I'm assuming = your "client app" is a web application hosted on web server supporting = only HTTP. How does the nonce or request_id get to the provider as part of the = authorization request in your example? (step 1) On Apr 4, 2011, at 3:03 PM, Phillip Hunt wrote: > It doesn't require client side ssl.=20 >=20 > Phil >=20 > Sent from my phone.=20 >=20 > On 2011-04-04, at 11:47, Skylar Woodward wrote: >=20 >> How does the client app transmit the nonce (random number) to the web = browser for redirect to the provider? If the client app does not support = HTTPS, it can't set up a secure session on its own to give the = browser/user something to pass on during the provider authorization. >>=20 >> To me, this is nothing different that a unique value of "state" which = robust clients will already use to differentiate request flows. Such a = state variable would be exposed both on its way and back of the = provider's redirect. >>=20 >>=20 >> In any case, I see HTTPS as the simple solution here. I question if = it is in the scope of OAuth to provide a mechanism to the community to = protect against such MITM attacks between a hosted web application and = the web browser. If the nature of the data requires such protection, = the app developer (or the provider) can work to provide such security = outside of HTTPS. In the right context, tunneling customer traffic = through a provider-provided VPN could be considered a reasonable = protection for the cases folks have outlined. It just doesn't seem like = a popular need at this point, and there seem to be no easy wins for = hosted clients unable to register with a certificate authority. >>=20 >>=20 >>=20 >> On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote: >>=20 >>> I have been wondering if we can combine a couple of things such as a = client generated transaction secret and use limited TLS to achieve a = fix. Note: this would address a hacker sniffing a returned = authorization code, but it probably does little for the MITM scenario = that was also outlined. >>>=20 >>> 1. The client app generate a random number or sequence of = characters, lets call it "request_id", then that value would be included = and securely (using TLS) transmitted in the authorization request. >>> 2. The authorization server does its usual thing and returns, = preferably securely but not necessarily, the authorization code to the = client app. >>> 3. Upon requesting an access_token, the client app also includes the = same request_id in its secure request to the token endpoint. >>> 4. The token server verifies that the "request_id" matches the = request_id supplied in the authorize request (in addition to all the = other processing). >>>=20 >>> Since both requests are sent securely a sniffing client cannot = obtain the client request_id even though it might be able to obtain the = authorization code being returned. >>>=20 >>> What this might allow is that the client can transmit a secret = protected by TLS in its outbound request, but can accept non-secure = delivery of the authorization code. The token server then has a means = to verify that the client exchanging the authorization code is the same = one that made the initial request. >>>=20 >>> This is off the top of my head, I am sure the proposal is likely not = yet a complete solution, but maybe someone can build on that. >>>=20 >>> Phil >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2011-04-04, at 10:52 AM, Oleg Gryb wrote: >>>=20 >>>> After looking into exiting (and working) implementations of OAuth = 1.0 in mobile world I have strong doubts about possibility of = implementing what was suggested in option #3.=20 >>>>=20 >>>> In my view, two conditions are needed to achieve that: >>>>=20 >>>> 1. Something unique stored on a mobile client. >>>> 2. That something should be a secret, so other (malicious) clients = could not reuse it. >>>>=20 >>>> Distribution of that "unique secrets" should be automated in the = mobile world and is usually included to mobile application=20 >>>> activation process, but that activation process can't make = conditions 1 & 2 above met in full, becuase: >>>>=20 >>>> 1. As soon as secrets are distributed to a mobile device they are = not quite secret any more >>>> 2. As soon as the secret becomes known, a simulator or other mobile = device can be used to spoof the traffic >>>>=20 >>>> I would consider option #3 as an illusion until somebody comes up = with a solution that would address the described issues. >>>>=20 >>>> BTW, the draft of "OAuth Dynamic Client Registration Protocol" = (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on = Feb. 12 and I didn't see any attempts to re-vitalise it. I think it = would be better and more beneficial for the community to return to this = protocol rather than inventing a new method of "mutual authentication".=20= >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> From: Phil Hunt >>>> To: Prateek Mishra >>>> Cc: OAuth WG >>>> Sent: Mon, April 4, 2011 9:52:17 AM >>>> Subject: Re: [OAUTH-WG] Authorization code security issue = (reframed) >>>>=20 >>>> Apologies for the long message (again). I have attempted to sum = things up and bring out the issue without using any existing service or = party as an example of problems. It seems some have taken offence to my = previous message pushing for a solution. As a result it was not = productive. I apologize. Hopefully this message sticks to the issue of = developing an appropriate counter measure to threats as that is my only = intent. >>>>=20 >>>> As Prateek clarified in the previous message to Francisco, SAML = also uses SHOULD, but artifact security is achieved by an additional = counter-measure... >>>>> The identity provider MUST ensure that only the service provider = to whom the message has >>>>> been issued is given the message as the result of an = request. >>>>=20 >>>> Yet, in OAuth the client app is not unique for a particular set of = client credentials we currently have no way to verify that the correct = client got the code. This has been the mechanism that the community has = been assuming solves the problem. Client credentials do not always work = to protect the authorization code because in OAuth you can have many = many clients with the same credential. For example everyone with the = same mobile app likely has the same client credential. Thus a copy of a = valid client app which is easy to obtain becomes the hacker's attack = vector. So, the client credential is not an effective counter in this = case. >>>>=20 >>>> Several have commented that there are other supplementary = techniques for protection, but in my view, most of them work indirectly = and/or depend on correct collective configuration of several components. = Some of these are: tokens may be used one time; tokens are invalidated = if used a second time, tokens are sufficiently unique, etc. All of = these will help. But none are designed to directly counter the attack. = In fact the best one - token invalidation carries the additional problem = of unreliable service for the legitimate client. The hacker can deny = service to anyone in the room simply by re-using any tokens seen. >>>>=20 >>>> =46rom my perspective, the "easy" solution was to increase the = requirements on TLS from SHOULD to MUST to prevent eavesdropping of the = code. This was echoed by several others. I agree this will not work for = everyone. Many have made strong arguments for why they can't use it. But = without a MUST we are still missing a direct counter to the threat. >>>>=20 >>>> I don't want to change things at this late date, but maybe this = means introducing some form of mutual authentication -- some way for the = requesting client "instance" to prove that they are the copy eligible to = use an authorization code.=20 >>>>=20 >>>> To end this discussion, I propose we vote on the proposal from Eran = plus one new option... >>>> 1. Include a normative MUST use TLS for the client redirection URI = endpoint. >>>> 2. Include a normative SHOULD use TLS for the client redirection = URI endpoint with strong language explaining the various attacks = possible if the endpoint is not made secure. >>>> 3. Keep current language of SHOULD, but develop a direct = counter-measure to token theft such as specific client instance = identification or mutual authentication. >>>>=20 >>>> Phil >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: >>>>=20 >>>>> Francisco, >>>>>=20 >>>>> You are right, I was in error to suggest that it was a MUST. >>>>>=20 >>>>> I think my main concern was that security considerations should = not be based on polling developers/deployers of an existing or legacy = protocol. >>>>>=20 >>>>> SAML does include some additional countermeasures though - for = example (lines 595-596, profiles document) - that specifically deal with = the >>>>> artifact being leaked -=20 >>>>>=20 >>>>> [quote] >>>>> The identity provider MUST ensure that only the service provider = to whom the message has >>>>> been issued is given the message as the result of an = request. >>>>> [\quote] >>>>>=20 >>>>> - prateek >>>>>> Hi Prateek, >>>>>>=20 >>>>>>> I would like to strongly disagree with this proposal. >>>>>>>=20 >>>>>>> It amounts to explicitly making OAuth 2.0 insecure so as to >>>>>>> satisfy some mysterious and unspecified set of legacy OAuth >>>>>>> 1.0 deployments. >>>>>>>=20 >>>>>>> The SAML web SSO (artifact) profile - which shares many >>>>>>> characteristics with the initial steps in OAuth - requires >>>>>>> precisely such a counter-measure and is widely implemented >>>>>>> in 1000s of deployments. >>>>>>=20 >>>>>> What counter-measure is this? Can you provide a reference? >>>>>> Section 4.1.3.5 of=20 >>>>>> = http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>>>>> recommends TLS but does not require it. >>>>>>=20 >>>>>> Francisco >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 From kris.selden@gmail.com Mon Apr 4 12:08:12 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771043A67AA for ; Mon, 4 Apr 2011 12:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omTfRAd2nRha for ; Mon, 4 Apr 2011 12:08:11 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id C59C83A6407 for ; Mon, 4 Apr 2011 12:08:11 -0700 (PDT) Received: by pxi20 with SMTP id 20so2385157pxi.27 for ; Mon, 04 Apr 2011 12:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=XfDMTbWel+UNLu2DaIt+E3XEuVJnHQ+n66zVkmeAWPY=; b=fWZccmO2xKe6W+hZcssHW9EjbatdbkdynFPNmabj4T95gtgAMdxOClJ7pr90hIRLt3 GENpozstAs1hwVsc0kOUNCLoNDjCFDFKosuQXjlvC4C48JK1ktgVnO06XMzdGDbT6Ams swmt02LzDDWvVJMg9i+rk7iGRYvGVk9utTjpY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=pUWsiHCyCp9dsS3h28Q04/pfRiQD1f+JDbOP3hpjxKESSVq2fYedBnBcgQY/BRk2f3 5+eXORW5wEdFS8FBP742DPm4HCiG2piA6/bub4ls1J8L6iRX3397R5SoeAufi36RXzU1 ap8a66isbnMbrDLn6BiO7qkZaLryE95di8/vA= Received: by 10.142.202.16 with SMTP id z16mr6770718wff.6.1301944194497; Mon, 04 Apr 2011 12:09:54 -0700 (PDT) Received: from [172.16.176.22] ([74.212.130.213]) by mx.google.com with ESMTPS id s39sm7923288wfc.16.2011.04.04.12.09.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 12:09:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Kris Selden In-Reply-To: <2597C1CF-1067-404A-BFE3-DE8F55A77EA6@kiva.org> Date: Mon, 4 Apr 2011 12:09:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <66F1ABA3-4A1E-4B18-94D4-A431FA9DE126@gmail.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <9E68D140-ED3D-4C62-A6A1-5CE1CDB5C5D9@oracle.com> <2597C1CF-1067-404A-BFE3-DE8F55A77EA6@kiva.org> To: Skylar Woodward X-Mailer: Apple Mail (2.1082) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:08:12 -0000 I completely agree with you regarding not being able to authenticate a = native client. The problem with web flow is the user experience is bad for a native = app. Why does this matter? Because of competition =96 if competitors = use a user friendly but less secure method and the end user does not = know it is bad for them, then because of market forces you have to do = the same. As a startup developer, I cannot tell the business side that our UI has = to be worse than their Facebook app, Twitter client or Instagram on = their phone because that isn't secure. They're going to look at me like = I'm crazy. If the end user is ignorant, educating them comes at too high of a price = for a startup. The end user cares about their safety but assumes that = big companies are the bar for security. On Apr 4, 2011, at 11:21 AM, Skylar Woodward wrote: > Having worked many years with native Internet consumer software = applications, and having worked in those teams in attempt to secure = client secrets (be they keys or obfuscated dynamic algorithms), I can = say with reasonable confidence that it is impossible to secure client = credentials for publicly available applications (where the same = credential is shared against all instances of the application). Both = iPhone and PlayStation represent some of the most formidable efforts to = secure secrets or data in publicly distributed consumer products. = Systems on these have been successfully broken and this will continue to = be the case. Even if someone has a new technology to propose that they = think can prove this wrong, there is no reliable record of success for = hiding secrets in the field. We should assume any system distributed for = public review can be reverse engineered, and secrets obtained. >=20 > I propose that for the sake of this discussion, we continue with the = assumption that no native apps with public distribution are able to have = client secrets. >=20 >=20 > (Btw, Kris seemed to be suggesting that users could be prompted to = enter a (unique?) app ID and client secret, but this would complicate = usability, working against the goals of OAuth in the first place. I'd = agree - if native app users had to enter a custom client secret, they = might as well obtain their own private access token and enter it = instead, by passing OAuth completely). >=20 > On Apr 4, 2011, at 2:02 PM, Phil Hunt wrote: >=20 >> On 2011-04-04, at 10:47 AM, Kris Selden wrote: >>=20 >>> A typical iPhone app cannot be shipped with a client secret and = rightly or wrongly users expect to only have to enter their credentials = once. >>=20 >> My understanding (and I'm not an iOS expert) is that each iOS = application has a secure keystore where the client credential could be = stored. I am told this is fairly straight forward. The client app would = issue a call out to the external safari browser for the authorization = with a redirect back to the app registered (local redirect) such as = myapp://authorization_code >=20 From tonynad@microsoft.com Mon Apr 4 12:09:06 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92BF73A659C for ; Mon, 4 Apr 2011 12:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.406 X-Spam-Level: X-Spam-Status: No, score=-7.406 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbIStbPKRfYM for ; Mon, 4 Apr 2011 12:09:05 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id AF2CD3A6452 for ; Mon, 4 Apr 2011 12:09:05 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 4 Apr 2011 12:10:48 -0700 Received: from VA3EHSOBE007.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 4 Apr 2011 12:10:48 -0700 Received: from mail88-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.8; Mon, 4 Apr 2011 19:10:47 +0000 Received: from mail88-va3 (localhost.localdomain [127.0.0.1]) by mail88-va3-R.bigfish.com (Postfix) with ESMTP id 61CD58003C2 for ; Mon, 4 Apr 2011 19:10:47 +0000 (UTC) X-SpamScore: -49 X-BigFish: PS-49(zz9371P542N1432N98dK4015LzzdafM1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:SN1PRD0302HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail88-va3 (localhost.localdomain [127.0.0.1]) by mail88-va3 (MessageSwitch) id 1301944246502953_28999; Mon, 4 Apr 2011 19:10:46 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.242]) by mail88-va3.bigfish.com (Postfix) with ESMTP id 6E1FD4C0060; Mon, 4 Apr 2011 19:10:46 +0000 (UTC) Received: from SN1PRD0302HT001.namprd03.prod.outlook.com (65.55.94.9) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 4 Apr 2011 19:10:39 +0000 Received: from SN1PRD0302MB100.namprd03.prod.outlook.com ([169.254.10.226]) by SN1PRD0302HT001.namprd03.prod.outlook.com ([10.14.149.47]) with mapi id 14.01.0225.027; Mon, 4 Apr 2011 19:10:37 +0000 From: Anthony Nadalin To: Mike Jones , Skylar Woodward , Marius Scurtescu Thread-Topic: [OAUTH-WG] Guidance on Native Applications in the Framework Spec (was Flowchart for legs of OAuth) Thread-Index: Acvy+2PM0mazYfusS8qdLymhVsK+oAAAF0Qw Date: Mon, 4 Apr 2011 19:10:36 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943252CA711@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252CA711@TK5EX14MBXC203.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN1PRD0302HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%KIVA.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Guidance on Native Applications in the Framework Spec (was Flowchart for legs of OAuth) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:09:06 -0000 So the rewrite of the text was given to Torsten and myself as action items,= but welcome others to help out here -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, April 04, 2011 12:06 PM To: Skylar Woodward; Marius Scurtescu Cc: Kris Selden; oauth@ietf.org Subject: [OAUTH-WG] Guidance on Native Applications in the Framework Spec (= was Flowchart for legs of OAuth) One of the results at the OAuth meeting on Friday was that non-normative te= xt describing how to use OAuth with native applications will be restored to= the framework draft. We could start with the text from past drafts, but i= t can likely be improved upon as well. Marius, as someone who has extensively deployed an OAuth protocol with nati= ve apps, what would you like the draft to say about this? (Others with act= ual deployments, please respond as well if you have things to add!) Thanks, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of S= kylar Woodward Sent: Monday, April 04, 2011 11:54 AM To: Marius Scurtescu Cc: Kris Selden; oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth I agree with Marius' points. We plan to support the auth-code flow for nati= ve apps as well. There is no reason why native apps can't perform a succes= sful auth-code flow, they just do so without client credentials. However, = the spec doesn't make it clear that this is viable option. skylar On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote: > On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wrot= e: >> A typical iPhone app cannot be shipped with a client secret and rightly = or wrongly users expect to only have to enter their credentials once. >>=20 >> What is the best profile to use for an app that can't have a client secr= et and needs a refresh token or a long lived access token? >=20 > The authorization code grant, aka web server flow. >=20 > The spec is misleading in this respect IMO. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Mon Apr 4 12:10:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502D13A66B4 for ; Mon, 4 Apr 2011 12:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPQCI9J1rAhE for ; Mon, 4 Apr 2011 12:10:54 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 048CA3A6407 for ; Mon, 4 Apr 2011 12:10:53 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p34JCXUI023448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 19:12:35 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p34JCW3V024150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2011 19:12:33 GMT Received: from abhmt016.oracle.com (abhmt016.oracle.com [141.146.116.25]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p34JCWDj026098; Mon, 4 Apr 2011 14:12:33 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 12:12:32 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Mon, 4 Apr 2011 12:12:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> To: Skylar Woodward X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4D9A1821.00DF:SCFSTAT5015188,ss=1,fgs=0 Cc: Oleg Gryb , OAuth WG , Prateek Mishra Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:10:56 -0000 I was referring to a mobile client that passes the request via an = external browser. That browser is capable of running SSL with server = authentication only. Phil phil.hunt@oracle.com On 2011-04-04, at 12:08 PM, Skylar Woodward wrote: > Maybe you can explain your example in more detail then? I'm assuming = your "client app" is a web application hosted on web server supporting = only HTTP. >=20 > How does the nonce or request_id get to the provider as part of the = authorization request in your example? (step 1) >=20 >=20 > On Apr 4, 2011, at 3:03 PM, Phillip Hunt wrote: >=20 >> It doesn't require client side ssl.=20 >>=20 >> Phil >>=20 >> Sent from my phone.=20 >>=20 >> On 2011-04-04, at 11:47, Skylar Woodward wrote: >>=20 >>> How does the client app transmit the nonce (random number) to the = web browser for redirect to the provider? If the client app does not = support HTTPS, it can't set up a secure session on its own to give the = browser/user something to pass on during the provider authorization. >>>=20 >>> To me, this is nothing different that a unique value of "state" = which robust clients will already use to differentiate request flows. = Such a state variable would be exposed both on its way and back of the = provider's redirect. >>>=20 >>>=20 >>> In any case, I see HTTPS as the simple solution here. I question if = it is in the scope of OAuth to provide a mechanism to the community to = protect against such MITM attacks between a hosted web application and = the web browser. If the nature of the data requires such protection, = the app developer (or the provider) can work to provide such security = outside of HTTPS. In the right context, tunneling customer traffic = through a provider-provided VPN could be considered a reasonable = protection for the cases folks have outlined. It just doesn't seem like = a popular need at this point, and there seem to be no easy wins for = hosted clients unable to register with a certificate authority. >>>=20 >>>=20 >>>=20 >>> On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote: >>>=20 >>>> I have been wondering if we can combine a couple of things such as = a client generated transaction secret and use limited TLS to achieve a = fix. Note: this would address a hacker sniffing a returned = authorization code, but it probably does little for the MITM scenario = that was also outlined. >>>>=20 >>>> 1. The client app generate a random number or sequence of = characters, lets call it "request_id", then that value would be included = and securely (using TLS) transmitted in the authorization request. >>>> 2. The authorization server does its usual thing and returns, = preferably securely but not necessarily, the authorization code to the = client app. >>>> 3. Upon requesting an access_token, the client app also includes = the same request_id in its secure request to the token endpoint. >>>> 4. The token server verifies that the "request_id" matches the = request_id supplied in the authorize request (in addition to all the = other processing). >>>>=20 >>>> Since both requests are sent securely a sniffing client cannot = obtain the client request_id even though it might be able to obtain the = authorization code being returned. >>>>=20 >>>> What this might allow is that the client can transmit a secret = protected by TLS in its outbound request, but can accept non-secure = delivery of the authorization code. The token server then has a means = to verify that the client exchanging the authorization code is the same = one that made the initial request. >>>>=20 >>>> This is off the top of my head, I am sure the proposal is likely = not yet a complete solution, but maybe someone can build on that. >>>>=20 >>>> Phil >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2011-04-04, at 10:52 AM, Oleg Gryb wrote: >>>>=20 >>>>> After looking into exiting (and working) implementations of OAuth = 1.0 in mobile world I have strong doubts about possibility of = implementing what was suggested in option #3.=20 >>>>>=20 >>>>> In my view, two conditions are needed to achieve that: >>>>>=20 >>>>> 1. Something unique stored on a mobile client. >>>>> 2. That something should be a secret, so other (malicious) clients = could not reuse it. >>>>>=20 >>>>> Distribution of that "unique secrets" should be automated in the = mobile world and is usually included to mobile application=20 >>>>> activation process, but that activation process can't make = conditions 1 & 2 above met in full, becuase: >>>>>=20 >>>>> 1. As soon as secrets are distributed to a mobile device they are = not quite secret any more >>>>> 2. As soon as the secret becomes known, a simulator or other = mobile device can be used to spoof the traffic >>>>>=20 >>>>> I would consider option #3 as an illusion until somebody comes up = with a solution that would address the described issues. >>>>>=20 >>>>> BTW, the draft of "OAuth Dynamic Client Registration Protocol" = (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on = Feb. 12 and I didn't see any attempts to re-vitalise it. I think it = would be better and more beneficial for the community to return to this = protocol rather than inventing a new method of "mutual authentication".=20= >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From: Phil Hunt >>>>> To: Prateek Mishra >>>>> Cc: OAuth WG >>>>> Sent: Mon, April 4, 2011 9:52:17 AM >>>>> Subject: Re: [OAUTH-WG] Authorization code security issue = (reframed) >>>>>=20 >>>>> Apologies for the long message (again). I have attempted to sum = things up and bring out the issue without using any existing service or = party as an example of problems. It seems some have taken offence to my = previous message pushing for a solution. As a result it was not = productive. I apologize. Hopefully this message sticks to the issue of = developing an appropriate counter measure to threats as that is my only = intent. >>>>>=20 >>>>> As Prateek clarified in the previous message to Francisco, SAML = also uses SHOULD, but artifact security is achieved by an additional = counter-measure... >>>>>> The identity provider MUST ensure that only the service provider = to whom the message has >>>>>> been issued is given the message as the result of an = request. >>>>>=20 >>>>> Yet, in OAuth the client app is not unique for a particular set of = client credentials we currently have no way to verify that the correct = client got the code. This has been the mechanism that the community has = been assuming solves the problem. Client credentials do not always work = to protect the authorization code because in OAuth you can have many = many clients with the same credential. For example everyone with the = same mobile app likely has the same client credential. Thus a copy of a = valid client app which is easy to obtain becomes the hacker's attack = vector. So, the client credential is not an effective counter in this = case. >>>>>=20 >>>>> Several have commented that there are other supplementary = techniques for protection, but in my view, most of them work indirectly = and/or depend on correct collective configuration of several components. = Some of these are: tokens may be used one time; tokens are invalidated = if used a second time, tokens are sufficiently unique, etc. All of = these will help. But none are designed to directly counter the attack. = In fact the best one - token invalidation carries the additional problem = of unreliable service for the legitimate client. The hacker can deny = service to anyone in the room simply by re-using any tokens seen. >>>>>=20 >>>>> =46rom my perspective, the "easy" solution was to increase the = requirements on TLS from SHOULD to MUST to prevent eavesdropping of the = code. This was echoed by several others. I agree this will not work for = everyone. Many have made strong arguments for why they can't use it. But = without a MUST we are still missing a direct counter to the threat. >>>>>=20 >>>>> I don't want to change things at this late date, but maybe this = means introducing some form of mutual authentication -- some way for the = requesting client "instance" to prove that they are the copy eligible to = use an authorization code.=20 >>>>>=20 >>>>> To end this discussion, I propose we vote on the proposal from = Eran plus one new option... >>>>> 1. Include a normative MUST use TLS for the client redirection URI = endpoint. >>>>> 2. Include a normative SHOULD use TLS for the client redirection = URI endpoint with strong language explaining the various attacks = possible if the endpoint is not made secure. >>>>> 3. Keep current language of SHOULD, but develop a direct = counter-measure to token theft such as specific client instance = identification or mutual authentication. >>>>>=20 >>>>> Phil >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: >>>>>=20 >>>>>> Francisco, >>>>>>=20 >>>>>> You are right, I was in error to suggest that it was a MUST. >>>>>>=20 >>>>>> I think my main concern was that security considerations should = not be based on polling developers/deployers of an existing or legacy = protocol. >>>>>>=20 >>>>>> SAML does include some additional countermeasures though - for = example (lines 595-596, profiles document) - that specifically deal with = the >>>>>> artifact being leaked -=20 >>>>>>=20 >>>>>> [quote] >>>>>> The identity provider MUST ensure that only the service provider = to whom the message has >>>>>> been issued is given the message as the result of an = request. >>>>>> [\quote] >>>>>>=20 >>>>>> - prateek >>>>>>> Hi Prateek, >>>>>>>=20 >>>>>>>> I would like to strongly disagree with this proposal. >>>>>>>>=20 >>>>>>>> It amounts to explicitly making OAuth 2.0 insecure so as to >>>>>>>> satisfy some mysterious and unspecified set of legacy OAuth >>>>>>>> 1.0 deployments. >>>>>>>>=20 >>>>>>>> The SAML web SSO (artifact) profile - which shares many >>>>>>>> characteristics with the initial steps in OAuth - requires >>>>>>>> precisely such a counter-measure and is widely implemented >>>>>>>> in 1000s of deployments. >>>>>>>=20 >>>>>>> What counter-measure is this? Can you provide a reference? >>>>>>> Section 4.1.3.5 of=20 >>>>>>> = http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>>>>>> recommends TLS but does not require it. >>>>>>>=20 >>>>>>> Francisco >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From tonynad@microsoft.com Mon Apr 4 12:11:51 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7A73A6452 for ; Mon, 4 Apr 2011 12:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.409 X-Spam-Level: X-Spam-Status: No, score=-7.409 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy6MSv0zu0Ms for ; Mon, 4 Apr 2011 12:11:50 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1E52F3A6407 for ; Mon, 4 Apr 2011 12:11:50 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 4 Apr 2011 12:13:32 -0700 Received: from VA3EHSOBE005.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 4 Apr 2011 12:13:32 -0700 Received: from mail22-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.8; Mon, 4 Apr 2011 19:13:09 +0000 Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3-R.bigfish.com (Postfix) with ESMTP id 6CDDE9380D7 for ; Mon, 4 Apr 2011 19:13:09 +0000 (UTC) X-SpamScore: -53 X-BigFish: PS-53(zz1503M936eK9371P542N1432N98dKzzdafM1202h1082kzz1033IL8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:SN1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3 (MessageSwitch) id 1301944388921518_15567; Mon, 4 Apr 2011 19:13:08 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.251]) by mail22-va3.bigfish.com (Postfix) with ESMTP id DAC641410051; Mon, 4 Apr 2011 19:13:08 +0000 (UTC) Received: from SN1PRD0302HT002.namprd03.prod.outlook.com (65.55.94.9) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 4 Apr 2011 19:13:00 +0000 Received: from SN1PRD0302MB100.namprd03.prod.outlook.com ([169.254.10.226]) by SN1PRD0302HT002.namprd03.prod.outlook.com ([10.14.149.46]) with mapi id 14.01.0225.027; Mon, 4 Apr 2011 19:12:59 +0000 From: Anthony Nadalin To: Kris Selden , Skylar Woodward Thread-Topic: [OAUTH-WG] Flowchart for legs of OAuth Thread-Index: AQHL0ipTtjZaSpjXs0eFEWU3KTMxjpQz2uqAgAAT4ICAAAPGgIABMnkAgAZCNgCAAB0bAIAM0bmAgAAELICAABHMgIAF0E4AgAAEPQCAAAVGAIAADY8AgAAAyvA= Date: Mon, 4 Apr 2011 19:12:58 +0000 Message-ID: References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <9E68D140-ED3D-4C62-A6A1-5CE1CDB5C5D9@oracle.com> <2597C1CF-1067-404A-BFE3-DE8F55A77EA6@kiva.org> <66F1ABA3-4A1E-4B18-94D4-A431FA9DE126@gmail.com> In-Reply-To: <66F1ABA3-4A1E-4B18-94D4-A431FA9DE126@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN1PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%KIVA.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:11:51 -0000 > I completely agree with you regarding not being able to authenticate a na= tive client. I suggest you read the security considerations draft to make sure this is c= orrect and points out the issues -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of K= ris Selden Sent: Monday, April 04, 2011 12:10 PM To: Skylar Woodward Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth I completely agree with you regarding not being able to authenticate a nati= ve client. The problem with web flow is the user experience is bad for a native app. = Why does this matter? Because of competition - if competitors use a user f= riendly but less secure method and the end user does not know it is bad for= them, then because of market forces you have to do the same. As a startup developer, I cannot tell the business side that our UI has to = be worse than their Facebook app, Twitter client or Instagram on their phon= e because that isn't secure. They're going to look at me like I'm crazy. If the end user is ignorant, educating them comes at too high of a price fo= r a startup. The end user cares about their safety but assumes that big co= mpanies are the bar for security. On Apr 4, 2011, at 11:21 AM, Skylar Woodward wrote: > Having worked many years with native Internet consumer software applicati= ons, and having worked in those teams in attempt to secure client secrets (= be they keys or obfuscated dynamic algorithms), I can say with reasonable c= onfidence that it is impossible to secure client credentials for publicly a= vailable applications (where the same credential is shared against all inst= ances of the application). Both iPhone and PlayStation represent some of t= he most formidable efforts to secure secrets or data in publicly distribute= d consumer products. Systems on these have been successfully broken and th= is will continue to be the case. Even if someone has a new technology to p= ropose that they think can prove this wrong, there is no reliable record of= success for hiding secrets in the field. We should assume any system distr= ibuted for public review can be reverse engineered, and secrets obtained. >=20 > I propose that for the sake of this discussion, we continue with the assu= mption that no native apps with public distribution are able to have client= secrets. >=20 >=20 > (Btw, Kris seemed to be suggesting that users could be prompted to enter = a (unique?) app ID and client secret, but this would complicate usability, = working against the goals of OAuth in the first place. I'd agree - if nativ= e app users had to enter a custom client secret, they might as well obtain = their own private access token and enter it instead, by passing OAuth compl= etely). >=20 > On Apr 4, 2011, at 2:02 PM, Phil Hunt wrote: >=20 >> On 2011-04-04, at 10:47 AM, Kris Selden wrote: >>=20 >>> A typical iPhone app cannot be shipped with a client secret and rightly= or wrongly users expect to only have to enter their credentials once. >>=20 >> My understanding (and I'm not an iOS expert) is that each iOS applicatio= n has a secure keystore where the client credential could be stored. I am t= old this is fairly straight forward. The client app would issue a call out = to the external safari browser for the authorization with a redirect back t= o the app registered (local redirect) such as myapp://authorization_code >=20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Mon Apr 4 12:13:26 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D07D3A6452 for ; Mon, 4 Apr 2011 12:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.925 X-Spam-Level: X-Spam-Status: No, score=-105.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIB4d7qF-W+D for ; Mon, 4 Apr 2011 12:13:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 921E63A6407 for ; Mon, 4 Apr 2011 12:13:25 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p34JF7N0031358 for ; Mon, 4 Apr 2011 12:15:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301944507; bh=zX+HfY5nZwF+BL4R+2o1sTPHb9Y=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Qzubr+xbJGgNJcWDK35JaYZk8F0BCLjZYa8/Gz+Pdyb9MJQ4nY7Mxu1E4GU3963wE y5Yn3umjc8ggk5Y9HgVow== Received: from yxe42 (yxe42.prod.google.com [10.190.2.42]) by kpbe19.cbf.corp.google.com with ESMTP id p34JF6wc026698 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 4 Apr 2011 12:15:06 -0700 Received: by yxe42 with SMTP id 42so2337009yxe.30 for ; Mon, 04 Apr 2011 12:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=+FAuZlZpNQOUYd84Twm/sbNtZiSMG9h6zoMuCUIOfU4=; b=GrBjPSRxHJoktTV/WRLPUIJoD51+URZ/qZaf1y33hEoxee/Fq8ZFJSFgxsIjc5w/QI B6Jb91UtPXvka2JyLjJA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Dczr2blbWJU2y+QZ1LcKYI5rzzaYzVjcX61UE0X2QGkvy8pTt1uFf2jEfgYafpp/Bq TLjflyY5st/yaxFd9ejw== Received: by 10.101.15.7 with SMTP id s7mr5531860ani.16.1301944506074; Mon, 04 Apr 2011 12:15:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.34.4 with HTTP; Mon, 4 Apr 2011 12:14:46 -0700 (PDT) In-Reply-To: <66F1ABA3-4A1E-4B18-94D4-A431FA9DE126@gmail.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <9E68D140-ED3D-4C62-A6A1-5CE1CDB5C5D9@oracle.com> <2597C1CF-1067-404A-BFE3-DE8F55A77EA6@kiva.org> <66F1ABA3-4A1E-4B18-94D4-A431FA9DE126@gmail.com> From: Marius Scurtescu Date: Mon, 4 Apr 2011 12:14:46 -0700 Message-ID: To: Kris Selden Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:13:26 -0000 On Mon, Apr 4, 2011 at 12:09 PM, Kris Selden wrote: > I completely agree with you regarding not being able to authenticate a na= tive client. > > The problem with web flow is the user experience is bad for a native app.= =A0Why does this matter? =A0Because of competition =96 if competitors use = a user friendly but less secure method and the end user does not know it is= bad for them, then because of market forces you have to do the same. User experience should be identical for both User-Agent and Web Server flows. With User-Agent typically you get only a short lived access token, so for more cases this will not work at all for native apps. Marius From skylar@kiva.org Mon Apr 4 12:26:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25453A659C for ; Mon, 4 Apr 2011 12:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxAxYZoJ5OcK for ; Mon, 4 Apr 2011 12:26:55 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by core3.amsl.com (Postfix) with SMTP id 6AD8E3A6452 for ; Mon, 4 Apr 2011 12:26:54 -0700 (PDT) Received: from source ([209.85.160.177]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKTZob5A3tIo6q5cH2h0OvTvceKawyRw3Z@postini.com; Mon, 04 Apr 2011 12:28:37 PDT Received: by gyh20 with SMTP id 20so2493127gyh.36 for ; Mon, 04 Apr 2011 12:28:36 -0700 (PDT) Received: by 10.90.182.15 with SMTP id e15mr7897841agf.54.1301945316041; Mon, 04 Apr 2011 12:28:36 -0700 (PDT) Received: from [192.168.2.8] (74-128-24-154.dhcp.insightbb.com [74.128.24.154]) by mx.google.com with ESMTPS id 6sm5675501anx.46.2011.04.04.12.28.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 12:28:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Mon, 4 Apr 2011 15:28:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1084) Cc: Oleg Gryb , OAuth WG , Prateek Mishra Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:26:57 -0000 But mobile clients aren't vulnerable to this type of attack because all = of their code is contained on the device and they make all outgoing = requests to the provider via SSL. There are no redirects to insecure = remote endpoints. A mobile device incapable of making outgoing SSL = requests would not be able to run an OAuth-compliant client as the spec = is currently written. Where in this example is the un-encrypted exchange you are trying to = protect? On Apr 4, 2011, at 3:12 PM, Phil Hunt wrote: > I was referring to a mobile client that passes the request via an = external browser. That browser is capable of running SSL with server = authentication only. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-04-04, at 12:08 PM, Skylar Woodward wrote: >=20 >> Maybe you can explain your example in more detail then? I'm assuming = your "client app" is a web application hosted on web server supporting = only HTTP. >>=20 >> How does the nonce or request_id get to the provider as part of the = authorization request in your example? (step 1) >>=20 >>=20 >> On Apr 4, 2011, at 3:03 PM, Phillip Hunt wrote: >>=20 >>> It doesn't require client side ssl.=20 >>>=20 >>> Phil >>>=20 >>> Sent from my phone.=20 >>>=20 >>> On 2011-04-04, at 11:47, Skylar Woodward wrote: >>>=20 >>>> How does the client app transmit the nonce (random number) to the = web browser for redirect to the provider? If the client app does not = support HTTPS, it can't set up a secure session on its own to give the = browser/user something to pass on during the provider authorization. >>>>=20 >>>> To me, this is nothing different that a unique value of "state" = which robust clients will already use to differentiate request flows. = Such a state variable would be exposed both on its way and back of the = provider's redirect. >>>>=20 >>>>=20 >>>> In any case, I see HTTPS as the simple solution here. I question if = it is in the scope of OAuth to provide a mechanism to the community to = protect against such MITM attacks between a hosted web application and = the web browser. If the nature of the data requires such protection, = the app developer (or the provider) can work to provide such security = outside of HTTPS. In the right context, tunneling customer traffic = through a provider-provided VPN could be considered a reasonable = protection for the cases folks have outlined. It just doesn't seem like = a popular need at this point, and there seem to be no easy wins for = hosted clients unable to register with a certificate authority. >>>>=20 >>>>=20 >>>>=20 >>>> On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote: >>>>=20 >>>>> I have been wondering if we can combine a couple of things such as = a client generated transaction secret and use limited TLS to achieve a = fix. Note: this would address a hacker sniffing a returned = authorization code, but it probably does little for the MITM scenario = that was also outlined. >>>>>=20 >>>>> 1. The client app generate a random number or sequence of = characters, lets call it "request_id", then that value would be included = and securely (using TLS) transmitted in the authorization request. >>>>> 2. The authorization server does its usual thing and returns, = preferably securely but not necessarily, the authorization code to the = client app. >>>>> 3. Upon requesting an access_token, the client app also includes = the same request_id in its secure request to the token endpoint. >>>>> 4. The token server verifies that the "request_id" matches the = request_id supplied in the authorize request (in addition to all the = other processing). >>>>>=20 >>>>> Since both requests are sent securely a sniffing client cannot = obtain the client request_id even though it might be able to obtain the = authorization code being returned. >>>>>=20 >>>>> What this might allow is that the client can transmit a secret = protected by TLS in its outbound request, but can accept non-secure = delivery of the authorization code. The token server then has a means = to verify that the client exchanging the authorization code is the same = one that made the initial request. >>>>>=20 >>>>> This is off the top of my head, I am sure the proposal is likely = not yet a complete solution, but maybe someone can build on that. >>>>>=20 >>>>> Phil >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2011-04-04, at 10:52 AM, Oleg Gryb wrote: >>>>>=20 >>>>>> After looking into exiting (and working) implementations of OAuth = 1.0 in mobile world I have strong doubts about possibility of = implementing what was suggested in option #3.=20 >>>>>>=20 >>>>>> In my view, two conditions are needed to achieve that: >>>>>>=20 >>>>>> 1. Something unique stored on a mobile client. >>>>>> 2. That something should be a secret, so other (malicious) = clients could not reuse it. >>>>>>=20 >>>>>> Distribution of that "unique secrets" should be automated in the = mobile world and is usually included to mobile application=20 >>>>>> activation process, but that activation process can't make = conditions 1 & 2 above met in full, becuase: >>>>>>=20 >>>>>> 1. As soon as secrets are distributed to a mobile device they are = not quite secret any more >>>>>> 2. As soon as the secret becomes known, a simulator or other = mobile device can be used to spoof the traffic >>>>>>=20 >>>>>> I would consider option #3 as an illusion until somebody comes up = with a solution that would address the described issues. >>>>>>=20 >>>>>> BTW, the draft of "OAuth Dynamic Client Registration Protocol" = (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on = Feb. 12 and I didn't see any attempts to re-vitalise it. I think it = would be better and more beneficial for the community to return to this = protocol rather than inventing a new method of "mutual authentication".=20= >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From: Phil Hunt >>>>>> To: Prateek Mishra >>>>>> Cc: OAuth WG >>>>>> Sent: Mon, April 4, 2011 9:52:17 AM >>>>>> Subject: Re: [OAUTH-WG] Authorization code security issue = (reframed) >>>>>>=20 >>>>>> Apologies for the long message (again). I have attempted to sum = things up and bring out the issue without using any existing service or = party as an example of problems. It seems some have taken offence to my = previous message pushing for a solution. As a result it was not = productive. I apologize. Hopefully this message sticks to the issue of = developing an appropriate counter measure to threats as that is my only = intent. >>>>>>=20 >>>>>> As Prateek clarified in the previous message to Francisco, SAML = also uses SHOULD, but artifact security is achieved by an additional = counter-measure... >>>>>>> The identity provider MUST ensure that only the service provider = to whom the message has >>>>>>> been issued is given the message as the result of an = request. >>>>>>=20 >>>>>> Yet, in OAuth the client app is not unique for a particular set = of client credentials we currently have no way to verify that the = correct client got the code. This has been the mechanism that the = community has been assuming solves the problem. Client credentials do = not always work to protect the authorization code because in OAuth you = can have many many clients with the same credential. For example = everyone with the same mobile app likely has the same client credential. = Thus a copy of a valid client app which is easy to obtain becomes the = hacker's attack vector. So, the client credential is not an effective = counter in this case. >>>>>>=20 >>>>>> Several have commented that there are other supplementary = techniques for protection, but in my view, most of them work indirectly = and/or depend on correct collective configuration of several components. = Some of these are: tokens may be used one time; tokens are invalidated = if used a second time, tokens are sufficiently unique, etc. All of = these will help. But none are designed to directly counter the attack. = In fact the best one - token invalidation carries the additional problem = of unreliable service for the legitimate client. The hacker can deny = service to anyone in the room simply by re-using any tokens seen. >>>>>>=20 >>>>>> =46rom my perspective, the "easy" solution was to increase the = requirements on TLS from SHOULD to MUST to prevent eavesdropping of the = code. This was echoed by several others. I agree this will not work for = everyone. Many have made strong arguments for why they can't use it. But = without a MUST we are still missing a direct counter to the threat. >>>>>>=20 >>>>>> I don't want to change things at this late date, but maybe this = means introducing some form of mutual authentication -- some way for the = requesting client "instance" to prove that they are the copy eligible to = use an authorization code.=20 >>>>>>=20 >>>>>> To end this discussion, I propose we vote on the proposal from = Eran plus one new option... >>>>>> 1. Include a normative MUST use TLS for the client redirection = URI endpoint. >>>>>> 2. Include a normative SHOULD use TLS for the client redirection = URI endpoint with strong language explaining the various attacks = possible if the endpoint is not made secure. >>>>>> 3. Keep current language of SHOULD, but develop a direct = counter-measure to token theft such as specific client instance = identification or mutual authentication. >>>>>>=20 >>>>>> Phil >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: >>>>>>=20 >>>>>>> Francisco, >>>>>>>=20 >>>>>>> You are right, I was in error to suggest that it was a MUST. >>>>>>>=20 >>>>>>> I think my main concern was that security considerations should = not be based on polling developers/deployers of an existing or legacy = protocol. >>>>>>>=20 >>>>>>> SAML does include some additional countermeasures though - for = example (lines 595-596, profiles document) - that specifically deal with = the >>>>>>> artifact being leaked -=20 >>>>>>>=20 >>>>>>> [quote] >>>>>>> The identity provider MUST ensure that only the service provider = to whom the message has >>>>>>> been issued is given the message as the result of an = request. >>>>>>> [\quote] >>>>>>>=20 >>>>>>> - prateek >>>>>>>> Hi Prateek, >>>>>>>>=20 >>>>>>>>> I would like to strongly disagree with this proposal. >>>>>>>>>=20 >>>>>>>>> It amounts to explicitly making OAuth 2.0 insecure so as to >>>>>>>>> satisfy some mysterious and unspecified set of legacy OAuth >>>>>>>>> 1.0 deployments. >>>>>>>>>=20 >>>>>>>>> The SAML web SSO (artifact) profile - which shares many >>>>>>>>> characteristics with the initial steps in OAuth - requires >>>>>>>>> precisely such a counter-measure and is widely implemented >>>>>>>>> in 1000s of deployments. >>>>>>>>=20 >>>>>>>> What counter-measure is this? Can you provide a reference? >>>>>>>> Section 4.1.3.5 of=20 >>>>>>>> = http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>>>>>>> recommends TLS but does not require it. >>>>>>>>=20 >>>>>>>> Francisco >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From phil.hunt@oracle.com Mon Apr 4 12:27:15 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1413A6768 for ; Mon, 4 Apr 2011 12:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zosSLZdBPJ-L for ; Mon, 4 Apr 2011 12:27:14 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 292C13A6452 for ; Mon, 4 Apr 2011 12:27:14 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p34JSsFO031815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 19:28:55 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p34JSr6I016602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2011 19:28:53 GMT Received: from abhmt020.oracle.com (abhmt020.oracle.com [141.146.116.29]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p34JSqrD018880; Mon, 4 Apr 2011 14:28:53 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 12:28:52 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Phil Hunt In-Reply-To: Date: Mon, 4 Apr 2011 12:28:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <847C4918-B6B6-4A17-8567-E7486A1F0643@oracle.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <9E68D140-ED3D-4C62-A6A1-5CE1CDB5C5D9@oracle.com> <2597C1CF-1067-404A-BFE3-DE8F55A77EA6@kiva.org> <66F1ABA3-4A1E-4B18-94D4-A431FA9DE126@gmail.com> To: Marius Scurtescu X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4D9A1BF5.014E:SCFSTAT5015188,ss=1,fgs=0 Cc: Kris Selden , oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:27:15 -0000 Marius/Kris, Are we talking about Native apps where no browser (internal or external) = is available (e.g. set-top-box)? If a browser is available, I would not want to confuse the user with = authentication at the service provider with local branding of the app. = OAuth does a nice job of keeping these separate as we've already seen in = the OAuth 1 implementations. Per what Marius is saying, the user = experience [for a particular resource provider] should be the same = regardless of user-agent or web server. If a browser is not available, I've seen out-of-band methods work very = well too. E.g. code via SMS, code via email.=20 The issue that client credentials on installed apps aren't very good is = becoming well known (see the other threads on authorization code = security). Even if well protected (which is debatable), the problem is = there are many many clients with the same legit code. We need something = that so that a server can determine it is accepting an access token = request from the same client that originally requested an authorization. There is also a follow on problem that without a unique client app (per = instance) identifier, you can't easily revoke access to that client = without impacting every other client with the same identifier. Phil phil.hunt@oracle.com On 2011-04-04, at 12:14 PM, Marius Scurtescu wrote: > On Mon, Apr 4, 2011 at 12:09 PM, Kris Selden = wrote: >> I completely agree with you regarding not being able to authenticate = a native client. >>=20 >> The problem with web flow is the user experience is bad for a native = app. Why does this matter? Because of competition =96 if competitors = use a user friendly but less secure method and the end user does not = know it is bad for them, then because of market forces you have to do = the same. >=20 > User experience should be identical for both User-Agent and Web Server > flows. With User-Agent typically you get only a short lived access > token, so for more cases this will not work at all for native apps. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From zachary.zeltsan@alcatel-lucent.com Mon Apr 4 12:37:02 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77C43A67A3 for ; Mon, 4 Apr 2011 12:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71eFV1eiKDKC for ; Mon, 4 Apr 2011 12:37:02 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id E33D53A67A2 for ; Mon, 4 Apr 2011 12:37:01 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p34Jcf1Y005545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 14:38:42 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p34JcfIe009425 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Apr 2011 14:38:41 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 4 Apr 2011 14:38:41 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Marius Scurtescu'" , Kris Selden Date: Mon, 4 Apr 2011 14:38:40 -0500 Thread-Topic: [OAUTH-WG] Flowchart for legs of OAuth Thread-Index: Acvy9l3T5/MVZLLMRLCrJlQl/NMdnQAAl8Zw Message-ID: <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:37:02 -0000 According to section "6 Refreshing an Access Token" (-13.txt), client when = making a request for exchanging a refresh token for an access token has to = include its authentication credentials, and the "authorization server MUST = validate the client credentials".=20 How can this be done if a client is an application that can't have a client= secret?=20 The authorization code grant does require client authentication (per sectio= n 4.1): (D) The client requests an access token from the authorization server's token endpoint by authenticating using its client credentials, and includes the authorization code received in the previous step. It appears that the clients that cannot keep its secret cannot use (be issu= ed) the refresh tokens. Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= arius Scurtescu Sent: Monday, April 04, 2011 2:30 PM To: Kris Selden Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wrote: > A typical iPhone app cannot be shipped with a client secret and rightly o= r wrongly users expect to only have to enter their credentials once. > > What is the best profile to use for an app that can't have a client secre= t and needs a refresh token or a long lived access token? The authorization code grant, aka web server flow. The spec is misleading in this respect IMO. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Mon Apr 4 12:37:22 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518233A67B1 for ; Mon, 4 Apr 2011 12:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5m2xG5qBN1iX for ; Mon, 4 Apr 2011 12:37:20 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 37B423A67A2 for ; Mon, 4 Apr 2011 12:37:20 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p34JcwGK024654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 19:39:00 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p34JcvDR020764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2011 19:38:58 GMT Received: from abhmt007.oracle.com (abhmt007.oracle.com [141.146.116.16]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p34JcvE7017874; Mon, 4 Apr 2011 14:38:57 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 12:38:56 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Mon, 4 Apr 2011 12:38:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> To: Skylar Woodward X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4D9A1E52.00D3:SCFSTAT5015188,ss=1,fgs=0 Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:37:22 -0000 If you run a scanner, you will see that many of the current draft = implementations pass the authorization code by redirect without SSL. = I've seen several implementations where the authorization code is easy = to scan. I suspect this occurs because the HTTP response isn't directly in = response to the original outgoing authorization. When I run the scanner, = the resource provider is performing a workflow with the user that = accomplishes form based authentication and authorization with the user, = some of which is not on SSL. What happens is the redirect is then not = sent by SSL. It seems like only a natural consequence of typical = authentication/authorization workflows. Or at best, it is difficult the = guarantee that the authorization code will always be returned in a = secure TLS channel. Several people stated that the redirect end-point cannot implement = server-side security (called local redirect) and I think their request = is reasonable as it would require each client to have its own server = certificate. That *might* be acceptable to most web apps, but likely = won't work for apps with many many copies like mobile apps. So, I'm making the assumption that if we can minimally count on outbound = TLS security, the transaction id would suffice to allow the token = service to connect the originating authorization client with the client = requesting an access token. Phil phil.hunt@oracle.com On 2011-04-04, at 12:28 PM, Skylar Woodward wrote: > But mobile clients aren't vulnerable to this type of attack because = all of their code is contained on the device and they make all outgoing = requests to the provider via SSL. There are no redirects to insecure = remote endpoints. A mobile device incapable of making outgoing SSL = requests would not be able to run an OAuth-compliant client as the spec = is currently written. >=20 > Where in this example is the un-encrypted exchange you are trying to = protect? >=20 >=20 > On Apr 4, 2011, at 3:12 PM, Phil Hunt wrote: >=20 >> I was referring to a mobile client that passes the request via an = external browser. That browser is capable of running SSL with server = authentication only. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-04-04, at 12:08 PM, Skylar Woodward wrote: >>=20 >>> Maybe you can explain your example in more detail then? I'm assuming = your "client app" is a web application hosted on web server supporting = only HTTP. >>>=20 >>> How does the nonce or request_id get to the provider as part of the = authorization request in your example? (step 1) >>>=20 >>>=20 >>> On Apr 4, 2011, at 3:03 PM, Phillip Hunt wrote: >>>=20 >>>> It doesn't require client side ssl.=20 >>>>=20 >>>> Phil >>>>=20 >>>> Sent from my phone.=20 >>>>=20 >>>> On 2011-04-04, at 11:47, Skylar Woodward wrote: >>>>=20 >>>>> How does the client app transmit the nonce (random number) to the = web browser for redirect to the provider? If the client app does not = support HTTPS, it can't set up a secure session on its own to give the = browser/user something to pass on during the provider authorization. >>>>>=20 >>>>> To me, this is nothing different that a unique value of "state" = which robust clients will already use to differentiate request flows. = Such a state variable would be exposed both on its way and back of the = provider's redirect. >>>>>=20 >>>>>=20 >>>>> In any case, I see HTTPS as the simple solution here. I question = if it is in the scope of OAuth to provide a mechanism to the community = to protect against such MITM attacks between a hosted web application = and the web browser. If the nature of the data requires such = protection, the app developer (or the provider) can work to provide such = security outside of HTTPS. In the right context, tunneling customer = traffic through a provider-provided VPN could be considered a reasonable = protection for the cases folks have outlined. It just doesn't seem like = a popular need at this point, and there seem to be no easy wins for = hosted clients unable to register with a certificate authority. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote: >>>>>=20 >>>>>> I have been wondering if we can combine a couple of things such = as a client generated transaction secret and use limited TLS to achieve = a fix. Note: this would address a hacker sniffing a returned = authorization code, but it probably does little for the MITM scenario = that was also outlined. >>>>>>=20 >>>>>> 1. The client app generate a random number or sequence of = characters, lets call it "request_id", then that value would be included = and securely (using TLS) transmitted in the authorization request. >>>>>> 2. The authorization server does its usual thing and returns, = preferably securely but not necessarily, the authorization code to the = client app. >>>>>> 3. Upon requesting an access_token, the client app also includes = the same request_id in its secure request to the token endpoint. >>>>>> 4. The token server verifies that the "request_id" matches the = request_id supplied in the authorize request (in addition to all the = other processing). >>>>>>=20 >>>>>> Since both requests are sent securely a sniffing client cannot = obtain the client request_id even though it might be able to obtain the = authorization code being returned. >>>>>>=20 >>>>>> What this might allow is that the client can transmit a secret = protected by TLS in its outbound request, but can accept non-secure = delivery of the authorization code. The token server then has a means = to verify that the client exchanging the authorization code is the same = one that made the initial request. >>>>>>=20 >>>>>> This is off the top of my head, I am sure the proposal is likely = not yet a complete solution, but maybe someone can build on that. >>>>>>=20 >>>>>> Phil >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2011-04-04, at 10:52 AM, Oleg Gryb wrote: >>>>>>=20 >>>>>>> After looking into exiting (and working) implementations of = OAuth 1.0 in mobile world I have strong doubts about possibility of = implementing what was suggested in option #3.=20 >>>>>>>=20 >>>>>>> In my view, two conditions are needed to achieve that: >>>>>>>=20 >>>>>>> 1. Something unique stored on a mobile client. >>>>>>> 2. That something should be a secret, so other (malicious) = clients could not reuse it. >>>>>>>=20 >>>>>>> Distribution of that "unique secrets" should be automated in the = mobile world and is usually included to mobile application=20 >>>>>>> activation process, but that activation process can't make = conditions 1 & 2 above met in full, becuase: >>>>>>>=20 >>>>>>> 1. As soon as secrets are distributed to a mobile device they = are not quite secret any more >>>>>>> 2. As soon as the secret becomes known, a simulator or other = mobile device can be used to spoof the traffic >>>>>>>=20 >>>>>>> I would consider option #3 as an illusion until somebody comes = up with a solution that would address the described issues. >>>>>>>=20 >>>>>>> BTW, the draft of "OAuth Dynamic Client Registration Protocol" = (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on = Feb. 12 and I didn't see any attempts to re-vitalise it. I think it = would be better and more beneficial for the community to return to this = protocol rather than inventing a new method of "mutual authentication".=20= >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> From: Phil Hunt >>>>>>> To: Prateek Mishra >>>>>>> Cc: OAuth WG >>>>>>> Sent: Mon, April 4, 2011 9:52:17 AM >>>>>>> Subject: Re: [OAUTH-WG] Authorization code security issue = (reframed) >>>>>>>=20 >>>>>>> Apologies for the long message (again). I have attempted to sum = things up and bring out the issue without using any existing service or = party as an example of problems. It seems some have taken offence to my = previous message pushing for a solution. As a result it was not = productive. I apologize. Hopefully this message sticks to the issue of = developing an appropriate counter measure to threats as that is my only = intent. >>>>>>>=20 >>>>>>> As Prateek clarified in the previous message to Francisco, SAML = also uses SHOULD, but artifact security is achieved by an additional = counter-measure... >>>>>>>> The identity provider MUST ensure that only the service = provider to whom the message has >>>>>>>> been issued is given the message as the result of an = request. >>>>>>>=20 >>>>>>> Yet, in OAuth the client app is not unique for a particular set = of client credentials we currently have no way to verify that the = correct client got the code. This has been the mechanism that the = community has been assuming solves the problem. Client credentials do = not always work to protect the authorization code because in OAuth you = can have many many clients with the same credential. For example = everyone with the same mobile app likely has the same client credential. = Thus a copy of a valid client app which is easy to obtain becomes the = hacker's attack vector. So, the client credential is not an effective = counter in this case. >>>>>>>=20 >>>>>>> Several have commented that there are other supplementary = techniques for protection, but in my view, most of them work indirectly = and/or depend on correct collective configuration of several components. = Some of these are: tokens may be used one time; tokens are invalidated = if used a second time, tokens are sufficiently unique, etc. All of = these will help. But none are designed to directly counter the attack. = In fact the best one - token invalidation carries the additional problem = of unreliable service for the legitimate client. The hacker can deny = service to anyone in the room simply by re-using any tokens seen. >>>>>>>=20 >>>>>>> =46rom my perspective, the "easy" solution was to increase the = requirements on TLS from SHOULD to MUST to prevent eavesdropping of the = code. This was echoed by several others. I agree this will not work for = everyone. Many have made strong arguments for why they can't use it. But = without a MUST we are still missing a direct counter to the threat. >>>>>>>=20 >>>>>>> I don't want to change things at this late date, but maybe this = means introducing some form of mutual authentication -- some way for the = requesting client "instance" to prove that they are the copy eligible to = use an authorization code.=20 >>>>>>>=20 >>>>>>> To end this discussion, I propose we vote on the proposal from = Eran plus one new option... >>>>>>> 1. Include a normative MUST use TLS for the client redirection = URI endpoint. >>>>>>> 2. Include a normative SHOULD use TLS for the client redirection = URI endpoint with strong language explaining the various attacks = possible if the endpoint is not made secure. >>>>>>> 3. Keep current language of SHOULD, but develop a direct = counter-measure to token theft such as specific client instance = identification or mutual authentication. >>>>>>>=20 >>>>>>> Phil >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: >>>>>>>=20 >>>>>>>> Francisco, >>>>>>>>=20 >>>>>>>> You are right, I was in error to suggest that it was a MUST. >>>>>>>>=20 >>>>>>>> I think my main concern was that security considerations should = not be based on polling developers/deployers of an existing or legacy = protocol. >>>>>>>>=20 >>>>>>>> SAML does include some additional countermeasures though - for = example (lines 595-596, profiles document) - that specifically deal with = the >>>>>>>> artifact being leaked -=20 >>>>>>>>=20 >>>>>>>> [quote] >>>>>>>> The identity provider MUST ensure that only the service = provider to whom the message has >>>>>>>> been issued is given the message as the result of an = request. >>>>>>>> [\quote] >>>>>>>>=20 >>>>>>>> - prateek >>>>>>>>> Hi Prateek, >>>>>>>>>=20 >>>>>>>>>> I would like to strongly disagree with this proposal. >>>>>>>>>>=20 >>>>>>>>>> It amounts to explicitly making OAuth 2.0 insecure so as to >>>>>>>>>> satisfy some mysterious and unspecified set of legacy OAuth >>>>>>>>>> 1.0 deployments. >>>>>>>>>>=20 >>>>>>>>>> The SAML web SSO (artifact) profile - which shares many >>>>>>>>>> characteristics with the initial steps in OAuth - requires >>>>>>>>>> precisely such a counter-measure and is widely implemented >>>>>>>>>> in 1000s of deployments. >>>>>>>>>=20 >>>>>>>>> What counter-measure is this? Can you provide a reference? >>>>>>>>> Section 4.1.3.5 of=20 >>>>>>>>> = http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>>>>>>>> recommends TLS but does not require it. >>>>>>>>>=20 >>>>>>>>> Francisco >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From skylar@kiva.org Mon Apr 4 12:51:25 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8FD3A67A8 for ; Mon, 4 Apr 2011 12:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0jxgKnG9-eO for ; Mon, 4 Apr 2011 12:51:23 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by core3.amsl.com (Postfix) with SMTP id D4E393A6768 for ; Mon, 4 Apr 2011 12:51:22 -0700 (PDT) Received: from source ([209.85.213.173]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKTZohoTVTzoVQng/nrcyZZz3TFJlOy6EQ@postini.com; Mon, 04 Apr 2011 12:53:05 PDT Received: by yxk8 with SMTP id 8so2842142yxk.4 for ; Mon, 04 Apr 2011 12:53:04 -0700 (PDT) Received: by 10.151.85.6 with SMTP id n6mr8047263ybl.196.1301946784406; Mon, 04 Apr 2011 12:53:04 -0700 (PDT) Received: from [192.168.2.8] (74-128-24-154.dhcp.insightbb.com [74.128.24.154]) by mx.google.com with ESMTPS id q29sm2316427ybk.25.2011.04.04.12.53.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 12:53:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Mon, 4 Apr 2011 15:52:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2BDF838F-C5CE-43C3-B017-91D967ECDAC0@kiva.org> References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1084) Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:51:25 -0000 I'm confused - it seems like you're mixing web clients and native = clients in this most recent explanation. It's perfectly reasonable that = the authorization code will always be returned by a provider in a secure = TLS channel to the web browser or native client which started the = authorization request. What's not reasonable is, in the case of the = code returned to a web browser (acting on behalf of a web client), for = the browser to then pass the code on to the web client over TLS. Maybe you can elaborate the attack you are considering by listing each = network request/response between the mobile client and any servers? I'll repeat again that the attack I've seen described thus far doesn't = apply to mobile apps with( or without) many copies because there is no = local redirect involved. (The redirect URI is merely an identifier that = says "here's the code!" - it need not be a network location, and if it = is, it's just a local location on the same device - eg, another app = running on the same device). skylar On Apr 4, 2011, at 3:38 PM, Phil Hunt wrote: > If you run a scanner, you will see that many of the current draft = implementations pass the authorization code by redirect without SSL. = I've seen several implementations where the authorization code is easy = to scan. >=20 > I suspect this occurs because the HTTP response isn't directly in = response to the original outgoing authorization. When I run the scanner, = the resource provider is performing a workflow with the user that = accomplishes form based authentication and authorization with the user, = some of which is not on SSL. What happens is the redirect is then not = sent by SSL. It seems like only a natural consequence of typical = authentication/authorization workflows. Or at best, it is difficult the = guarantee that the authorization code will always be returned in a = secure TLS channel. >=20 > Several people stated that the redirect end-point cannot implement = server-side security (called local redirect) and I think their request = is reasonable as it would require each client to have its own server = certificate. That *might* be acceptable to most web apps, but likely = won't work for apps with many many copies like mobile apps. >=20 > So, I'm making the assumption that if we can minimally count on = outbound TLS security, the transaction id would suffice to allow the = token service to connect the originating authorization client with the = client requesting an access token. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-04-04, at 12:28 PM, Skylar Woodward wrote: >=20 >> But mobile clients aren't vulnerable to this type of attack because = all of their code is contained on the device and they make all outgoing = requests to the provider via SSL. There are no redirects to insecure = remote endpoints. A mobile device incapable of making outgoing SSL = requests would not be able to run an OAuth-compliant client as the spec = is currently written. >>=20 >> Where in this example is the un-encrypted exchange you are trying to = protect? >>=20 >>=20 >> On Apr 4, 2011, at 3:12 PM, Phil Hunt wrote: >>=20 >>> I was referring to a mobile client that passes the request via an = external browser. That browser is capable of running SSL with server = authentication only. >>>=20 >>> Phil >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2011-04-04, at 12:08 PM, Skylar Woodward wrote: >>>=20 >>>> Maybe you can explain your example in more detail then? I'm = assuming your "client app" is a web application hosted on web server = supporting only HTTP. >>>>=20 >>>> How does the nonce or request_id get to the provider as part of the = authorization request in your example? (step 1) >>>>=20 >>>>=20 >>>> On Apr 4, 2011, at 3:03 PM, Phillip Hunt wrote: >>>>=20 >>>>> It doesn't require client side ssl.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> Sent from my phone.=20 >>>>>=20 >>>>> On 2011-04-04, at 11:47, Skylar Woodward wrote: >>>>>=20 >>>>>> How does the client app transmit the nonce (random number) to the = web browser for redirect to the provider? If the client app does not = support HTTPS, it can't set up a secure session on its own to give the = browser/user something to pass on during the provider authorization. >>>>>>=20 >>>>>> To me, this is nothing different that a unique value of "state" = which robust clients will already use to differentiate request flows. = Such a state variable would be exposed both on its way and back of the = provider's redirect. >>>>>>=20 >>>>>>=20 >>>>>> In any case, I see HTTPS as the simple solution here. I question = if it is in the scope of OAuth to provide a mechanism to the community = to protect against such MITM attacks between a hosted web application = and the web browser. If the nature of the data requires such = protection, the app developer (or the provider) can work to provide such = security outside of HTTPS. In the right context, tunneling customer = traffic through a provider-provided VPN could be considered a reasonable = protection for the cases folks have outlined. It just doesn't seem like = a popular need at this point, and there seem to be no easy wins for = hosted clients unable to register with a certificate authority. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote: >>>>>>=20 >>>>>>> I have been wondering if we can combine a couple of things such = as a client generated transaction secret and use limited TLS to achieve = a fix. Note: this would address a hacker sniffing a returned = authorization code, but it probably does little for the MITM scenario = that was also outlined. >>>>>>>=20 >>>>>>> 1. The client app generate a random number or sequence of = characters, lets call it "request_id", then that value would be included = and securely (using TLS) transmitted in the authorization request. >>>>>>> 2. The authorization server does its usual thing and returns, = preferably securely but not necessarily, the authorization code to the = client app. >>>>>>> 3. Upon requesting an access_token, the client app also includes = the same request_id in its secure request to the token endpoint. >>>>>>> 4. The token server verifies that the "request_id" matches the = request_id supplied in the authorize request (in addition to all the = other processing). >>>>>>>=20 >>>>>>> Since both requests are sent securely a sniffing client cannot = obtain the client request_id even though it might be able to obtain the = authorization code being returned. >>>>>>>=20 >>>>>>> What this might allow is that the client can transmit a secret = protected by TLS in its outbound request, but can accept non-secure = delivery of the authorization code. The token server then has a means = to verify that the client exchanging the authorization code is the same = one that made the initial request. >>>>>>>=20 >>>>>>> This is off the top of my head, I am sure the proposal is likely = not yet a complete solution, but maybe someone can build on that. >>>>>>>=20 >>>>>>> Phil >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2011-04-04, at 10:52 AM, Oleg Gryb wrote: >>>>>>>=20 >>>>>>>> After looking into exiting (and working) implementations of = OAuth 1.0 in mobile world I have strong doubts about possibility of = implementing what was suggested in option #3.=20 >>>>>>>>=20 >>>>>>>> In my view, two conditions are needed to achieve that: >>>>>>>>=20 >>>>>>>> 1. Something unique stored on a mobile client. >>>>>>>> 2. That something should be a secret, so other (malicious) = clients could not reuse it. >>>>>>>>=20 >>>>>>>> Distribution of that "unique secrets" should be automated in = the mobile world and is usually included to mobile application=20 >>>>>>>> activation process, but that activation process can't make = conditions 1 & 2 above met in full, becuase: >>>>>>>>=20 >>>>>>>> 1. As soon as secrets are distributed to a mobile device they = are not quite secret any more >>>>>>>> 2. As soon as the secret becomes known, a simulator or other = mobile device can be used to spoof the traffic >>>>>>>>=20 >>>>>>>> I would consider option #3 as an illusion until somebody comes = up with a solution that would address the described issues. >>>>>>>>=20 >>>>>>>> BTW, the draft of "OAuth Dynamic Client Registration Protocol" = (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on = Feb. 12 and I didn't see any attempts to re-vitalise it. I think it = would be better and more beneficial for the community to return to this = protocol rather than inventing a new method of "mutual authentication".=20= >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> From: Phil Hunt >>>>>>>> To: Prateek Mishra >>>>>>>> Cc: OAuth WG >>>>>>>> Sent: Mon, April 4, 2011 9:52:17 AM >>>>>>>> Subject: Re: [OAUTH-WG] Authorization code security issue = (reframed) >>>>>>>>=20 >>>>>>>> Apologies for the long message (again). I have attempted to sum = things up and bring out the issue without using any existing service or = party as an example of problems. It seems some have taken offence to my = previous message pushing for a solution. As a result it was not = productive. I apologize. Hopefully this message sticks to the issue of = developing an appropriate counter measure to threats as that is my only = intent. >>>>>>>>=20 >>>>>>>> As Prateek clarified in the previous message to Francisco, SAML = also uses SHOULD, but artifact security is achieved by an additional = counter-measure... >>>>>>>>> The identity provider MUST ensure that only the service = provider to whom the message has >>>>>>>>> been issued is given the message as the result of an = request. >>>>>>>>=20 >>>>>>>> Yet, in OAuth the client app is not unique for a particular set = of client credentials we currently have no way to verify that the = correct client got the code. This has been the mechanism that the = community has been assuming solves the problem. Client credentials do = not always work to protect the authorization code because in OAuth you = can have many many clients with the same credential. For example = everyone with the same mobile app likely has the same client credential. = Thus a copy of a valid client app which is easy to obtain becomes the = hacker's attack vector. So, the client credential is not an effective = counter in this case. >>>>>>>>=20 >>>>>>>> Several have commented that there are other supplementary = techniques for protection, but in my view, most of them work indirectly = and/or depend on correct collective configuration of several components. = Some of these are: tokens may be used one time; tokens are invalidated = if used a second time, tokens are sufficiently unique, etc. All of = these will help. But none are designed to directly counter the attack. = In fact the best one - token invalidation carries the additional problem = of unreliable service for the legitimate client. The hacker can deny = service to anyone in the room simply by re-using any tokens seen. >>>>>>>>=20 >>>>>>>> =46rom my perspective, the "easy" solution was to increase the = requirements on TLS from SHOULD to MUST to prevent eavesdropping of the = code. This was echoed by several others. I agree this will not work for = everyone. Many have made strong arguments for why they can't use it. But = without a MUST we are still missing a direct counter to the threat. >>>>>>>>=20 >>>>>>>> I don't want to change things at this late date, but maybe this = means introducing some form of mutual authentication -- some way for the = requesting client "instance" to prove that they are the copy eligible to = use an authorization code.=20 >>>>>>>>=20 >>>>>>>> To end this discussion, I propose we vote on the proposal from = Eran plus one new option... >>>>>>>> 1. Include a normative MUST use TLS for the client redirection = URI endpoint. >>>>>>>> 2. Include a normative SHOULD use TLS for the client = redirection URI endpoint with strong language explaining the various = attacks possible if the endpoint is not made secure. >>>>>>>> 3. Keep current language of SHOULD, but develop a direct = counter-measure to token theft such as specific client instance = identification or mutual authentication. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: >>>>>>>>=20 >>>>>>>>> Francisco, >>>>>>>>>=20 >>>>>>>>> You are right, I was in error to suggest that it was a MUST. >>>>>>>>>=20 >>>>>>>>> I think my main concern was that security considerations = should not be based on polling developers/deployers of an existing or = legacy protocol. >>>>>>>>>=20 >>>>>>>>> SAML does include some additional countermeasures though - for = example (lines 595-596, profiles document) - that specifically deal with = the >>>>>>>>> artifact being leaked -=20 >>>>>>>>>=20 >>>>>>>>> [quote] >>>>>>>>> The identity provider MUST ensure that only the service = provider to whom the message has >>>>>>>>> been issued is given the message as the result of an = request. >>>>>>>>> [\quote] >>>>>>>>>=20 >>>>>>>>> - prateek >>>>>>>>>> Hi Prateek, >>>>>>>>>>=20 >>>>>>>>>>> I would like to strongly disagree with this proposal. >>>>>>>>>>>=20 >>>>>>>>>>> It amounts to explicitly making OAuth 2.0 insecure so as to >>>>>>>>>>> satisfy some mysterious and unspecified set of legacy OAuth >>>>>>>>>>> 1.0 deployments. >>>>>>>>>>>=20 >>>>>>>>>>> The SAML web SSO (artifact) profile - which shares many >>>>>>>>>>> characteristics with the initial steps in OAuth - requires >>>>>>>>>>> precisely such a counter-measure and is widely implemented >>>>>>>>>>> in 1000s of deployments. >>>>>>>>>>=20 >>>>>>>>>> What counter-measure is this? Can you provide a reference? >>>>>>>>>> Section 4.1.3.5 of=20 >>>>>>>>>> = http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>>>>>>>>> recommends TLS but does not require it. >>>>>>>>>>=20 >>>>>>>>>> Francisco >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 From phil.hunt@oracle.com Mon Apr 4 13:05:18 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636323A67D0 for ; Mon, 4 Apr 2011 13:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rrdn6NkOZswS for ; Mon, 4 Apr 2011 13:05:16 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 440643A67CC for ; Mon, 4 Apr 2011 13:05:16 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p34K6ua0021192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 20:06:58 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p34K6tmT029125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2011 20:06:56 GMT Received: from abhmt008.oracle.com (abhmt008.oracle.com [141.146.116.17]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p34K6tQq011245; Mon, 4 Apr 2011 15:06:55 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 13:06:54 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <2BDF838F-C5CE-43C3-B017-91D967ECDAC0@kiva.org> Date: Mon, 4 Apr 2011 13:06:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4A384831-10D3-4305-98ED-C189761E6D32@oracle.com> References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> <2BDF838F-C5CE-43C3-B017-91D967ECDAC0@kiva.org> To: Skylar Woodward X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4D9A24E0.00F1:SCFSTAT5015188,ss=1,fgs=0 Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:05:18 -0000 For the moment, I'm only talking about mobile clients. Very quickly here is the attack... 1) Paul starts dance at good Client & good AS, App requests = authorization. Note: outbound call is secure, but returned redirect is = not. 2) Evil Brian intercepts the (HTTP) redirect containing Paul's authz = code 3) Brian takes Paul's redirect #2 and enters it in his browser (e.g. by = script) 4) Brian's browser processes redirect URI from #3 and passes to Brian's = copy of client (e.g. downloaded from app store). 5) Brian's client exchanges substituted authz code for access token 6) Brian's client now accesses service using Paul's authorization As was explained earlier this attack is minimized by things like token = invalidation when the second client comes along, but we still have a = horserace and possibility of DoS for the user at minimum. The server cannot mitigate this unless it can either ensure the client = is the only one that could have received the code, or can somehow = uniquely identify the client so that a copy cannot masquerade as the = original requestor. Phil phil.hunt@oracle.com On 2011-04-04, at 12:52 PM, Skylar Woodward wrote: > I'm confused - it seems like you're mixing web clients and native = clients in this most recent explanation. It's perfectly reasonable that = the authorization code will always be returned by a provider in a secure = TLS channel to the web browser or native client which started the = authorization request. What's not reasonable is, in the case of the = code returned to a web browser (acting on behalf of a web client), for = the browser to then pass the code on to the web client over TLS. >=20 > Maybe you can elaborate the attack you are considering by listing each = network request/response between the mobile client and any servers? >=20 > I'll repeat again that the attack I've seen described thus far doesn't = apply to mobile apps with( or without) many copies because there is no = local redirect involved. (The redirect URI is merely an identifier that = says "here's the code!" - it need not be a network location, and if it = is, it's just a local location on the same device - eg, another app = running on the same device). >=20 > skylar >=20 > On Apr 4, 2011, at 3:38 PM, Phil Hunt wrote: >=20 >> If you run a scanner, you will see that many of the current draft = implementations pass the authorization code by redirect without SSL. = I've seen several implementations where the authorization code is easy = to scan. >>=20 >> I suspect this occurs because the HTTP response isn't directly in = response to the original outgoing authorization. When I run the scanner, = the resource provider is performing a workflow with the user that = accomplishes form based authentication and authorization with the user, = some of which is not on SSL. What happens is the redirect is then not = sent by SSL. It seems like only a natural consequence of typical = authentication/authorization workflows. Or at best, it is difficult the = guarantee that the authorization code will always be returned in a = secure TLS channel. >>=20 >> Several people stated that the redirect end-point cannot implement = server-side security (called local redirect) and I think their request = is reasonable as it would require each client to have its own server = certificate. That *might* be acceptable to most web apps, but likely = won't work for apps with many many copies like mobile apps. >>=20 >> So, I'm making the assumption that if we can minimally count on = outbound TLS security, the transaction id would suffice to allow the = token service to connect the originating authorization client with the = client requesting an access token. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-04-04, at 12:28 PM, Skylar Woodward wrote: >>=20 >>> But mobile clients aren't vulnerable to this type of attack because = all of their code is contained on the device and they make all outgoing = requests to the provider via SSL. There are no redirects to insecure = remote endpoints. A mobile device incapable of making outgoing SSL = requests would not be able to run an OAuth-compliant client as the spec = is currently written. >>>=20 >>> Where in this example is the un-encrypted exchange you are trying to = protect? >>>=20 >>>=20 >>> On Apr 4, 2011, at 3:12 PM, Phil Hunt wrote: >>>=20 >>>> I was referring to a mobile client that passes the request via an = external browser. That browser is capable of running SSL with server = authentication only. >>>>=20 >>>> Phil >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2011-04-04, at 12:08 PM, Skylar Woodward wrote: >>>>=20 >>>>> Maybe you can explain your example in more detail then? I'm = assuming your "client app" is a web application hosted on web server = supporting only HTTP. >>>>>=20 >>>>> How does the nonce or request_id get to the provider as part of = the authorization request in your example? (step 1) >>>>>=20 >>>>>=20 >>>>> On Apr 4, 2011, at 3:03 PM, Phillip Hunt wrote: >>>>>=20 >>>>>> It doesn't require client side ssl.=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> Sent from my phone.=20 >>>>>>=20 >>>>>> On 2011-04-04, at 11:47, Skylar Woodward wrote: >>>>>>=20 >>>>>>> How does the client app transmit the nonce (random number) to = the web browser for redirect to the provider? If the client app does not = support HTTPS, it can't set up a secure session on its own to give the = browser/user something to pass on during the provider authorization. >>>>>>>=20 >>>>>>> To me, this is nothing different that a unique value of "state" = which robust clients will already use to differentiate request flows. = Such a state variable would be exposed both on its way and back of the = provider's redirect. >>>>>>>=20 >>>>>>>=20 >>>>>>> In any case, I see HTTPS as the simple solution here. I question = if it is in the scope of OAuth to provide a mechanism to the community = to protect against such MITM attacks between a hosted web application = and the web browser. If the nature of the data requires such = protection, the app developer (or the provider) can work to provide such = security outside of HTTPS. In the right context, tunneling customer = traffic through a provider-provided VPN could be considered a reasonable = protection for the cases folks have outlined. It just doesn't seem like = a popular need at this point, and there seem to be no easy wins for = hosted clients unable to register with a certificate authority. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote: >>>>>>>=20 >>>>>>>> I have been wondering if we can combine a couple of things such = as a client generated transaction secret and use limited TLS to achieve = a fix. Note: this would address a hacker sniffing a returned = authorization code, but it probably does little for the MITM scenario = that was also outlined. >>>>>>>>=20 >>>>>>>> 1. The client app generate a random number or sequence of = characters, lets call it "request_id", then that value would be included = and securely (using TLS) transmitted in the authorization request. >>>>>>>> 2. The authorization server does its usual thing and returns, = preferably securely but not necessarily, the authorization code to the = client app. >>>>>>>> 3. Upon requesting an access_token, the client app also = includes the same request_id in its secure request to the token = endpoint. >>>>>>>> 4. The token server verifies that the "request_id" matches the = request_id supplied in the authorize request (in addition to all the = other processing). >>>>>>>>=20 >>>>>>>> Since both requests are sent securely a sniffing client cannot = obtain the client request_id even though it might be able to obtain the = authorization code being returned. >>>>>>>>=20 >>>>>>>> What this might allow is that the client can transmit a secret = protected by TLS in its outbound request, but can accept non-secure = delivery of the authorization code. The token server then has a means = to verify that the client exchanging the authorization code is the same = one that made the initial request. >>>>>>>>=20 >>>>>>>> This is off the top of my head, I am sure the proposal is = likely not yet a complete solution, but maybe someone can build on that. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2011-04-04, at 10:52 AM, Oleg Gryb wrote: >>>>>>>>=20 >>>>>>>>> After looking into exiting (and working) implementations of = OAuth 1.0 in mobile world I have strong doubts about possibility of = implementing what was suggested in option #3.=20 >>>>>>>>>=20 >>>>>>>>> In my view, two conditions are needed to achieve that: >>>>>>>>>=20 >>>>>>>>> 1. Something unique stored on a mobile client. >>>>>>>>> 2. That something should be a secret, so other (malicious) = clients could not reuse it. >>>>>>>>>=20 >>>>>>>>> Distribution of that "unique secrets" should be automated in = the mobile world and is usually included to mobile application=20 >>>>>>>>> activation process, but that activation process can't make = conditions 1 & 2 above met in full, becuase: >>>>>>>>>=20 >>>>>>>>> 1. As soon as secrets are distributed to a mobile device they = are not quite secret any more >>>>>>>>> 2. As soon as the secret becomes known, a simulator or other = mobile device can be used to spoof the traffic >>>>>>>>>=20 >>>>>>>>> I would consider option #3 as an illusion until somebody comes = up with a solution that would address the described issues. >>>>>>>>>=20 >>>>>>>>> BTW, the draft of "OAuth Dynamic Client Registration Protocol" = (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on = Feb. 12 and I didn't see any attempts to re-vitalise it. I think it = would be better and more beneficial for the community to return to this = protocol rather than inventing a new method of "mutual authentication".=20= >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> From: Phil Hunt >>>>>>>>> To: Prateek Mishra >>>>>>>>> Cc: OAuth WG >>>>>>>>> Sent: Mon, April 4, 2011 9:52:17 AM >>>>>>>>> Subject: Re: [OAUTH-WG] Authorization code security issue = (reframed) >>>>>>>>>=20 >>>>>>>>> Apologies for the long message (again). I have attempted to = sum things up and bring out the issue without using any existing service = or party as an example of problems. It seems some have taken offence to = my previous message pushing for a solution. As a result it was not = productive. I apologize. Hopefully this message sticks to the issue of = developing an appropriate counter measure to threats as that is my only = intent. >>>>>>>>>=20 >>>>>>>>> As Prateek clarified in the previous message to Francisco, = SAML also uses SHOULD, but artifact security is achieved by an = additional counter-measure... >>>>>>>>>> The identity provider MUST ensure that only the service = provider to whom the message has >>>>>>>>>> been issued is given the message as the result of an = request. >>>>>>>>>=20 >>>>>>>>> Yet, in OAuth the client app is not unique for a particular = set of client credentials we currently have no way to verify that the = correct client got the code. This has been the mechanism that the = community has been assuming solves the problem. Client credentials do = not always work to protect the authorization code because in OAuth you = can have many many clients with the same credential. For example = everyone with the same mobile app likely has the same client credential. = Thus a copy of a valid client app which is easy to obtain becomes the = hacker's attack vector. So, the client credential is not an effective = counter in this case. >>>>>>>>>=20 >>>>>>>>> Several have commented that there are other supplementary = techniques for protection, but in my view, most of them work indirectly = and/or depend on correct collective configuration of several components. = Some of these are: tokens may be used one time; tokens are invalidated = if used a second time, tokens are sufficiently unique, etc. All of = these will help. But none are designed to directly counter the attack. = In fact the best one - token invalidation carries the additional problem = of unreliable service for the legitimate client. The hacker can deny = service to anyone in the room simply by re-using any tokens seen. >>>>>>>>>=20 >>>>>>>>> =46rom my perspective, the "easy" solution was to increase the = requirements on TLS from SHOULD to MUST to prevent eavesdropping of the = code. This was echoed by several others. I agree this will not work for = everyone. Many have made strong arguments for why they can't use it. But = without a MUST we are still missing a direct counter to the threat. >>>>>>>>>=20 >>>>>>>>> I don't want to change things at this late date, but maybe = this means introducing some form of mutual authentication -- some way = for the requesting client "instance" to prove that they are the copy = eligible to use an authorization code.=20 >>>>>>>>>=20 >>>>>>>>> To end this discussion, I propose we vote on the proposal from = Eran plus one new option... >>>>>>>>> 1. Include a normative MUST use TLS for the client redirection = URI endpoint. >>>>>>>>> 2. Include a normative SHOULD use TLS for the client = redirection URI endpoint with strong language explaining the various = attacks possible if the endpoint is not made secure. >>>>>>>>> 3. Keep current language of SHOULD, but develop a direct = counter-measure to token theft such as specific client instance = identification or mutual authentication. >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>> phil.hunt@oracle.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: >>>>>>>>>=20 >>>>>>>>>> Francisco, >>>>>>>>>>=20 >>>>>>>>>> You are right, I was in error to suggest that it was a MUST. >>>>>>>>>>=20 >>>>>>>>>> I think my main concern was that security considerations = should not be based on polling developers/deployers of an existing or = legacy protocol. >>>>>>>>>>=20 >>>>>>>>>> SAML does include some additional countermeasures though - = for example (lines 595-596, profiles document) - that specifically deal = with the >>>>>>>>>> artifact being leaked -=20 >>>>>>>>>>=20 >>>>>>>>>> [quote] >>>>>>>>>> The identity provider MUST ensure that only the service = provider to whom the message has >>>>>>>>>> been issued is given the message as the result of an = request. >>>>>>>>>> [\quote] >>>>>>>>>>=20 >>>>>>>>>> - prateek >>>>>>>>>>> Hi Prateek, >>>>>>>>>>>=20 >>>>>>>>>>>> I would like to strongly disagree with this proposal. >>>>>>>>>>>>=20 >>>>>>>>>>>> It amounts to explicitly making OAuth 2.0 insecure so as to >>>>>>>>>>>> satisfy some mysterious and unspecified set of legacy OAuth >>>>>>>>>>>> 1.0 deployments. >>>>>>>>>>>>=20 >>>>>>>>>>>> The SAML web SSO (artifact) profile - which shares many >>>>>>>>>>>> characteristics with the initial steps in OAuth - requires >>>>>>>>>>>> precisely such a counter-measure and is widely implemented >>>>>>>>>>>> in 1000s of deployments. >>>>>>>>>>>=20 >>>>>>>>>>> What counter-measure is this? Can you provide a reference? >>>>>>>>>>> Section 4.1.3.5 of=20 >>>>>>>>>>> = http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>>>>>>>>>> recommends TLS but does not require it. >>>>>>>>>>>=20 >>>>>>>>>>> Francisco >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >=20 From jricher@mitre.org Mon Apr 4 13:08:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9CB3A67C3 for ; Mon, 4 Apr 2011 13:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[AWL=1.597, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UexcMRNqJZqM for ; Mon, 4 Apr 2011 13:08:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 580393A67C2 for ; Mon, 4 Apr 2011 13:08:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BC17821B144B; Mon, 4 Apr 2011 16:09:54 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B525921B102C; Mon, 4 Apr 2011 16:09:54 -0400 (EDT) Received: from [129.83.50.23] (129.83.50.23) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Mon, 4 Apr 2011 16:09:54 -0400 From: Justin Richer To: Skylar Woodward In-Reply-To: References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 4 Apr 2011 16:09:57 -0400 Message-ID: <1301947797.31750.53.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:08:13 -0000 Agreed - we are planning to use the auth-code flow for native apps and have no immediate plans to use implicit mode for native clients, either. We'd be using the auth-code flow with a client id only and no client secret, which I think is the pattern that everyone else is planning to follow. -- justin On Mon, 2011-04-04 at 14:54 -0400, Skylar Woodward wrote: > I agree with Marius' points. We plan to support the auth-code flow for native apps as well. There is no reason why native apps can't perform a successful auth-code flow, they just do so without client credentials. However, the spec doesn't make it clear that this is viable option. > > skylar > > > On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote: > > > On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wrote: > >> A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once. > >> > >> What is the best profile to use for an app that can't have a client secret and needs a refresh token or a long lived access token? > > > > The authorization code grant, aka web server flow. > > > > The spec is misleading in this respect IMO. > > > > Marius > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Mon Apr 4 13:45:24 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7C528C142 for ; Mon, 4 Apr 2011 13:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02jfW+nHyr0j for ; Mon, 4 Apr 2011 13:45:24 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 0436728C12A for ; Mon, 4 Apr 2011 13:45:23 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p34Kl5tp028185 for ; Mon, 4 Apr 2011 13:47:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301950026; bh=FXFjnKO1lnzDLL7YaDRT7dsTcpk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=LEI5cgVnSpk9EOih7mAhr7J+itpbec9arkpZp6kb93jAtAXrlyU9t6juMhJLmq2nT iDPsAvfjqjIGDhg/dB+UQ== Received: from gyg13 (gyg13.prod.google.com [10.243.50.141]) by wpaz21.hot.corp.google.com with ESMTP id p34Kl4wi001417 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 4 Apr 2011 13:47:04 -0700 Received: by gyg13 with SMTP id 13so3070451gyg.41 for ; Mon, 04 Apr 2011 13:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=km9KFFWxNdZrIhXmx/Z8SZIcVGqtozuESbDld3SdZUw=; b=jDcLg8dD+H2wuZvEM8c9QwXoq8SLfQ5LB42PUY9i/VrrK9XFYjEOzz6gYMh/pqIpc3 JHGQHy2vvD5tIW9vMaIg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=yZghdqUeRBQxLc3z2fAous0GKZ1bOnOhKRkDI8plWi2/mCWQsbKqDR3IuOVpARbJQh l6fTgasxDLduTbI/dAow== Received: by 10.101.54.12 with SMTP id g12mr2680652ank.38.1301950024145; Mon, 04 Apr 2011 13:47:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.34.4 with HTTP; Mon, 4 Apr 2011 13:46:43 -0700 (PDT) In-Reply-To: <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: Marius Scurtescu Date: Mon, 4 Apr 2011 13:46:43 -0700 Message-ID: To: "Zeltsan, Zachary (Zachary)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:45:25 -0000 On Mon, Apr 4, 2011 at 12:38 PM, Zeltsan, Zachary (Zachary) wrote: > According to section "6 Refreshing an Access Token" (-13.txt), client whe= n making a request for exchanging a refresh token for an access token has t= o include its authentication credentials, and the "authorization server MUS= T validate the client credentials". > How can this be done if a client is an application that can't have a clie= nt secret? > The authorization code grant does require client authentication (per sect= ion 4.1): > > (D) =A0The client requests an access token from the authorization > =A0 =A0 =A0 =A0server's token endpoint by authenticating using its client > =A0 =A0 =A0 =A0credentials, and includes the authorization code received = in the > =A0 =A0 =A0 =A0previous step. > > It appears that the clients that cannot keep its secret cannot use (be is= sued) the refresh tokens. Right, so something has to give, otherwise there is no solution for native = apps. An authorization server will have to accept clients with no secrets. Google chose to actually issue secrets even for native apps, with the understanding that they cannot be guarded properly. It just keeps the flows and code paths uniform. Marius From drobin1437@gmail.com Mon Apr 4 13:56:40 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1BC33A67EE for ; Mon, 4 Apr 2011 13:56:40 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZMTdJK16dhW for ; Mon, 4 Apr 2011 13:56:40 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id DADBA3A67B7 for ; Mon, 4 Apr 2011 13:56:39 -0700 (PDT) Received: by gwb20 with SMTP id 20so2734533gwb.31 for ; Mon, 04 Apr 2011 13:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=1Ra5eRLmRJCmO/skpde0I+TnV3cKsRLXAy5VBLNRT+8=; b=A9+aJMex65K2N7mR9yVGK0+6zG9aRsplg0TuNNB2CJ5i2xSuS9aYWyoUTrBTCHzH6e uGUbQxlneYfweR7paJpXykIr1D/AXrFFW01GtsXxFQ2/CPLyKiKcU9XZ/wf+q3GzV3Dj o6U8Q6pxquIe8S5ClfCHLzVQOWIOm86qjuhLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=grcJEWTbG+styEGIMuekI1Abd1jVKeN1m0dPWyYrGQIenCbd/FPEcoDsI0fAvHdwfu kohHFHEvbgnaDw8WoPYDXK9EYpUdvEpcTBR72Yx3YtAmbw5xJFtONDmfxmo3d7389TFN HVNa7kFQc7rhqr36H38L8UDuwd9VCGMfCj8Ok= MIME-Version: 1.0 Received: by 10.150.114.3 with SMTP id m3mr3317321ybc.416.1301950702280; Mon, 04 Apr 2011 13:58:22 -0700 (PDT) Received: by 10.151.79.1 with HTTP; Mon, 4 Apr 2011 13:58:22 -0700 (PDT) Date: Mon, 4 Apr 2011 16:58:22 -0400 Message-ID: From: David Robinson To: oauth@ietf.org Content-Type: multipart/alternative; boundary=00151748e8c01fe1f004a01e0504 Subject: [OAUTH-WG] Chain Grant Type for OAuth 2 spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:56:40 -0000 --00151748e8c01fe1f004a01e0504 Content-Type: text/plain; charset=ISO-8859-1 Phil, I read through the Chain Grant Type for OAuth 2 draft and appreciate the problem you are addressing. We encountered the same issue when using open social gadgets with OAuth when data needs to come from more than one server. It is not user friendly to prompt an end user to log into multiple servers and a robust chaining model can help. You indicate a domain is all resource servers that share a common OAuth token service (Section 2). Is a token service actually an "authorization server" per v13 of the base OAuth 2 spec or are you referring to something else ? In Section 2.2, first two bullets, is the implication that "OAuth token services" are performing identity federation ? The spec states the method used to do this is in companion OAuth token specifications, but it isn't clear to me which token specification addresses identity federation. Which token specs/sections are you referring to as an example ? --00151748e8c01fe1f004a01e0504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Phil,

I read through the Chain Grant Type for OAuth 2 draft and appr= eciate the problem you are addressing.

We encountered the same issue= when using open social gadgets with OAuth when data needs
to come from = more than one server.=A0 It is not user friendly to prompt an end user to l= og into multiple
servers and a robust chaining model can help.

You indicate a domain = is all resource servers that share a common OAuth token service (Section 2)= .
Is a token service actually an "authorization server" per v1= 3 of the base OAuth 2 spec or are you referring to something else ?

In Section 2.2, first two bullets, is the implication that "OAuth = token services" are performing identity federation ?
The spec state= s the method used to do this is in companion OAuth token specifications, bu= t it isn't clear to me
which token specification addresses identity federation.=A0 Which token spe= cs/sections are you referring to as an example ?


--00151748e8c01fe1f004a01e0504-- From phil.hunt@oracle.com Mon Apr 4 13:57:37 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C9C3A67B7 for ; Mon, 4 Apr 2011 13:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EouykKkAYd4P for ; Mon, 4 Apr 2011 13:57:36 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 985803A67EE for ; Mon, 4 Apr 2011 13:57:36 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p34KxGg9011757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 20:59:18 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p34KxFPL024993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2011 20:59:16 GMT Received: from abhmt020.oracle.com (abhmt020.oracle.com [141.146.116.29]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p34KxF78009186; Mon, 4 Apr 2011 15:59:15 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 13:59:15 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <1301947797.31750.53.camel@ground> Date: Mon, 4 Apr 2011 13:59:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <1301947797.31750.53.camel@ground> To: Justin Richer X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4D9A3124.0096:SCFSTAT5015188,ss=1,fgs=0 Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:57:37 -0000 Does section 3.2 help you? "In addition, the authorization server MAY allow unauthenticated access = token requests when the client identity does not matter (e.g. anonymous = client) or when the client identity is established via other means." Phil phil.hunt@oracle.com On 2011-04-04, at 1:09 PM, Justin Richer wrote: > Agreed - we are planning to use the auth-code flow for native apps and > have no immediate plans to use implicit mode for native clients, = either. > We'd be using the auth-code flow with a client id only and no client > secret, which I think is the pattern that everyone else is planning to > follow. >=20 > -- justin >=20 > On Mon, 2011-04-04 at 14:54 -0400, Skylar Woodward wrote: >> I agree with Marius' points. We plan to support the auth-code flow = for native apps as well. There is no reason why native apps can't = perform a successful auth-code flow, they just do so without client = credentials. However, the spec doesn't make it clear that this is = viable option. >>=20 >> skylar >>=20 >>=20 >> On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote: >>=20 >>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden = wrote: >>>> A typical iPhone app cannot be shipped with a client secret and = rightly or wrongly users expect to only have to enter their credentials = once. >>>>=20 >>>> What is the best profile to use for an app that can't have a client = secret and needs a refresh token or a long lived access token? >>>=20 >>> The authorization code grant, aka web server flow. >>>=20 >>> The spec is misleading in this respect IMO. >>>=20 >>> Marius >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Mon Apr 4 13:58:46 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4355F3A67F4 for ; Mon, 4 Apr 2011 13:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.602 X-Spam-Level: X-Spam-Status: No, score=-105.602 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cowYbxD-gZLj for ; Mon, 4 Apr 2011 13:58:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 33EE93A67EE for ; Mon, 4 Apr 2011 13:58:44 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p34L0QIk027819 for ; Mon, 4 Apr 2011 14:00:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301950827; bh=BkBLGwHmaTRXwH9+gZU0ngw8b0g=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=GLOx3PG5+uZVuVX5HZ1GdN+mVEx6QhOP53qrq0ZJNO0sEbWkvuqZ20RXQi/qj3E3j kepUcZBWcCqwKhqRKNeUw== Received: from gyg8 (gyg8.prod.google.com [10.243.50.136]) by wpaz5.hot.corp.google.com with ESMTP id p34Kxl27020545 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 4 Apr 2011 14:00:23 -0700 Received: by gyg8 with SMTP id 8so2865106gyg.24 for ; Mon, 04 Apr 2011 14:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yUOnVAK07bv93I2aSwQAKqKFUskaeAyzvbTKBvpsVW8=; b=ebGZ8f3x3ZNeSVt4n5G36qUZpVGd9pWCywHghWJeaxiGgxiVZtDthy+3ShwmYaLhe5 ZXWySYG6faQdQUNDyVaQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nAmvsvpoQJtvb9G+R9LA6RQgASR46Whf5MgJCneXMNE82BYtlBEA2tzAwkot8E20sU UnpAmUJF5G+MXmskkYng== MIME-Version: 1.0 Received: by 10.90.23.19 with SMTP id 19mr58171agw.108.1301950823500; Mon, 04 Apr 2011 14:00:23 -0700 (PDT) Received: by 10.90.93.15 with HTTP; Mon, 4 Apr 2011 14:00:23 -0700 (PDT) In-Reply-To: <4A384831-10D3-4305-98ED-C189761E6D32@oracle.com> References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> <2BDF838F-C5CE-43C3-B017-91D967ECDAC0@kiva.org> <4A384831-10D3-4305-98ED-C189761E6D32@oracle.com> Date: Mon, 4 Apr 2011 14:00:23 -0700 Message-ID: From: Brian Eaton To: Phil Hunt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:58:46 -0000 On Mon, Apr 4, 2011 at 1:06 PM, Phil Hunt wrote: > Very quickly here is the attack... > 1) Paul starts dance at good Client & =A0good AS, App requests authorizat= ion. Note: outbound call is secure, but returned redirect is not. For the record, we haven't had particular problems with installed apps finding secure callback URLs. We've got mobile clients using the following approaches: - using custom URL schemes. I gather this is forbidden by spec, but it prevents the attack at least. - using https URLs hosted at Google, in a web view Mobile apps watch the URL (you can do this with embedded web views) and read the authorization code that way. - using https URLs hosted at third-party web sites, in a web view These are typically static or very simple web sites that are used just to transfer control back to the mobile app. - using https URLs hosted at Google, in the default browser rather than a web view There are various tricks that you can use to pick up the authorization code from the default browser. They are all ugly, but they work. Cheers, Brian From torsten@lodderstedt.net Mon Apr 4 13:59:23 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA8D93A67F4 for ; Mon, 4 Apr 2011 13:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL3aUlbE6Ozr for ; Mon, 4 Apr 2011 13:59:23 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by core3.amsl.com (Postfix) with ESMTP id BBEBC3A67EE for ; Mon, 4 Apr 2011 13:59:22 -0700 (PDT) Received: from [79.253.39.103] (helo=[192.168.71.20]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Q6qtT-0000SJ-DC; Mon, 04 Apr 2011 23:01:03 +0200 Message-ID: <4D9A318D.3090908@lodderstedt.net> Date: Mon, 04 Apr 2011 23:01:01 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Zeltsan, Zachary (Zachary)" References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:59:24 -0000 Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): > According to section "6 Refreshing an Access Token" (-13.txt), client when making a request for exchanging a refresh token for an access token has to include its authentication credentials, and the "authorization server MUST validate the client credentials". > How can this be done if a client is an application that can't have a client secret? > The authorization code grant does require client authentication (per section 4.1): > > (D) The client requests an access token from the authorization > server's token endpoint by authenticating using its client > credentials, and includes the authorization code received in the > previous step. > > It appears that the clients that cannot keep its secret cannot use (be issued) the refresh tokens. In my opinion, this part of the spec is misleading. Authorization code MUST be possible without client authentication. Otherwise, OAuth is useless for native apps. http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-01#section-2.10 describes how the flow can be protected in such cases. regards, Torsten. > Zachary > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Marius Scurtescu > Sent: Monday, April 04, 2011 2:30 PM > To: Kris Selden > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth > > On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wrote: >> A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once. >> >> What is the best profile to use for an app that can't have a client secret and needs a refresh token or a long lived access token? > The authorization code grant, aka web server flow. > > The spec is misleading in this respect IMO. > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Mon Apr 4 14:06:08 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B223A6802 for ; Mon, 4 Apr 2011 14:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx3KQ3QkY2k8 for ; Mon, 4 Apr 2011 14:06:07 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 19C053A67FD for ; Mon, 4 Apr 2011 14:06:07 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p34L7lmw001900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 21:07:49 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p34L7lZY018365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2011 21:07:47 GMT Received: from abhmt019.oracle.com (abhmt019.oracle.com [141.146.116.28]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p34L7k1D004425; Mon, 4 Apr 2011 16:07:46 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 14:07:46 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Mon, 4 Apr 2011 14:07:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51D14DBB-80CB-413D-BB3A-09D6D5571B0E@oracle.com> References: To: David Robinson X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4D9A3323.00EE:SCFSTAT5015188,ss=1,fgs=0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Chain Grant Type for OAuth 2 spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 21:06:08 -0000 I think in practical terms, an oAuth domain is simply one where the = access token accepted. In practical terms this likely means they share = the same token service. Regarding 2.2. The attention is not identity federation, just federation = of the token itself. The main thing is the target token server has to = have a way to verify the inbound oauth_token. If it is a reference = identifier, it will potentially have to make a call back to the issuing = server (out of scope). If it is a parsabled token, then the token must = be valid according to its specification (e.g. JWT token). It is fair to assume that the inbound token includes certain claims = (which may be identity) and scope being asserted by the originating = token server. Phil phil.hunt@oracle.com On 2011-04-04, at 1:58 PM, David Robinson wrote: > Phil, >=20 > I read through the Chain Grant Type for OAuth 2 draft and appreciate = the problem you are addressing. >=20 > We encountered the same issue when using open social gadgets with = OAuth when data needs > to come from more than one server. It is not user friendly to prompt = an end user to log into multiple > servers and a robust chaining model can help. >=20 > You indicate a domain is all resource servers that share a common = OAuth token service (Section 2). > Is a token service actually an "authorization server" per v13 of the = base OAuth 2 spec or are you referring to something else ? >=20 > In Section 2.2, first two bullets, is the implication that "OAuth = token services" are performing identity federation ? > The spec states the method used to do this is in companion OAuth token = specifications, but it isn't clear to me > which token specification addresses identity federation. Which token = specs/sections are you referring to as an example ? >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Apr 4 14:25:12 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9533A6811 for ; Mon, 4 Apr 2011 14:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvwHZ3PX9zKn for ; Mon, 4 Apr 2011 14:25:11 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2AC6B3A680E for ; Mon, 4 Apr 2011 14:25:10 -0700 (PDT) Received: (qmail 30054 invoked from network); 4 Apr 2011 21:26:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Apr 2011 21:26:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 4 Apr 2011 14:26:39 -0700 From: Eran Hammer-Lahav To: Mike Jones , Skylar Woodward , Marius Scurtescu Date: Mon, 4 Apr 2011 14:26:35 -0700 Thread-Topic: [OAUTH-WG] Guidance on Native Applications in the Framework Spec (was Flowchart for legs of OAuth) Thread-Index: Acvy+2PM0mazYfusS8qdLymhVsK+oAAEovFw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DC40@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943252CA711@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252CA711@TK5EX14MBXC203.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Guidance on Native Applications in the Framework Spec (was Flowchart for legs of OAuth) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 21:25:12 -0000 Just to clarify. Those attending the meeting did not decide. The chairs ask= ed Torsten and Anthony to take the text removed and resubmit it for working= group consideration. The text discussed is all non-normative, and is meant= as a helpful guide. As editor, I don't have any objections and think this is a worthwhile effor= t. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Mike Jones > Sent: Monday, April 04, 2011 12:06 PM > To: Skylar Woodward; Marius Scurtescu > Cc: Kris Selden; oauth@ietf.org > Subject: [OAUTH-WG] Guidance on Native Applications in the Framework > Spec (was Flowchart for legs of OAuth) >=20 > One of the results at the OAuth meeting on Friday was that non-normative > text describing how to use OAuth with native applications will be restore= d to > the framework draft. We could start with the text from past drafts, but = it can > likely be improved upon as well. >=20 > Marius, as someone who has extensively deployed an OAuth protocol with > native apps, what would you like the draft to say about this? (Others wi= th > actual deployments, please respond as well if you have things to add!) >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Skylar Woodward > Sent: Monday, April 04, 2011 11:54 AM > To: Marius Scurtescu > Cc: Kris Selden; oauth@ietf.org > Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >=20 > I agree with Marius' points. We plan to support the auth-code flow for na= tive > apps as well. There is no reason why native apps can't perform a success= ful > auth-code flow, they just do so without client credentials. However, the > spec doesn't make it clear that this is viable option. >=20 > skylar >=20 >=20 > On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote: >=20 > > On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden > wrote: > >> A typical iPhone app cannot be shipped with a client secret and rightl= y or > wrongly users expect to only have to enter their credentials once. > >> > >> What is the best profile to use for an app that can't have a client se= cret > and needs a refresh token or a long lived access token? > > > > The authorization code grant, aka web server flow. > > > > The spec is misleading in this respect IMO. > > > > Marius > > _______________________________________________ > > 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 From eran@hueniverse.com Mon Apr 4 14:28:55 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E8F3A6801 for ; Mon, 4 Apr 2011 14:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4FzmhN4nhVJ for ; Mon, 4 Apr 2011 14:28:51 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 9B76B3A67A8 for ; Mon, 4 Apr 2011 14:28:50 -0700 (PDT) Received: (qmail 3223 invoked from network); 4 Apr 2011 21:30:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Apr 2011 21:30:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 4 Apr 2011 14:30:30 -0700 From: Eran Hammer-Lahav To: Brian Eaton , Phil Hunt Date: Mon, 4 Apr 2011 14:30:27 -0700 Thread-Topic: [OAUTH-WG] Authorization code security issue (reframed) Thread-Index: AcvzC1ZOWcxQtrGBQB6OO57apcAllgABAmjg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DC45@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> <2BDF838F-C5CE-43C3-B017-91D967ECDAC0@kiva.org> <4A384831-10D3-4305-98ED-C189761E6D32@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 21:28:55 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Monday, April 04, 2011 2:00 PM > To: Phil Hunt > Cc: Oleg Gryb; OAuth WG > Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) >=20 > On Mon, Apr 4, 2011 at 1:06 PM, Phil Hunt wrote: > > Very quickly here is the attack... > > 1) Paul starts dance at good Client & =A0good AS, App requests authoriz= ation. > Note: outbound call is secure, but returned redirect is not. >=20 > For the record, we haven't had particular problems with installed apps fi= nding > secure callback URLs. We've got mobile clients using the following > approaches: >=20 > - using custom URL schemes. > I gather this is forbidden by spec, but it prevents the attack at leas= t. Not at all. Just as a matter of "standards etiquette" we can't explicitly r= ecommend violating other standards. The only issue is using unregistered sc= hemes. EHL > - using https URLs hosted at Google, in a web view > Mobile apps watch the URL (you can do this with embedded web views) > and read the authorization code that way. >=20 > - using https URLs hosted at third-party web sites, in a web view > These are typically static or very simple web sites that are used just= to > transfer control back to the mobile app. >=20 > - using https URLs hosted at Google, in the default browser rather than a > web view > There are various tricks that you can use to pick up the authorizatio= n code > from the default browser. They are all ugly, but they work. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From zachary.zeltsan@alcatel-lucent.com Mon Apr 4 15:48:12 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577A53A681E for ; Mon, 4 Apr 2011 15:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nxMhr3Wuczz for ; Mon, 4 Apr 2011 15:48:11 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 55E813A67FD for ; Mon, 4 Apr 2011 15:48:10 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p34Mnm2g027267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 17:49:48 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p34Mnlsc011442 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Apr 2011 17:49:48 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 4 Apr 2011 17:49:47 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Torsten Lodderstedt'" Date: Mon, 4 Apr 2011 17:49:47 -0500 Thread-Topic: [OAUTH-WG] Flowchart for legs of OAuth Thread-Index: AcvzC2stcjaOyOkZQgaVCgbvGSW4mAABrjlg Message-ID: <5710F82C0E73B04FA559560098BF95B12505F041B6@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net> In-Reply-To: <4D9A318D.3090908@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 22:48:12 -0000 Torsten, I agree that the described measures would protect the native application cl= ients.=20 But the current specification, as I understand it, does not allow the use o= f the authorization code without client's authentication. It also requires = client authentication whenever the refresh tokens are used. In my opinion t= he authorization code, as presently specified, is not suitable for an appli= cation "that can't have a client secret and needs a refresh token or a long= lived access token". I agree with Marius that unless the authorization code's specification is m= odified, it is not useful for the native applications. Regards, =20 Zachary -----Original Message----- From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 Sent: Monday, April 04, 2011 5:01 PM To: Zeltsan, Zachary (Zachary) Cc: 'Marius Scurtescu'; Kris Selden; oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): > According to section "6 Refreshing an Access Token" (-13.txt), client whe= n making a request for exchanging a refresh token for an access token has t= o include its authentication credentials, and the "authorization server MUS= T validate the client credentials". > How can this be done if a client is an application that can't have a clie= nt secret? > The authorization code grant does require client authentication (per sect= ion 4.1): > > (D) The client requests an access token from the authorization > server's token endpoint by authenticating using its client > credentials, and includes the authorization code received in the > previous step. > > It appears that the clients that cannot keep its secret cannot use (be is= sued) the refresh tokens. In my opinion, this part of the spec is misleading. Authorization code=20 MUST be possible without client authentication. Otherwise, OAuth is=20 useless for native apps. http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-0= 1#section-2.10=20 describes how the flow can be protected in such cases. regards, Torsten. > Zachary > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Marius Scurtescu > Sent: Monday, April 04, 2011 2:30 PM > To: Kris Selden > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth > > On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wrot= e: >> A typical iPhone app cannot be shipped with a client secret and rightly = or wrongly users expect to only have to enter their credentials once. >> >> What is the best profile to use for an app that can't have a client secr= et and needs a refresh token or a long lived access token? > The authorization code grant, aka web server flow. > > The spec is misleading in this respect IMO. > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From skylar@kiva.org Mon Apr 4 16:13:19 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C083A6821 for ; Mon, 4 Apr 2011 16:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rvs3dEVZbIOZ for ; Mon, 4 Apr 2011 16:13:18 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by core3.amsl.com (Postfix) with SMTP id 407A13A6813 for ; Mon, 4 Apr 2011 16:13:17 -0700 (PDT) Received: from source ([209.85.213.170]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKTZpQ9Bov1lEN5hBRYj0RO1RswbZcPrTE@postini.com; Mon, 04 Apr 2011 16:15:01 PDT Received: by yxi11 with SMTP id 11so3508764yxi.15 for ; Mon, 04 Apr 2011 16:15:00 -0700 (PDT) Received: by 10.236.77.72 with SMTP id c48mr11047571yhe.292.1301958899961; Mon, 04 Apr 2011 16:14:59 -0700 (PDT) Received: from [192.168.2.8] (74-128-24-154.dhcp.insightbb.com [74.128.24.154]) by mx.google.com with ESMTPS id f32sm2552576yhc.28.2011.04.04.16.14.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 16:14:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <4D9A318D.3090908@lodderstedt.net> Date: Mon, 4 Apr 2011 19:14:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1084) Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 23:13:19 -0000 In our implementation (not yet public) we accept the empty string ("") = as the value for clients not issued secrets. While this was done to = simplify the interface and implementation, it would make it compliant in = my view. In this case, the authorization server is validating the = credentials, which are the client ID and the empty string, which is = equivalent security-wise to any other length of "secret" issued to a = native client. Besides, for many providers, the client credentials will only be a = client ID. They would plan to secure all exchanges over TLS and = credentials serve just as a tracking device or at best, a weak form of = identification. skylar On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote: > Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): >> According to section "6 Refreshing an Access Token" (-13.txt), client = when making a request for exchanging a refresh token for an access token = has to include its authentication credentials, and the "authorization = server MUST validate the client credentials". >> How can this be done if a client is an application that can't have a = client secret? >> The authorization code grant does require client authentication (per = section 4.1): >>=20 >> (D) The client requests an access token from the authorization >> server's token endpoint by authenticating using its client >> credentials, and includes the authorization code received in = the >> previous step. >>=20 >> It appears that the clients that cannot keep its secret cannot use = (be issued) the refresh tokens. >=20 > In my opinion, this part of the spec is misleading. Authorization code = MUST be possible without client authentication. Otherwise, OAuth is = useless for native apps. >=20 > = http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-= 01#section-2.10 describes how the flow can be protected in such cases. >=20 > regards, > Torsten. >> Zachary >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Marius Scurtescu >> Sent: Monday, April 04, 2011 2:30 PM >> To: Kris Selden >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>=20 >> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden = wrote: >>> A typical iPhone app cannot be shipped with a client secret and = rightly or wrongly users expect to only have to enter their credentials = once. >>>=20 >>> What is the best profile to use for an app that can't have a client = secret and needs a refresh token or a long lived access token? >> The authorization code grant, aka web server flow. >>=20 >> The spec is misleading in this respect IMO. >>=20 >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Mon Apr 4 17:07:34 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5173A6823 for ; Mon, 4 Apr 2011 17:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.929 X-Spam-Level: X-Spam-Status: No, score=-105.929 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWiMbQZYs+ri for ; Mon, 4 Apr 2011 17:07:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 0FE333A6821 for ; Mon, 4 Apr 2011 17:07:33 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p3509FOt004762 for ; Mon, 4 Apr 2011 17:09:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301962156; bh=P37qIhRpwVNB7DrN4F9KLw2YFpo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=IYKsloZXS3tdyTrwPycIT0pNlFDsM/bYdsc1zoWzAio+1SbP3Jr+oqFrFjs8QUxEo JJ1E3UNRIQm69k4kR88lQ== Received: from gyh4 (gyh4.prod.google.com [10.243.50.196]) by kpbe14.cbf.corp.google.com with ESMTP id p3509ESE018905 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 4 Apr 2011 17:09:14 -0700 Received: by gyh4 with SMTP id 4so2932539gyh.26 for ; Mon, 04 Apr 2011 17:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=LPcunTVkA1KsHgg0JOFXUgsbGoXgjChdEStwAR5MGuE=; b=AnPrNYk1ZwNgjOuPsa7lYZdCynHlNbLWVNHZ31RPB8fTM0vhEZEeIhaspsWwNFzFBI V5H7+k29G+QujRbvPqCw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=gQQfhR5ZgVrXhvLgCKrvwcg1q+1iTyXam8oQ7Yjj6Q9iod7iVpPXCgkokIjVlQe682 vq2uDw6qEZX2zO+i5H3w== Received: by 10.91.202.13 with SMTP id e13mr8081211agq.33.1301962154185; Mon, 04 Apr 2011 17:09:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.34.4 with HTTP; Mon, 4 Apr 2011 17:08:54 -0700 (PDT) In-Reply-To: <38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net> <38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> From: Marius Scurtescu Date: Mon, 4 Apr 2011 17:08:54 -0700 Message-ID: To: Skylar Woodward Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 00:07:34 -0000 On Mon, Apr 4, 2011 at 4:14 PM, Skylar Woodward wrote: > In our implementation (not yet public) we accept the empty string ("") as= the value for clients not issued secrets. While this was done to simplify = the interface and implementation, it would make it compliant in my view. = =A0In this case, the authorization server is validating the credentials, wh= ich are the client ID and the empty string, which is equivalent security-wi= se to any other length of "secret" issued to a native client. I am splitting hairs now, but according to the spec an empty parameter value should be treated the same as if the parameter was not sent at all. So, empty secret violates the requirement for the parameter to be present. Marius From phil.hunt@oracle.com Mon Apr 4 17:08:38 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E7F3A6821 for ; Mon, 4 Apr 2011 17:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLWOAygrGlm2 for ; Mon, 4 Apr 2011 17:08:37 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 794233A67D0 for ; Mon, 4 Apr 2011 17:08:37 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p350AGRS025706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2011 00:10:17 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p350AFIa028708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 00:10:16 GMT Received: from abhmt015.oracle.com (abhmt015.oracle.com [141.146.116.24]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p350AFb9014150; Mon, 4 Apr 2011 19:10:15 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 17:10:15 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Mon, 4 Apr 2011 17:10:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9A9FECDB-3633-4434-9401-0B75209633E7@oracle.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net> <38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> To: Marius Scurtescu X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4D9A5DE8.0064:SCFSTAT5015188,ss=1,fgs=0 Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 00:08:38 -0000 Read 3.2. I believe you'll find an escape clause there. Phil phil.hunt@oracle.com On 2011-04-04, at 5:08 PM, Marius Scurtescu wrote: > On Mon, Apr 4, 2011 at 4:14 PM, Skylar Woodward = wrote: >> In our implementation (not yet public) we accept the empty string = ("") as the value for clients not issued secrets. While this was done to = simplify the interface and implementation, it would make it compliant in = my view. In this case, the authorization server is validating the = credentials, which are the client ID and the empty string, which is = equivalent security-wise to any other length of "secret" issued to a = native client. >=20 > I am splitting hairs now, but according to the spec an empty parameter > value should be treated the same as if the parameter was not sent at > all. So, empty secret violates the requirement for the parameter to be > present. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From fcorella@pomcor.com Mon Apr 4 17:33:43 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D0D3A6821 for ; Mon, 4 Apr 2011 17:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbpecQJCgcqR for ; Mon, 4 Apr 2011 17:33:42 -0700 (PDT) Received: from web55801.mail.re3.yahoo.com (web55801.mail.re3.yahoo.com [216.252.110.47]) by core3.amsl.com (Postfix) with SMTP id 065D83A6816 for ; Mon, 4 Apr 2011 17:33:41 -0700 (PDT) Received: (qmail 49220 invoked by uid 60001); 5 Apr 2011 00:35:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301963722; bh=l1CWR9WZ07/F8n40LTVJcGK4C2QaRk3/TnQRSqVmqr0=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=e27HrbqzT+SkA/1guejhKzfp8XTyM6ou/pkAimB8v4I2m/xAjR3mOiq/pBSSF+yLneHvcs7OVgpS/4KO9AF5CZRJEUzp5K7jH7holpetrAza0Ax5TQkeNL2NXEs5gmVKPlAug5lcgjjQkl+SiW/ZksY1LcHNHOHM2Bg0Z7BAi20= Message-ID: <887780.25851.qm@web55801.mail.re3.yahoo.com> X-YMail-OSG: FaIY.IQVM1nmL9.m9nCmTuL7RpaUSzRtu4YxRnc91q7awVS _yVanIz.LDjyosNzMaM967rWFx_tlFPD0ktih8Grn4HxqG_HtgKYJbw1pvUD j.aconTBOWjTAdchrb7Wv7Gas.2il9IA7lLmF10jQEiVKIScqpoNgaOlTTIv jiZTu5ylxn81aZ90wUruT.BD7foKIO5nR6_cj4udLdwvSBEcxkl_.vIEzQXS 6wHRyG6GPzMcTph1N8UbzGQRYc1x5YR0EBb2GQbG58byephxZFTLlVJoDAPc CxQ6hXlrbc.xfhvQs8424un2hvmc_zltWLN90__C75zuG29xpoPRhuPK8FDF o3cKlyZ9Q6q6u7TuY4TjbbPD1DTCTc_8KIKrZnJeiEylBHkfKkV5NBAdUgiv TQTa1 Received: from [174.65.103.16] by web55801.mail.re3.yahoo.com via HTTP; Mon, 04 Apr 2011 17:35:22 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Mon, 4 Apr 2011 17:35:22 -0700 (PDT) From: Francisco Corella To: Eran Hammer-Lahav , Skylar Woodward , Phil Hunt , Oleg Gryb , David Recordon In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1510669683-1301963722=:25851" Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 00:33:43 -0000 --0-1510669683-1301963722=:25851 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable David, > If this is changed to a MUST, Facebook will be in violation of the > specification moving forward. It is untenable to require all of our > *client* developers to implement TLS endpoints though we certainly > support developers who wish to do so. This is very different than > offerring our entire API (and now site as opt-in) over TLS as the > server. Why is it untenable?=A0 Is it because of the cost of a certificate?=A0 Many CAs offer certifcates for less $100, and there are free certificates.=A0 See http://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_servers= . Is it because of the cost of hosting an SSL site?=A0 You can have your own virtual server at Amazon for $14 a month.=A0 Is it because of the inconvenience of having to spend a few hours getting a certificate and adding SSL to your site? And how about putting your users and your data at risk?=A0 Is that tenable? Francisco --0-1510669683-1301963722=:25851 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
David,

> If this is changed to a MU= ST, Facebook will be in violation of the
> specification moving forwa= rd. It is untenable to require all of our
> *client* developers to im= plement TLS endpoints though we certainly
> support developers who wi= sh to do so. This is very different than
> offerring our entire API (= and now site as opt-in) over TLS as the
> server.

Why is it un= tenable?  Is it because of the cost of a
certificate?  Many CA= s offer certifcates for less $100, and
there are free certificates. = ; See
http://en.wikipedia.org/wiki/Comparison_of_SSL_certif= icates_for_web_servers.
Is it because of the cost of hosting an SSL = site?  You can
have your own virtual server at Amazon for $14 a month.  Is
it because of the inconvenience of having to spend a fe= w
hours getting a certificate and adding SSL to your site?

And ho= w about putting your users and your data at risk?  Is
that tenable?=

Francisco

--0-1510669683-1301963722=:25851-- From fcorella@pomcor.com Mon Apr 4 17:44:31 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E8A3A6817 for ; Mon, 4 Apr 2011 17:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSS5gD+y8KQD for ; Mon, 4 Apr 2011 17:44:30 -0700 (PDT) Received: from web55805.mail.re3.yahoo.com (web55805.mail.re3.yahoo.com [216.252.110.51]) by core3.amsl.com (Postfix) with SMTP id B0AD83A680E for ; Mon, 4 Apr 2011 17:44:30 -0700 (PDT) Received: (qmail 83039 invoked by uid 60001); 5 Apr 2011 00:46:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301964371; bh=rRv+68FGS2vskarXOh2xiyWdstor1O5y+HGAX7BCGzY=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ea4hWiGnteVSreWxf9WNwG0Ucwmtp5ugoHIA5Ia1kGqeV7p9vcWzQroRas2Q12uMscGLn9X91X/BnGabddzTaiBTnmmIGLXUf6/PbIyDCavcbvkaJdwU9AftMQy/KakPVPaUZnswBe2eelj1gamyQ7tAGD2vFc78lDOZT2gJFaM= Message-ID: <612045.49458.qm@web55805.mail.re3.yahoo.com> X-YMail-OSG: lleSeUkVM1kr1l8nO9YnpyO3_vpc9.AdG1SgbI7WbYFYPlT d9h5FrhFZTca1TEnBoUCMULnUhugn_1E3dM_3oytQsTB0zglTLkD4Jm7Diw5 hzXPAN7arrQBxiOcZzPAARmmhnNrelPaACRNnmT.K38fXxPv1twhSpvK0Zuk aaCUiMYv6PiwHaNnshJ4GAAbllgluwp0XhaUjOeGUls6d3MJHc3Gz5lzEcJD qavQLvBZ6B0bkGaprgqztceXU_wZ3FMCp4OEapBznHEXF.XFqh12oqx7dCMQ RplLsf5T_HsPu4wr_XDVHZcYNdKyKs22ZZsKY4jxcJJstWYqOkVAAiT9WLNF dkEgrYKRCodonDWk5yt1QIviixyvODxMuGX2UOpsJmaFLk1pdW4XcHXom.97 trCgd Received: from [174.65.103.16] by web55805.mail.re3.yahoo.com via HTTP; Mon, 04 Apr 2011 17:46:11 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Mon, 4 Apr 2011 17:46:11 -0700 (PDT) From: Francisco Corella To: Skylar Woodward , Phil Hunt , Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664D9B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1797915024-1301964371=:49458" Cc: Oleg Gryb , OAuth WG , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 00:44:31 -0000 --0-1797915024-1301964371=:49458 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eran, > I don=E2=80=99t think your statement that =E2=80=98the IETF should endors= e > lack of security=E2=80=99 is accurate or helpful. If the IETF endorsed a protocol such that a compliant implementation allows user impersonation and unauthorized access to protected resource, then the IETF would be endorsing lack of security.=C2=A0 How is that inaccurate? The statement is helpful from the point of view of the users who would be the victims of the attacks.=C2=A0 You seem to be concerned about companies and developers but not about users. > I completely rejects the notion that a SHOULD with strong > language explaining the risk is any less =E2=80=9Csecure=E2=80=9D than a > MUST. > > The only impact of using a MUST vs. a SHOULD is that > companies deploying it without requiring TLS on the > redirection endpoint will not be able to claim full > compliance if we use a MUST, but will be able to if we use a > SHOULD. > > RFC 2616 defines compliance as follows: > >=C2=A0=C2=A0=C2=A0 An implementation is not compliant if it fails to satis= fy one or more >=C2=A0=C2=A0=C2=A0 of the MUST or REQUIRED level requirements for the prot= ocols it >=C2=A0=C2=A0=C2=A0 implements. An implementation that satisfies all the MU= ST or REQUIRED >=C2=A0=C2=A0=C2=A0 level and all the SHOULD level requirements for its pro= tocols is said >=C2=A0=C2=A0=C2=A0 to be "unconditionally compliant"; one that satisfies a= ll the MUST >=C2=A0=C2=A0=C2=A0 level requirements but not all the SHOULD level require= ments for its >=C2=A0=C2=A0=C2=A0 protocols is said to be "conditionally compliant." > > If we used a SHOULD for TLS, and added such a language, it > will enable the definition of three classes of > implementations: non-compliant, unconditionally compliant > (your definition of secure), and conditionally compliant > (what Facebook, Yahoo, Google, and Kiva are likely to > deploy). Therefore we should use MUST, otherwise there can be "conditionally compliant" implementations that put users at risk. > But my point is that trying to paint the SHOULD option with > strong security guidance as =E2=80=98the IETF endorsing an insecure > protocol=E2=80=99 or =E2=80=98destroy the credibility of OAuth outside th= e > silly social networking circle=E2=80=99 (I=E2=80=99m paraphrasing but the > spirit of the comments is accurate) is just an overblown > reaction and scare tactic. What are you paraphrasing?=C2=A0 I think social networking is very important.=C2=A0 Furthermore, I think social login may very well become the default user authentication method of the Web.=C2=A0 So the security of social login is essential for the security of the Web at large. > Both options are legitimate and produce the same deployment > reality. They only differ in how the spec talks about > security and how implementers can talk about their > conformance. If they differ about how implementers can talk about their conformance then they do not produce the same deployment reality. Francisco =0A --0-1797915024-1301964371=:49458 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Eran,

> I don=E2=80=99t think your = statement that =E2=80=98the IETF should endorse
> lack of security=E2= =80=99 is accurate or helpful.

If the IETF endorsed a protocol such = that a compliant
implementation allows user impersonation and unauthoriz= ed
access to protected resource, then the IETF would be
endorsing lac= k of security.  How is that inaccurate?

The statement is helpfu= l from the point of view of the users
who would be the victims of the at= tacks.  You seem to be
concerned about companies and developers but= not about
users.

> I completely rejects the notion that a SHO= ULD with strong
> language explaining the risk is any less =E2=80=9Cs= ecure=E2=80=9D than a
> MUST.
>
> The only impact of usin= g a MUST vs. a SHOULD is that
> companies deploying it without requir= ing TLS on the
> redirection endpoint will not be able to claim full
> compliance if = we use a MUST, but will be able to if we use a
> SHOULD.
>
&= gt; RFC 2616 defines compliance as follows:
>
>  &nbs= p; An implementation is not compliant if it fails to satisfy one or more>    of the MUST or REQUIRED level requirements for the = protocols it
>    implements. An implementation that s= atisfies all the MUST or REQUIRED
>    level and all t= he SHOULD level requirements for its protocols is said
>  &= nbsp; to be "unconditionally compliant"; one that satisfies all the MUST>    level requirements but not all the SHOULD level req= uirements for its
>    protocols is said to be "condit= ionally compliant."
>
> If we used a SHOULD for TLS, and added = such a language, it
> will enable the definition of three classes of
> implementations: non-compliant, unconditionally complia= nt
> (your definition of secure), and conditionally compliant
>= (what Facebook, Yahoo, Google, and Kiva are likely to
> deploy).
=
Therefore we should use MUST, otherwise there can be
"conditionally = compliant" implementations that put users at
risk.

> But my po= int is that trying to paint the SHOULD option with
> strong security = guidance as =E2=80=98the IETF endorsing an insecure
> protocol=E2=80= =99 or =E2=80=98destroy the credibility of OAuth outside the
> silly = social networking circle=E2=80=99 (I=E2=80=99m paraphrasing but the
>= spirit of the comments is accurate) is just an overblown
> reaction = and scare tactic.

What are you paraphrasing?  I think social ne= tworking is
very important.  Furthermore, I think social login may = very
well become the default user authentication method of the
Web.&n= bsp; So the security of social login is essential for the
security of the Web at large.

= > Both options are legitimate and produce the same deployment
> re= ality. They only differ in how the spec talks about
> security and ho= w implementers can talk about their
> conformance.

If they dif= fer about how implementers can talk about their
conformance then they do= not produce the same deployment
reality.

Francisco


= =0A
--0-1797915024-1301964371=:49458-- From fcorella@pomcor.com Mon Apr 4 17:46:07 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3763A6816 for ; Mon, 4 Apr 2011 17:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5B-nUJXsrbao for ; Mon, 4 Apr 2011 17:46:06 -0700 (PDT) Received: from web55806.mail.re3.yahoo.com (web55806.mail.re3.yahoo.com [216.252.110.52]) by core3.amsl.com (Postfix) with SMTP id 787453A680E for ; Mon, 4 Apr 2011 17:46:06 -0700 (PDT) Received: (qmail 36435 invoked by uid 60001); 5 Apr 2011 00:47:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301964465; bh=FR17HFrTCU0Gp5VA6eJStHRDk1t6R9rETOWtwN7kvck=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=D4fW7k0pe5COR0OYgfLI8gvunf3TmAIcH0jR4r947vMIyQegHAHvBrdtQGlLO4O08oEczNkhA7+mhMrnIZhzHNdz1mazi+NhpfcFN8TWhBSw9WxpH26uPhOovxV6zyWGLSqgpX0GfKakh5dOzH4bsK+VvVHFYGqbCzsYSVL8NBw= Message-ID: <567186.33115.qm@web55806.mail.re3.yahoo.com> X-YMail-OSG: mcdl7osVM1kNSk44hhQQcSR1ce8aH9B8d7nAXqb_7z.nCeU aYi9pQ_BDWvwtV0EqhZylN4swKfBVXvIwnfXAQSjM5fLqbRn4aL0VxosaWGC znUGgYjHzaA7BcM4YYqSn_kdtrAo2KT7r9ndF0INDguUSjbps74kccoS7GGW rCYU8.VxVkJhPLdx.fmp1PxKsbOqGRiNYtbsLd8Y6uPexyP05Jm1krxrchwL nDQ1qH1OG2GD.4oZVXhHbLtZ7uZdEjwc3XJKUMEiGKefTBUZR7RgMEAHglV8 fRGacGqm8DZzf94u6JltMmkHDmFlehyW60bvGcNnUV0nEfguP_QWT0w4oBhy 69.FLSG0Et6TUfZ_ufgEXZxClEaai6Bl_T4p1CcZnsEdk9CjIezd0MKJBE5N LqrvI Received: from [174.65.103.16] by web55806.mail.re3.yahoo.com via HTTP; Mon, 04 Apr 2011 17:47:45 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Mon, 4 Apr 2011 17:47:45 -0700 (PDT) From: Francisco Corella To: Dick Hardt , Skylar Woodward , Phillip Hunt , Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664D9B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1569148468-1301964465=:33115" Cc: OAuth WG , "Karen P. Lewison" Subject: Re: [OAUTH-WG] to TLS or not on redirect on consumer websites :: security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 00:46:07 -0000 --0-1569148468-1301964465=:33115 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Eran, > The only consequence is compromising the *client* > login/authentication security. I'm not trying to play it > down, but I we need to be clear. This is not a compromise of > the protected resources or authorization server. We are definitely talking about a compromise of the protected resources.=A0 The attacker can access the protected resources through the client.=A0 And George Fletcher described an attack variant where the attacker does that without logging in as the user. Francisco --0-1569148468-1301964465=:33115 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Eran,

> Th= e only consequence is compromising the *client*
> login/authenticatio= n security. I'm not trying to play it
> down, but I we need to be cle= ar. This is not a compromise of
> the protected resources or authoriz= ation server.

We are definitely talking about a compromise of theprotected resources.  The attacker can access the protected
resour= ces through the client.  And George Fletcher described
an attack va= riant where the attacker does that without
logging in as the user.
Francisco

--0-1569148468-1301964465=:33115-- From fcorella@pomcor.com Mon Apr 4 17:48:12 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892343A680E for ; Mon, 4 Apr 2011 17:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3dvlVWjDktv for ; Mon, 4 Apr 2011 17:48:11 -0700 (PDT) Received: from web55803.mail.re3.yahoo.com (web55803.mail.re3.yahoo.com [216.252.110.49]) by core3.amsl.com (Postfix) with SMTP id 72BEB3A6816 for ; Mon, 4 Apr 2011 17:48:11 -0700 (PDT) Received: (qmail 41071 invoked by uid 60001); 5 Apr 2011 00:49:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301964594; bh=gAKHJI3k/MLEZPCBDYykHj0xch7lH7vBBXMY6TyROFY=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iVsnQALoaLoeOZAgSWofNJAia1AewQwzciqFyyUDmG7QyOn7M3agoiLJFic8xtPPMAmcXXTIJGfBx6X1AfjMBsadSDBm8Wb+P1lNc1Uh4VEpqtCN5poy3P7MHxRUy9eq0Jo8VR4cdyZiHct1jGMZxrd/l+HlP99W2uOkkmQhHwE= Message-ID: <166941.40844.qm@web55803.mail.re3.yahoo.com> X-YMail-OSG: bu20j4MVM1kTkTgoZ3EFPcNNBfFB9QD_hR2E92IMOnAIw0g XbrkWA0.UVM8palot2nOGzKCNYFUHbkqUv6n2Kl5twMtH4U_E.ZtRwwks.Pf d2kSTTUJVN9c0Kb0W1N2wuyEwKkKWt2wmTrFV9MTChCDAqyP8XDrQJDhMoSn IEn6qH3.92AyuOH2IdDrdMPurTlrVZL4iyNb1yKB8.QcuHfJdO6SMW4z86Jt t.dL12YVNwlCfucSXp9H0Yum8Ni4cRLSuxFSB1lpxquBK06rMe2jjDJdZFrw Eq91hM.HrWH.TB_4oanVjhs_uI.kTNMOfdiZgWf6T0NSCthbnFINpns3Nz7w 8uV1NI3oJTSqA.xv.Kfx6rnpEyJpawOiKAx5eXerXcDjBKBLDslbPka2KtRN _3rZE Received: from [174.65.103.16] by web55803.mail.re3.yahoo.com via HTTP; Mon, 04 Apr 2011 17:49:54 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Mon, 4 Apr 2011 17:49:54 -0700 (PDT) From: Francisco Corella To: Dick Hardt In-Reply-To: <90B7461C-848C-4DE5-94DF-8AB1781AA4DC@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-632828860-1301964594=:40844" Cc: "Karen P. Lewison" , OAuth WG Subject: Re: [OAUTH-WG] to TLS or not on redirect on consumer websites :: security considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 00:48:12 -0000 --0-632828860-1301964594=:40844 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dick, > Maybe you should stop using Twitter as anyone that can MITM your > session can tweet as you since Twitter does not enforce HTTPS on > twitter.com Thanks for pointing that out.=A0 I haven't looked at the security posture of Twitter, I just mentioned Twitter because Eran did.=A0 The point I was trying to make is that unauthorized write access to protected resources (e.g. sending tweets or updates) can do as much damage as unauthorized read access. Francisco --0-632828860-1301964594=:40844 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Dick,

> Maybe you should stop using= Twitter as anyone that can MITM your
> session can tweet as you sinc= e Twitter does not enforce HTTPS on
> twitter.com

Thanks for p= ointing that out.  I haven't looked at the security
posture of Twit= ter, I just mentioned Twitter because Eran did.  The
point I was tr= ying to make is that unauthorized write access to
protected resources (e= .g. sending tweets or updates) can do as much
damage as unauthorized rea= d access.

Francisco

--0-632828860-1301964594=:40844-- From skylar@kiva.org Mon Apr 4 18:38:14 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0C33A683B for ; Mon, 4 Apr 2011 18:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 692rfPCNLyWo for ; Mon, 4 Apr 2011 18:38:11 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by core3.amsl.com (Postfix) with SMTP id F33323A6840 for ; Mon, 4 Apr 2011 18:38:10 -0700 (PDT) Received: from mail-gx0-f182.google.com ([209.85.161.182]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKTZpy6XbmWEh3fYlK0yw8EhCVhdItHtiz@postini.com; Mon, 04 Apr 2011 18:39:54 PDT Received: by mail-gx0-f182.google.com with SMTP id 28so3182717gxk.41 for ; Mon, 04 Apr 2011 18:39:53 -0700 (PDT) Received: by 10.150.165.12 with SMTP id n12mr8496778ybe.16.1301967592869; Mon, 04 Apr 2011 18:39:52 -0700 (PDT) Received: from [192.168.2.8] (74-128-24-154.dhcp.insightbb.com [74.128.24.154]) by mx.google.com with ESMTPS id p41sm1824015ybk.14.2011.04.04.18.39.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 18:39:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <4A384831-10D3-4305-98ED-C189761E6D32@oracle.com> Date: Mon, 4 Apr 2011 21:39:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> <2BDF838F-C5CE-43C3-B017-91D967ECDAC0@kiva.org> <4A384831-10D3-4305-98ED-C189761E6D32@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1084) Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 01:38:14 -0000 On Apr 4, 2011, at 4:06 PM, Phil Hunt wrote: > For the moment, I'm only talking about mobile clients. >=20 > Very quickly here is the attack... > 1) Paul starts dance at good Client & good AS, App requests = authorization. Note: outbound call is secure, but returned redirect is = not. I'm going to re-iterate Brian's point that this is not an interesting = attack because we have no problem with securing a response to the = outbound call. Just to be very clear that we're all speaking about the = same thing here I'm detailing what you are implying in step one = (assuming pop-out to external browser as you mentioned earlier in this = thread): - Paul's mobile device (MD), running native client C, makes request to = the mobile browser (MB) on the same device for the OAuth authorization = page for provider P. - The MB makes an outbound request over TLS to P's outh/authorization = endpoint. (HTTPS) - P responds over the same socket with the approval (and or login = pages). (still HTTPS) - Paul clicks the Approval button on the provider authorization page = which initiates MB to make a new HTTPS call confirming the approval. - MB responds on the same secure socket (HTTPS!) with the composed = redirect URI including auth code. Note here that the redirect URI uses = a custom protocol since the authorization is happening in an external = browser (not embedded in the client). This looks like something = x-application-myapp://oauth-callback?code=3Dsecret - MB handles the redirect URI by opening the native client C, passing it = the redirect URI from the previous step. This is a secure transfer of = data between two apps on MD. This is the only flow on the table for a native mobile app using auth = codes and an external browser. All exchanges between clients (C and MB) = and server are over TLS. There is no MITM or sniffing exploit for this = flow. For an embedded browser flow, the flow is similarly secure as Brian took = care to describe. The redirect URI might be an URN, a custom URI, or an = HTTPS url. For an intercept to happen as you've outlined in step 2, MB or native = client C must make a **new** network connection to some = yet-to-be-identified server. To me, it seems beyond obvious that the = redirect response from the provider's authorization server would be = secured over the same socket that started the authorization. If the = authorization server redirects to itself using an HTTP url which then = responds with the redirect URI, that is a poorly implemented = authorization server and would be non-complient according to the spec. = That's sloppy coding, not a sloppy spec. So, this leaves us no identified security compromise for the native = mobile client, thus no need for further measures to secure this flow. Whew. > 2) Evil Brian intercepts the (HTTP) redirect containing Paul's authz = code > 3) Brian takes Paul's redirect #2 and enters it in his browser (e.g. = by script) > 4) Brian's browser processes redirect URI from #3 and passes to = Brian's copy of client (e.g. downloaded from app store). > 5) Brian's client exchanges substituted authz code for access token > 6) Brian's client now accesses service using Paul's authorization >=20 > As was explained earlier this attack is minimized by things like token = invalidation when the second client comes along, but we still have a = horserace and possibility of DoS for the user at minimum. >=20 > The server cannot mitigate this unless it can either ensure the client = is the only one that could have received the code, or can somehow = uniquely identify the client so that a copy cannot masquerade as the = original requestor. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-04-04, at 12:52 PM, Skylar Woodward wrote: >=20 >> I'm confused - it seems like you're mixing web clients and native = clients in this most recent explanation. It's perfectly reasonable that = the authorization code will always be returned by a provider in a secure = TLS channel to the web browser or native client which started the = authorization request. What's not reasonable is, in the case of the = code returned to a web browser (acting on behalf of a web client), for = the browser to then pass the code on to the web client over TLS. >>=20 >> Maybe you can elaborate the attack you are considering by listing = each network request/response between the mobile client and any servers? >>=20 >> I'll repeat again that the attack I've seen described thus far = doesn't apply to mobile apps with( or without) many copies because there = is no local redirect involved. (The redirect URI is merely an identifier = that says "here's the code!" - it need not be a network location, and if = it is, it's just a local location on the same device - eg, another app = running on the same device). >>=20 >> skylar >>=20 >> On Apr 4, 2011, at 3:38 PM, Phil Hunt wrote: >>=20 >>> If you run a scanner, you will see that many of the current draft = implementations pass the authorization code by redirect without SSL. = I've seen several implementations where the authorization code is easy = to scan. >>>=20 >>> I suspect this occurs because the HTTP response isn't directly in = response to the original outgoing authorization. When I run the scanner, = the resource provider is performing a workflow with the user that = accomplishes form based authentication and authorization with the user, = some of which is not on SSL. What happens is the redirect is then not = sent by SSL. It seems like only a natural consequence of typical = authentication/authorization workflows. Or at best, it is difficult the = guarantee that the authorization code will always be returned in a = secure TLS channel. >>>=20 >>> Several people stated that the redirect end-point cannot implement = server-side security (called local redirect) and I think their request = is reasonable as it would require each client to have its own server = certificate. That *might* be acceptable to most web apps, but likely = won't work for apps with many many copies like mobile apps. >>>=20 >>> So, I'm making the assumption that if we can minimally count on = outbound TLS security, the transaction id would suffice to allow the = token service to connect the originating authorization client with the = client requesting an access token. >>>=20 >>> Phil >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2011-04-04, at 12:28 PM, Skylar Woodward wrote: >>>=20 >>>> But mobile clients aren't vulnerable to this type of attack because = all of their code is contained on the device and they make all outgoing = requests to the provider via SSL. There are no redirects to insecure = remote endpoints. A mobile device incapable of making outgoing SSL = requests would not be able to run an OAuth-compliant client as the spec = is currently written. >>>>=20 >>>> Where in this example is the un-encrypted exchange you are trying = to protect? >>>>=20 >>>>=20 >>>> On Apr 4, 2011, at 3:12 PM, Phil Hunt wrote: >>>>=20 >>>>> I was referring to a mobile client that passes the request via an = external browser. That browser is capable of running SSL with server = authentication only. >>>>>=20 >>>>> Phil >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2011-04-04, at 12:08 PM, Skylar Woodward wrote: >>>>>=20 >>>>>> Maybe you can explain your example in more detail then? I'm = assuming your "client app" is a web application hosted on web server = supporting only HTTP. >>>>>>=20 >>>>>> How does the nonce or request_id get to the provider as part of = the authorization request in your example? (step 1) >>>>>>=20 >>>>>>=20 >>>>>> On Apr 4, 2011, at 3:03 PM, Phillip Hunt wrote: >>>>>>=20 >>>>>>> It doesn't require client side ssl.=20 >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> Sent from my phone.=20 >>>>>>>=20 >>>>>>> On 2011-04-04, at 11:47, Skylar Woodward = wrote: >>>>>>>=20 >>>>>>>> How does the client app transmit the nonce (random number) to = the web browser for redirect to the provider? If the client app does not = support HTTPS, it can't set up a secure session on its own to give the = browser/user something to pass on during the provider authorization. >>>>>>>>=20 >>>>>>>> To me, this is nothing different that a unique value of "state" = which robust clients will already use to differentiate request flows. = Such a state variable would be exposed both on its way and back of the = provider's redirect. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> In any case, I see HTTPS as the simple solution here. I = question if it is in the scope of OAuth to provide a mechanism to the = community to protect against such MITM attacks between a hosted web = application and the web browser. If the nature of the data requires = such protection, the app developer (or the provider) can work to provide = such security outside of HTTPS. In the right context, tunneling = customer traffic through a provider-provided VPN could be considered a = reasonable protection for the cases folks have outlined. It just = doesn't seem like a popular need at this point, and there seem to be no = easy wins for hosted clients unable to register with a certificate = authority. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote: >>>>>>>>=20 >>>>>>>>> I have been wondering if we can combine a couple of things = such as a client generated transaction secret and use limited TLS to = achieve a fix. Note: this would address a hacker sniffing a returned = authorization code, but it probably does little for the MITM scenario = that was also outlined. >>>>>>>>>=20 >>>>>>>>> 1. The client app generate a random number or sequence of = characters, lets call it "request_id", then that value would be included = and securely (using TLS) transmitted in the authorization request. >>>>>>>>> 2. The authorization server does its usual thing and returns, = preferably securely but not necessarily, the authorization code to the = client app. >>>>>>>>> 3. Upon requesting an access_token, the client app also = includes the same request_id in its secure request to the token = endpoint. >>>>>>>>> 4. The token server verifies that the "request_id" matches the = request_id supplied in the authorize request (in addition to all the = other processing). >>>>>>>>>=20 >>>>>>>>> Since both requests are sent securely a sniffing client cannot = obtain the client request_id even though it might be able to obtain the = authorization code being returned. >>>>>>>>>=20 >>>>>>>>> What this might allow is that the client can transmit a secret = protected by TLS in its outbound request, but can accept non-secure = delivery of the authorization code. The token server then has a means = to verify that the client exchanging the authorization code is the same = one that made the initial request. >>>>>>>>>=20 >>>>>>>>> This is off the top of my head, I am sure the proposal is = likely not yet a complete solution, but maybe someone can build on that. >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>> phil.hunt@oracle.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2011-04-04, at 10:52 AM, Oleg Gryb wrote: >>>>>>>>>=20 >>>>>>>>>> After looking into exiting (and working) implementations of = OAuth 1.0 in mobile world I have strong doubts about possibility of = implementing what was suggested in option #3.=20 >>>>>>>>>>=20 >>>>>>>>>> In my view, two conditions are needed to achieve that: >>>>>>>>>>=20 >>>>>>>>>> 1. Something unique stored on a mobile client. >>>>>>>>>> 2. That something should be a secret, so other (malicious) = clients could not reuse it. >>>>>>>>>>=20 >>>>>>>>>> Distribution of that "unique secrets" should be automated in = the mobile world and is usually included to mobile application=20 >>>>>>>>>> activation process, but that activation process can't make = conditions 1 & 2 above met in full, becuase: >>>>>>>>>>=20 >>>>>>>>>> 1. As soon as secrets are distributed to a mobile device they = are not quite secret any more >>>>>>>>>> 2. As soon as the secret becomes known, a simulator or other = mobile device can be used to spoof the traffic >>>>>>>>>>=20 >>>>>>>>>> I would consider option #3 as an illusion until somebody = comes up with a solution that would address the described issues. >>>>>>>>>>=20 >>>>>>>>>> BTW, the draft of "OAuth Dynamic Client Registration = Protocol" (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has = expired on Feb. 12 and I didn't see any attempts to re-vitalise it. I = think it would be better and more beneficial for the community to return = to this protocol rather than inventing a new method of "mutual = authentication".=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> From: Phil Hunt >>>>>>>>>> To: Prateek Mishra >>>>>>>>>> Cc: OAuth WG >>>>>>>>>> Sent: Mon, April 4, 2011 9:52:17 AM >>>>>>>>>> Subject: Re: [OAUTH-WG] Authorization code security issue = (reframed) >>>>>>>>>>=20 >>>>>>>>>> Apologies for the long message (again). I have attempted to = sum things up and bring out the issue without using any existing service = or party as an example of problems. It seems some have taken offence to = my previous message pushing for a solution. As a result it was not = productive. I apologize. Hopefully this message sticks to the issue of = developing an appropriate counter measure to threats as that is my only = intent. >>>>>>>>>>=20 >>>>>>>>>> As Prateek clarified in the previous message to Francisco, = SAML also uses SHOULD, but artifact security is achieved by an = additional counter-measure... >>>>>>>>>>> The identity provider MUST ensure that only the service = provider to whom the message has >>>>>>>>>>> been issued is given the message as the result of an = request. >>>>>>>>>>=20 >>>>>>>>>> Yet, in OAuth the client app is not unique for a particular = set of client credentials we currently have no way to verify that the = correct client got the code. This has been the mechanism that the = community has been assuming solves the problem. Client credentials do = not always work to protect the authorization code because in OAuth you = can have many many clients with the same credential. For example = everyone with the same mobile app likely has the same client credential. = Thus a copy of a valid client app which is easy to obtain becomes the = hacker's attack vector. So, the client credential is not an effective = counter in this case. >>>>>>>>>>=20 >>>>>>>>>> Several have commented that there are other supplementary = techniques for protection, but in my view, most of them work indirectly = and/or depend on correct collective configuration of several components. = Some of these are: tokens may be used one time; tokens are invalidated = if used a second time, tokens are sufficiently unique, etc. All of = these will help. But none are designed to directly counter the attack. = In fact the best one - token invalidation carries the additional problem = of unreliable service for the legitimate client. The hacker can deny = service to anyone in the room simply by re-using any tokens seen. >>>>>>>>>>=20 >>>>>>>>>> =46rom my perspective, the "easy" solution was to increase = the requirements on TLS from SHOULD to MUST to prevent eavesdropping of = the code. This was echoed by several others. I agree this will not work = for everyone. Many have made strong arguments for why they can't use it. = But without a MUST we are still missing a direct counter to the threat. >>>>>>>>>>=20 >>>>>>>>>> I don't want to change things at this late date, but maybe = this means introducing some form of mutual authentication -- some way = for the requesting client "instance" to prove that they are the copy = eligible to use an authorization code.=20 >>>>>>>>>>=20 >>>>>>>>>> To end this discussion, I propose we vote on the proposal = from Eran plus one new option... >>>>>>>>>> 1. Include a normative MUST use TLS for the client = redirection URI endpoint. >>>>>>>>>> 2. Include a normative SHOULD use TLS for the client = redirection URI endpoint with strong language explaining the various = attacks possible if the endpoint is not made secure. >>>>>>>>>> 3. Keep current language of SHOULD, but develop a direct = counter-measure to token theft such as specific client instance = identification or mutual authentication. >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: >>>>>>>>>>=20 >>>>>>>>>>> Francisco, >>>>>>>>>>>=20 >>>>>>>>>>> You are right, I was in error to suggest that it was a MUST. >>>>>>>>>>>=20 >>>>>>>>>>> I think my main concern was that security considerations = should not be based on polling developers/deployers of an existing or = legacy protocol. >>>>>>>>>>>=20 >>>>>>>>>>> SAML does include some additional countermeasures though - = for example (lines 595-596, profiles document) - that specifically deal = with the >>>>>>>>>>> artifact being leaked -=20 >>>>>>>>>>>=20 >>>>>>>>>>> [quote] >>>>>>>>>>> The identity provider MUST ensure that only the service = provider to whom the message has >>>>>>>>>>> been issued is given the message as the result of an = request. >>>>>>>>>>> [\quote] >>>>>>>>>>>=20 >>>>>>>>>>> - prateek >>>>>>>>>>>> Hi Prateek, >>>>>>>>>>>>=20 >>>>>>>>>>>>> I would like to strongly disagree with this proposal. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> It amounts to explicitly making OAuth 2.0 insecure so as = to >>>>>>>>>>>>> satisfy some mysterious and unspecified set of legacy = OAuth >>>>>>>>>>>>> 1.0 deployments. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The SAML web SSO (artifact) profile - which shares many >>>>>>>>>>>>> characteristics with the initial steps in OAuth - requires >>>>>>>>>>>>> precisely such a counter-measure and is widely implemented >>>>>>>>>>>>> in 1000s of deployments. >>>>>>>>>>>>=20 >>>>>>>>>>>> What counter-measure is this? Can you provide a reference? >>>>>>>>>>>> Section 4.1.3.5 of=20 >>>>>>>>>>>> = http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>>>>>>>>>>> recommends TLS but does not require it. >>>>>>>>>>>>=20 >>>>>>>>>>>> Francisco >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From eran@hueniverse.com Mon Apr 4 19:23:20 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856EF3A682E for ; Mon, 4 Apr 2011 19:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAjhRO3+1sy6 for ; Mon, 4 Apr 2011 19:23:11 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0CAE83A6840 for ; Mon, 4 Apr 2011 19:23:10 -0700 (PDT) Received: (qmail 30856 invoked from network); 5 Apr 2011 02:24:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 Apr 2011 02:24:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 4 Apr 2011 19:24:48 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 4 Apr 2011 19:24:44 -0700 Thread-Topic: [OAUTH-WG] Authorization code security issue (reframed) Thread-Index: AcvzKVq7qsrLbkfERm2RAU/NIeYohAABjDBA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DCB3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <887780.25851.qm@web55801.mail.re3.yahoo.com> In-Reply-To: <887780.25851.qm@web55801.mail.re3.yahoo.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_90C41DD21FB7C64BB94121FBBC2E7234465664DCB3P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 02:23:20 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DCB3P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Speaking from current, on-going, firsthand experience building an OAuth 2.0= server and client. Your questions about deploying TLS are the least significant when it comes = to deploying a TLS-based client. I know these are the standard argument peo= ple make when defending a requirement to use TLS, but in practice they are = almost meaningless. The problem is that no modern web application is built and deployed using a= single provider or served from a single server (or servers controlled by a= single entity). Take every popular blog for example, and you'll find at le= ast 5 add-ons hosted by other services and loaded by the client: an analyti= cs tool, one or more ad networks, some site navigation components, hosted c= omments, and on and on. If *any* of these scripts loaded by the client at any time during an authen= ticated session are not using TLS, not only will the browser show some scar= y UX warning about incomplete HTTPS state, but also , a MITM will be able, = with the exact same ease, to hijack the session just like the attack raised= here. If the client is a JS-based OAuth client, add to that stealing the i= n-memory access token. TLS performance sucks! No, I'm not talking about the technology - I'm talking about the kind deplo= yed widely on the web. There are no widely available CDNs for TLS at the sa= me price and performance as are for HTTP. It is still hard-to-impossible to= find high-performance free TLS hosts for most popular JS toolkits like JQu= ery and YUI. Loading these (big) script packages from the TLS servers avail= able is simply too slow to be used in any practical web application. Ads ar= e another major issue. I've spent the past three months building an OAuth 2.0 client. I've gone th= rough the same analysis and realized that I had to use TLS end-to-end in or= der to protect the MAC secret issued to the client with its access token. T= his has caused significant pains as we had to figure out solutions for ever= y third party service or script we use. We had to give up on using the anal= ytics package we wanted because they didn't have a fast enough solution for= TLS-based pages (it works great for content sites where there isn't a lot = of fast interaction or reliance on 'onload' activity). I can go on for hours. This has been an awful experience, and not for a min= ute because of paying $100 for a cert or installing it in nginx. That took = less than an hour. I'm tired of having argument with people quoting theories. I work in the re= al world, and the real world is just not ready for end-to-end TLS deploymen= t. Maybe it's sad, but that's life. No one wants to put user's at risk, but= the only way to prevent it is to shut the web down. This debate is just like talking about highway safety. We know how to make = driving 100% safe. Everyone will drive tanks at no faster than 10mph, or al= ternatively, no one will drive and we'll all climb on converter belts to ge= t anywhere (each bubble wrapped and put into a medically induced coma to ma= ke sure we don't move around). But in the real world, practical considerati= ons trump 100% guarantees. By just offering services online you put users at some risk. If you want 10= 0% safe online banking, just don't offer any. We must do better, and we should push security as hard as we can. But if yo= u push beyond what is currently reasonable, you will get nowhere and maybe = even do more harm. Facebook, Google, Yahoo, Kiva, etc. can easily force our= developers to use TLS for the redirection endpoint. And the developers who= really want to use our services will figure out how to deploy TLS and get = it working. But as soon as these developers try to use other services not r= eady for end-to-end TLS, they result will be poor user experience. In other words, no one will use those clients - they will suck. It will be the safest web no one ever uses. Awesome! EHL From: Francisco Corella [mailto:fcorella@pomcor.com] Sent: Monday, April 04, 2011 5:35 PM To: Eran Hammer-Lahav; Skylar Woodward; Phil Hunt; Oleg Gryb; David Recordo= n Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) David, > If this is changed to a MUST, Facebook will be in violation of the > specification moving forward. It is untenable to require all of our > *client* developers to implement TLS endpoints though we certainly > support developers who wish to do so. This is very different than > offerring our entire API (and now site as opt-in) over TLS as the > server. Why is it untenable? Is it because of the cost of a certificate? Many CAs offer certifcates for less $100, and there are free certificates. See http://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_servers= . Is it because of the cost of hosting an SSL site? You can have your own virtual server at Amazon for $14 a month. Is it because of the inconvenience of having to spend a few hours getting a certificate and adding SSL to your site? And how about putting your users and your data at risk? Is that tenable? Francisco --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DCB3P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<one l= ong rant adding no value to this conversation>

 

Speaking from current, on-going, firsthand experience building an OAut= h 2.0 server and client.

<= o:p> 

Your questions about= deploying TLS are the least significant when it comes to deploying a TLS-b= ased client. I know these are the standard argument people make when defend= ing a requirement to use TLS, but in practice they are almost meaningless.<= o:p>

 

The problem is that no modern web application= is built and deployed using a single provider or served from a single serv= er (or servers controlled by a single entity). Take every popular blog for = example, and you’ll find at least 5 add-ons hosted by other services = and loaded by the client: an analytics tool, one or more ad networks, some = site navigation components, hosted comments, and on and on.

 

If *any* of these scripts loaded by the client at any= time during an authenticated session are not using TLS, not only will the = browser show some scary UX warning about incomplete HTTPS state, but also ,= a MITM will be able, with the exact same ease, to hijack the session just = like the attack raised here. If the client is a JS-based OAuth client, add = to that stealing the in-memory access token.

 

TLS performance sucks!

 

No, I’m not tal= king about the technology – I’m talking about the kind deployed= widely on the web. There are no widely available CDNs for TLS at the same = price and performance as are for HTTP. It is still hard-to-impossible to fi= nd high-performance free TLS hosts for most popular JS toolkits like JQuery= and YUI. Loading these (big) script packages from the TLS servers availabl= e is simply too slow to be used in any practical web application. Ads are a= nother major issue.

 

I’ve spent the pa= st three months building an OAuth 2.0 client. I’ve gone through the s= ame analysis and realized that I had to use TLS end-to-end in order to prot= ect the MAC secret issued to the client with its access token. This has cau= sed significant pains as we had to figure out solutions for every third par= ty service or script we use. We had to give up on using the analytics packa= ge we wanted because they didn’t have a fast enough solution for TLS-= based pages (it works great for content sites where there isn’t a lot= of fast interaction or reliance on ‘onload’ activity).

 

I can go on for hours. This has been an awful experi= ence, and not for a minute because of paying $100 for a cert or installing = it in nginx. That took less than an hour.

 

I&#= 8217;m tired of having argument with people quoting theories. I work in the= real world, and the real world is just not ready for end-to-end TLS deploy= ment. Maybe it’s sad, but that’s life. No one wants to put user= ’s at risk, but the only way to prevent it is to shut the web down.

 

This debate is just like talking about highway= safety. We know how to make driving 100% safe. Everyone will drive tanks a= t no faster than 10mph, or alternatively, no one will drive and we’ll= all climb on converter belts to get anywhere (each bubble wrapped and put = into a medically induced coma to make sure we don’t move around). But= in the real world, practical considerations trump 100% guarantees.

 

By just offering services online you put users at so= me risk. If you want 100% safe online banking, just don’t offer any.<= o:p>

 

We must do better, and we should push securit= y as hard as we can. But if you push beyond what is currently reasonable, y= ou will get nowhere and maybe even do more harm. Facebook, Google, Yahoo, K= iva, etc. can easily force our developers to use TLS for the redirection en= dpoint. And the developers who really want to use our services will figure = out how to deploy TLS and get it working. But as soon as these developers t= ry to use other services not ready for end-to-end TLS, they result will be = poor user experience.

 

In other words, no one = will use those clients – they will suck.

 

It will be the safest web no one ever uses.

 

Awesome!

 

EHL

 

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = Francisco Corella [mailto:fcorella@pomcor.com]
Sent: Monday, Apr= il 04, 2011 5:35 PM
To: Eran Hammer-Lahav; Skylar Woodward; Phil = Hunt; Oleg Gryb; David Recordon
Cc: OAuth WG
Subject: R= e: [OAUTH-WG] Authorization code security issue (reframed)

 

David,

> If this is changed to a MUST, Facebook wil= l be in violation of the
> specification moving forward. It is untena= ble to require all of our
> *client* developers to implement TLS endp= oints though we certainly
> support developers who wish to do so. Thi= s is very different than
> offerring our entire API (and now site as = opt-in) over TLS as the
> server.

Why is it untenable?  I= s it because of the cost of a
certificate?  Many CAs offer certifca= tes for less $100, and
there are free certificates.  See
http://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_s= ervers.
Is it because of the cost of hosting an SSL site?  You = can
have your own virtual server at Amazon for $14 a month.  Is
= it because of the inconvenience of having to spend a few
hours getting a= certificate and adding SSL to your site?

And how about putting your= users and your data at risk?  Is
that tenable?

Francisco

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DCB3P3PW5EX1MB01E_-- From phil.hunt@oracle.com Mon Apr 4 20:28:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327F43A683C for ; Mon, 4 Apr 2011 20:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.843 X-Spam-Level: X-Spam-Status: No, score=-5.843 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-rijeWxV8dV for ; Mon, 4 Apr 2011 20:28:53 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 08A333A6863 for ; Mon, 4 Apr 2011 20:28:51 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p353UV9a014234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2011 03:30:33 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p353UVNg027329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 03:30:31 GMT Received: from abhmt010.oracle.com (abhmt010.oracle.com [141.146.116.19]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p353UUEj028966; Mon, 4 Apr 2011 22:30:30 -0500 Received: from [192.168.1.136] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2011 20:30:30 -0700 References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> <2BDF838F-C5CE-43C3-B017-91D967ECDAC0@kiva.org> <4A384831-10D3-4305-98ED-C189761E6D32@oracle.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8G4) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8G4) From: Phillip Hunt Date: Mon, 4 Apr 2011 20:30:24 -0700 To: Skylar Woodward X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4D9A8CD7.00BA:SCFSTAT5015188,ss=1,fgs=0 Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 03:28:56 -0000 Phil Sent from my phone.=20 On 2011-04-04, at 18:39, Skylar Woodward wrote: > On Apr 4, 2011, at 4:06 PM, Phil Hunt wrote: >=20 >> For the moment, I'm only talking about mobile clients. >>=20 >> Very quickly here is the attack... >> 1) Paul starts dance at good Client & good AS, App requests authorizatio= n. Note: outbound call is secure, but returned redirect is not. >=20 > I'm going to re-iterate Brian's point that this is not an interesting atta= ck because we have no problem with securing a response to the outbound call.= Just to be very clear that we're all speaking about the same thing here I'm= detailing what you are implying in step one (assuming pop-out to external b= rowser as you mentioned earlier in this thread): >=20 > - Paul's mobile device (MD), running native client C, makes request to the= mobile browser (MB) on the same device for the OAuth authorization page for= provider P. > - The MB makes an outbound request over TLS to P's outh/authorization endp= oint. (HTTPS) > - P responds over the same socket with the approval (and or login pages). (= still HTTPS) Not guaranteed by spec nor in practice.=20 > - Paul clicks the Approval button on the provider authorization page which= initiates MB to make a new HTTPS call confirming the approval. Again not in practice.=20 > - MB responds on the same secure socket (HTTPS!) with the composed redirec= t URI including auth code. Note here that the redirect URI uses a custom pr= otocol since the authorization is happening in an external browser (not embe= dded in the client). This looks like something x-application-myapp://oauth-= callback?code=3Dsecret My scanner is showing this is not happening. Moreover the spec only says it i= s a SHOULD per the discussion.=20 This is the point that is often trivial to eavesdrop and easy to pass into B= rian's browser. The browser does the rest of the hack all by itself by follo= wing the link.=20 > - MB handles the redirect URI by opening the native client C, passing it t= he redirect URI from the previous step. This is a secure transfer of data be= tween two apps on MD. Agreed.=20 >=20 > This is the only flow on the table for a native mobile app using auth code= s and an external browser. All exchanges between clients (C and MB) and serv= er are over TLS. There is no MITM or sniffing exploit for this flow. >=20 Only true if TLS is on.=20 > For an embedded browser flow, the flow is similarly secure as Brian took c= are to describe. The redirect URI might be an URN, a custom URI, or an HTTP= S url. >=20 > For an intercept to happen as you've outlined in step 2, MB or native clie= nt C must make a **new** network connection to some yet-to-be- Remember the token request is a NEW endpoint.=20 > identified server. To me, it seems beyond obvious that the redirect respo= nse from the provider's authorization server would be secured over the same s= ocket that started the authorization. If the authorization server redirects t= o itself using an HTTP url which then responds with the redirect URI, that i= s a poorly implemented authorization server and would be non-complient accor= ding to the spec. That's sloppy coding, not a sloppy spec. I think you are over complicating. Look at the Facebook implementation (No o= ffense to Facebook) and watch with a scanner.=20 >=20 > So, this leaves us no identified security compromise for the native mobile= client, thus no need for further measures to secure this flow. >=20 > Whew. Well the hack works just fine for me. I really wish you were correct. :) >=20 >=20 >> 2) Evil Brian intercepts the (HTTP) redirect containing Paul's authz code= >> 3) Brian takes Paul's redirect #2 and enters it in his browser (e.g. by s= cript) >> 4) Brian's browser processes redirect URI from #3 and passes to Brian's c= opy of client (e.g. downloaded from app store). >> 5) Brian's client exchanges substituted authz code for access token >> 6) Brian's client now accesses service using Paul's authorization >>=20 >> As was explained earlier this attack is minimized by things like token in= validation when the second client comes along, but we still have a horserace= and possibility of DoS for the user at minimum. >>=20 >> The server cannot mitigate this unless it can either ensure the client is= the only one that could have received the code, or can somehow uniquely ide= ntify the client so that a copy cannot masquerade as the original requestor.= >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-04-04, at 12:52 PM, Skylar Woodward wrote: >>=20 >>> I'm confused - it seems like you're mixing web clients and native client= s in this most recent explanation. It's perfectly reasonable that the autho= rization code will always be returned by a provider in a secure TLS channel t= o the web browser or native client which started the authorization request. = What's not reasonable is, in the case of the code returned to a web browser= (acting on behalf of a web client), for the browser to then pass the code o= n to the web client over TLS. >>>=20 >>> Maybe you can elaborate the attack you are considering by listing each n= etwork request/response between the mobile client and any servers? >>>=20 >>> I'll repeat again that the attack I've seen described thus far doesn't a= pply to mobile apps with( or without) many copies because there is no local r= edirect involved. (The redirect URI is merely an identifier that says "here'= s the code!" - it need not be a network location, and if it is, it's just a l= ocal location on the same device - eg, another app running on the same devic= e). >>>=20 >>> skylar >>>=20 >>> On Apr 4, 2011, at 3:38 PM, Phil Hunt wrote: >>>=20 >>>> If you run a scanner, you will see that many of the current draft imple= mentations pass the authorization code by redirect without SSL. I've seen se= veral implementations where the authorization code is easy to scan. >>>>=20 >>>> I suspect this occurs because the HTTP response isn't directly in respo= nse to the original outgoing authorization. When I run the scanner, the reso= urce provider is performing a workflow with the user that accomplishes form b= ased authentication and authorization with the user, some of which is not on= SSL. What happens is the redirect is then not sent by SSL. It seems like on= ly a natural consequence of typical authentication/authorization workflows. O= r at best, it is difficult the guarantee that the authorization code will al= ways be returned in a secure TLS channel. >>>>=20 >>>> Several people stated that the redirect end-point cannot implement serv= er-side security (called local redirect) and I think their request is reason= able as it would require each client to have its own server certificate. Tha= t *might* be acceptable to most web apps, but likely won't work for apps wit= h many many copies like mobile apps. >>>>=20 >>>> So, I'm making the assumption that if we can minimally count on outboun= d TLS security, the transaction id would suffice to allow the token service t= o connect the originating authorization client with the client requesting an= access token. >>>>=20 >>>> Phil >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2011-04-04, at 12:28 PM, Skylar Woodward wrote: >>>>=20 >>>>> But mobile clients aren't vulnerable to this type of attack because al= l of their code is contained on the device and they make all outgoing reques= ts to the provider via SSL. There are no redirects to insecure remote endpo= ints. A mobile device incapable of making outgoing SSL requests would not b= e able to run an OAuth-compliant client as the spec is currently written. >>>>>=20 >>>>> Where in this example is the un-encrypted exchange you are trying to p= rotect? >>>>>=20 >>>>>=20 >>>>> On Apr 4, 2011, at 3:12 PM, Phil Hunt wrote: >>>>>=20 >>>>>> I was referring to a mobile client that passes the request via an ext= ernal browser. That browser is capable of running SSL with server authentica= tion only. >>>>>>=20 >>>>>> Phil >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2011-04-04, at 12:08 PM, Skylar Woodward wrote: >>>>>>=20 >>>>>>> Maybe you can explain your example in more detail then? I'm assuming= your "client app" is a web application hosted on web server supporting only= HTTP. >>>>>>>=20 >>>>>>> How does the nonce or request_id get to the provider as part of the a= uthorization request in your example? (step 1) >>>>>>>=20 >>>>>>>=20 >>>>>>> On Apr 4, 2011, at 3:03 PM, Phillip Hunt wrote: >>>>>>>=20 >>>>>>>> It doesn't require client side ssl.=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> Sent from my phone.=20 >>>>>>>>=20 >>>>>>>> On 2011-04-04, at 11:47, Skylar Woodward wrote: >>>>>>>>=20 >>>>>>>>> How does the client app transmit the nonce (random number) to the w= eb browser for redirect to the provider? If the client app does not support H= TTPS, it can't set up a secure session on its own to give the browser/user s= omething to pass on during the provider authorization. >>>>>>>>>=20 >>>>>>>>> To me, this is nothing different that a unique value of "state" wh= ich robust clients will already use to differentiate request flows. Such a s= tate variable would be exposed both on its way and back of the provider's re= direct. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> In any case, I see HTTPS as the simple solution here. I question i= f it is in the scope of OAuth to provide a mechanism to the community to pro= tect against such MITM attacks between a hosted web application and the web b= rowser. If the nature of the data requires such protection, the app develop= er (or the provider) can work to provide such security outside of HTTPS. In= the right context, tunneling customer traffic through a provider-provided V= PN could be considered a reasonable protection for the cases folks have outl= ined. It just doesn't seem like a popular need at this point, and there see= m to be no easy wins for hosted clients unable to register with a certificat= e authority. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote: >>>>>>>>>=20 >>>>>>>>>> I have been wondering if we can combine a couple of things such a= s a client generated transaction secret and use limited TLS to achieve a fix= . Note: this would address a hacker sniffing a returned authorization code,= but it probably does little for the MITM scenario that was also outlined. >>>>>>>>>>=20 >>>>>>>>>> 1. The client app generate a random number or sequence of charact= ers, lets call it "request_id", then that value would be included and secure= ly (using TLS) transmitted in the authorization request. >>>>>>>>>> 2. The authorization server does its usual thing and returns, pre= ferably securely but not necessarily, the authorization code to the client a= pp. >>>>>>>>>> 3. Upon requesting an access_token, the client app also includes t= he same request_id in its secure request to the token endpoint. >>>>>>>>>> 4. The token server verifies that the "request_id" matches the re= quest_id supplied in the authorize request (in addition to all the other pro= cessing). >>>>>>>>>>=20 >>>>>>>>>> Since both requests are sent securely a sniffing client cannot ob= tain the client request_id even though it might be able to obtain the author= ization code being returned. >>>>>>>>>>=20 >>>>>>>>>> What this might allow is that the client can transmit a secret pr= otected by TLS in its outbound request, but can accept non-secure delivery o= f the authorization code. The token server then has a means to verify that t= he client exchanging the authorization code is the same one that made the in= itial request. >>>>>>>>>>=20 >>>>>>>>>> This is off the top of my head, I am sure the proposal is likely n= ot yet a complete solution, but maybe someone can build on that. >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2011-04-04, at 10:52 AM, Oleg Gryb wrote: >>>>>>>>>>=20 >>>>>>>>>>> After looking into exiting (and working) implementations of OAut= h 1.0 in mobile world I have strong doubts about possibility of implementing= what was suggested in option #3.=20 >>>>>>>>>>>=20 >>>>>>>>>>> In my view, two conditions are needed to achieve that: >>>>>>>>>>>=20 >>>>>>>>>>> 1. Something unique stored on a mobile client. >>>>>>>>>>> 2. That something should be a secret, so other (malicious) clien= ts could not reuse it. >>>>>>>>>>>=20 >>>>>>>>>>> Distribution of that "unique secrets" should be automated in the= mobile world and is usually included to mobile application=20 >>>>>>>>>>> activation process, but that activation process can't make condi= tions 1 & 2 above met in full, becuase: >>>>>>>>>>>=20 >>>>>>>>>>> 1. As soon as secrets are distributed to a mobile device they ar= e not quite secret any more >>>>>>>>>>> 2. As soon as the secret becomes known, a simulator or other mob= ile device can be used to spoof the traffic >>>>>>>>>>>=20 >>>>>>>>>>> I would consider option #3 as an illusion until somebody comes u= p with a solution that would address the described issues. >>>>>>>>>>>=20 >>>>>>>>>>> BTW, the draft of "OAuth Dynamic Client Registration Protocol" (= http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on Feb. 12= and I didn't see any attempts to re-vitalise it. I think it would be better= and more beneficial for the community to return to this protocol rather tha= n inventing a new method of "mutual authentication".=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> From: Phil Hunt >>>>>>>>>>> To: Prateek Mishra >>>>>>>>>>> Cc: OAuth WG >>>>>>>>>>> Sent: Mon, April 4, 2011 9:52:17 AM >>>>>>>>>>> Subject: Re: [OAUTH-WG] Authorization code security issue (refra= med) >>>>>>>>>>>=20 >>>>>>>>>>> Apologies for the long message (again). I have attempted to sum t= hings up and bring out the issue without using any existing service or party= as an example of problems. It seems some have taken offence to my previous m= essage pushing for a solution. As a result it was not productive. I apologiz= e. Hopefully this message sticks to the issue of developing an appropriate c= ounter measure to threats as that is my only intent. >>>>>>>>>>>=20 >>>>>>>>>>> As Prateek clarified in the previous message to Francisco, SAML a= lso uses SHOULD, but artifact security is achieved by an additional counter-= measure... >>>>>>>>>>>> The identity provider MUST ensure that only the service provide= r to whom the message has >>>>>>>>>>>> been issued is given the message as the result of an request. >>>>>>>>>>>=20 >>>>>>>>>>> Yet, in OAuth the client app is not unique for a particular set o= f client credentials we currently have no way to verify that the correct cli= ent got the code. This has been the mechanism that the community has been as= suming solves the problem. Client credentials do not always work to protect t= he authorization code because in OAuth you can have many many clients with t= he same credential. For example everyone with the same mobile app likely has= the same client credential. Thus a copy of a valid client app which is easy= to obtain becomes the hacker's attack vector. So, the client credential is n= ot an effective counter in this case. >>>>>>>>>>>=20 >>>>>>>>>>> Several have commented that there are other supplementary techni= ques for protection, but in my view, most of them work indirectly and/or dep= end on correct collective configuration of several components. Some of these= are: tokens may be used one time; tokens are invalidated if used a second t= ime, tokens are sufficiently unique, etc. All of these will help. But none a= re designed to directly counter the attack. In fact the best one - token inv= alidation carries the additional problem of unreliable service for the legit= imate client. The hacker can deny service to anyone in the room simply by re= -using any tokens seen. >>>>>>>>>>>=20 >>>>>>>>>>> =46rom my perspective, the "easy" solution was to increase the r= equirements on TLS from SHOULD to MUST to prevent eavesdropping of the code.= This was echoed by several others. I agree this will not work for everyone.= Many have made strong arguments for why they can't use it. But without a MU= ST we are still missing a direct counter to the threat. >>>>>>>>>>>=20 >>>>>>>>>>> I don't want to change things at this late date, but maybe this m= eans introducing some form of mutual authentication -- some way for the requ= esting client "instance" to prove that they are the copy eligible to use an a= uthorization code.=20 >>>>>>>>>>>=20 >>>>>>>>>>> To end this discussion, I propose we vote on the proposal from E= ran plus one new option... >>>>>>>>>>> 1. Include a normative MUST use TLS for the client redirection U= RI endpoint. >>>>>>>>>>> 2. Include a normative SHOULD use TLS for the client redirection= URI endpoint with strong language explaining the various attacks possible i= f the endpoint is not made secure. >>>>>>>>>>> 3. Keep current language of SHOULD, but develop a direct counter= -measure to token theft such as specific client instance identification or m= utual authentication. >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Francisco, >>>>>>>>>>>>=20 >>>>>>>>>>>> You are right, I was in error to suggest that it was a MUST. >>>>>>>>>>>>=20 >>>>>>>>>>>> I think my main concern was that security considerations should= not be based on polling developers/deployers of an existing or legacy proto= col. >>>>>>>>>>>>=20 >>>>>>>>>>>> SAML does include some additional countermeasures though - for e= xample (lines 595-596, profiles document) - that specifically deal with the >>>>>>>>>>>> artifact being leaked -=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> [quote] >>>>>>>>>>>> The identity provider MUST ensure that only the service provide= r to whom the message has >>>>>>>>>>>> been issued is given the message as the result of an request. >>>>>>>>>>>> [\quote] >>>>>>>>>>>>=20 >>>>>>>>>>>> - prateek >>>>>>>>>>>>> Hi Prateek, >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I would like to strongly disagree with this proposal. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> It amounts to explicitly making OAuth 2.0 insecure so as to >>>>>>>>>>>>>> satisfy some mysterious and unspecified set of legacy OAuth >>>>>>>>>>>>>> 1.0 deployments. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The SAML web SSO (artifact) profile - which shares many >>>>>>>>>>>>>> characteristics with the initial steps in OAuth - requires >>>>>>>>>>>>>> precisely such a counter-measure and is widely implemented >>>>>>>>>>>>>> in 1000s of deployments. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> What counter-measure is this? Can you provide a reference? >>>>>>>>>>>>> Section 4.1.3.5 of=20 >>>>>>>>>>>>> http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.= 0-os.pdf >>>>>>>>>>>>> recommends TLS but does not require it. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Francisco >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From skylar@kiva.org Mon Apr 4 21:12:12 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848B53A687E for ; Mon, 4 Apr 2011 21:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqIwfFzmdseH for ; Mon, 4 Apr 2011 21:12:10 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by core3.amsl.com (Postfix) with SMTP id 7C6E73A687C for ; Mon, 4 Apr 2011 21:12:08 -0700 (PDT) Received: from mail-gx0-f181.google.com ([209.85.161.181]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKTZqW/5YOgPDz7kf2/a/+RafbLwRJEZ9W@postini.com; Mon, 04 Apr 2011 21:13:52 PDT Received: by gxk9 with SMTP id 9so2885740gxk.12 for ; Mon, 04 Apr 2011 21:13:51 -0700 (PDT) Received: by 10.150.61.20 with SMTP id j20mr37184yba.175.1301976831168; Mon, 04 Apr 2011 21:13:51 -0700 (PDT) Received: from [192.168.2.8] (74-128-24-154.dhcp.insightbb.com [74.128.24.154]) by mx.google.com with ESMTPS id c24sm6100214ana.47.2011.04.04.21.13.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 21:13:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Tue, 5 Apr 2011 00:13:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6FE840D7-7555-4DCD-93FC-5D38E86308EC@kiva.org> References: <133605.76951.qm@web55802.mail.re3.yahoo.com> <4D99EA6C.8060003@oracle.com> <188405.40029.qm@web37607.mail.mud.yahoo.com> <3671511D-F730-42F8-8916-FE674268AB80@kiva.org> <3CB0493B-C5D4-4ACA-B66D-C1E9FE23BA12@oracle.com> <2BDF838F-C5CE-43C3-B017-91D967ECDAC0@kiva.org> <4A384831-10D3-4305-98ED-C189761E6D32@oracle.com> To: Phillip Hunt X-Mailer: Apple Mail (2.1084) Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 04:12:12 -0000 Wow. I can't believe we're having this debate. You're describing a = failed implementations, not the spec. I think you are also = misunderstanding the implementation of this client flow. Have you built = a sample client with this flow? I'm going respond to these points, but if there's still confusion, I'm = going to need someone else to defend your argument. I'm either = completely misunderstanding the case you're presenting, or you are. See inline... On Apr 4, 2011, at 11:30 PM, Phillip Hunt wrote: > On 2011-04-04, at 18:39, Skylar Woodward wrote: >=20 >> On Apr 4, 2011, at 4:06 PM, Phil Hunt wrote: >>=20 >>> For the moment, I'm only talking about mobile clients. >>>=20 >>> Very quickly here is the attack... >>> 1) Paul starts dance at good Client & good AS, App requests = authorization. Note: outbound call is secure, but returned redirect is = not. >>=20 >> I'm going to re-iterate Brian's point that this is not an interesting = attack because we have no problem with securing a response to the = outbound call. Just to be very clear that we're all speaking about the = same thing here I'm detailing what you are implying in step one = (assuming pop-out to external browser as you mentioned earlier in this = thread): >>=20 >> - Paul's mobile device (MD), running native client C, makes request = to the mobile browser (MB) on the same device for the OAuth = authorization page for provider P. >> - The MB makes an outbound request over TLS to P's outh/authorization = endpoint. (HTTPS) >> - P responds over the same socket with the approval (and or login = pages). (still HTTPS) > Not guaranteed by spec nor in practice.=20 The response is over the same SSL-protected connection which MB = initiated to P. It's a simple HTTP response to an HTTP request. There's = no way the client can't respond over TLS.... unless there's a feature of = SSL with which I'm not familiar that allows a peer to negotiate the = socket as insecure mid-communication without forcing the other peer to = close the socket. (If that actually exists, you'll have to show me the = API in OpenSSL that would even allow a provider to implement such = behavior - otherwise I'll never believe it. Then, show me the API call = in Apache that allows that same [useless] behavior for an HTTP response = handler.). P would have to redirect MB to a new URL on P which is not accessed via = HTTPS. That's not part of this discussion. No one is proposing it and = the spec forbids it with respect URLs on the Authorization Server. The authorization server MUST require TLS 1.2 for the Authorization = Endpoint as per item 2.1. >=20 >> - Paul clicks the Approval button on the provider authorization page = which initiates MB to make a new HTTPS call confirming the approval. >=20 > Again not in practice.=20 Please stop talking about practice. No one on this list is proposing = redirecting from the authorization endpoint to an insecure page before = sending the redirect + auth code. If you've discovered a faulty = implementation, please discuss this with that implementor. >> - MB responds on the same secure socket (HTTPS!) with the composed = redirect URI including auth code. Note here that the redirect URI uses = a custom protocol since the authorization is happening in an external = browser (not embedded in the client). This looks like something = x-application-myapp://oauth-callback?code=3Dsecret > My scanner is showing this is not happening. Moreover the spec only = says it is a SHOULD per the discussion.=20 Here, you may be evaluating a faulty client. Please discuss this with = the developer of the client you are evaluating. There is no option here (regardless of the language SHOULD). If the = client developer doesn't use a custom protocol handler which is = registered, the client application on the device will never get the = callback. For the flow to work, a custom URL scheme must be used. (Besides, I don't see any language limiting the scheme for URIs. Only = that the redirection URI be a URI and *should* be pre-registered or = otherwise trusted. But the point is moot for this flow. It must be a = custom app protocol registered to be handled by client C.) > This is the point that is often trivial to eavesdrop and easy to pass = into Brian's browser. The browser does the rest of the hack all by = itself by following the link.=20 >> - MB handles the redirect URI by opening the native client C, passing = it the redirect URI from the previous step. This is a secure transfer of = data between two apps on MD. >=20 > Agreed.=20 >>=20 >> This is the only flow on the table for a native mobile app using auth = codes and an external browser. All exchanges between clients (C and MB) = and server are over TLS. There is no MITM or sniffing exploit for this = flow. >>=20 > Only true if TLS is on.=20 This comment doesn't make sense. We've established that all = communication in this flow is over secured SSL channels. >> For an embedded browser flow, the flow is similarly secure as Brian = took care to describe. The redirect URI might be an URN, a custom URI, = or an HTTPS url. >>=20 >> For an intercept to happen as you've outlined in step 2, MB or native = client C must make a **new** network connection to some yet-to-be- >=20 > Remember the token request is a NEW endpoint.=20 What does this comment even mean?! What is it one is meant to remember? = The token request has never been in question. It must support TLS 1.2 = (per section 2.2) and the server is known: it's still provider P.=20 >> identified server. To me, it seems beyond obvious that the redirect = response from the provider's authorization server would be secured over = the same socket that started the authorization. If the authorization = server redirects to itself using an HTTP url which then responds with = the redirect URI, that is a poorly implemented authorization server and = would be non-complient according to the spec. That's sloppy coding, not = a sloppy spec. >=20 > I think you are over complicating. Look at the Facebook implementation = (No offense to Facebook) and watch with a scanner.=20 Facebook has nothing to do with evaluating this flow. If you feel some = mobile client interaction with a Facebook API demonstrates this well you = should explain the flow and also demonstrate that the Facebook-hosted = provider you are evaluating is compliant with the latest draft of the = spec. I'm confident you would find the client or server non-compliant, = or that you are in fact describing a flow different from that of the = native mobile client + external browser. >> So, this leaves us no identified security compromise for the native = mobile client, thus no need for further measures to secure this flow. >>=20 >> Whew. >=20 > Well the hack works just fine for me. I really wish you were correct. = :) >>=20 >>=20 >>> 2) Evil Brian intercepts the (HTTP) redirect containing Paul's authz = code >>> 3) Brian takes Paul's redirect #2 and enters it in his browser (e.g. = by script) >>> 4) Brian's browser processes redirect URI from #3 and passes to = Brian's copy of client (e.g. downloaded from app store). >>> 5) Brian's client exchanges substituted authz code for access token >>> 6) Brian's client now accesses service using Paul's authorization >>>=20 >>> As was explained earlier this attack is minimized by things like = token invalidation when the second client comes along, but we still have = a horserace and possibility of DoS for the user at minimum. >>>=20 >>> The server cannot mitigate this unless it can either ensure the = client is the only one that could have received the code, or can somehow = uniquely identify the client so that a copy cannot masquerade as the = original requestor. >>>=20 >>> Phil >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2011-04-04, at 12:52 PM, Skylar Woodward wrote: >>>=20 >>>> I'm confused - it seems like you're mixing web clients and native = clients in this most recent explanation. It's perfectly reasonable that = the authorization code will always be returned by a provider in a secure = TLS channel to the web browser or native client which started the = authorization request. What's not reasonable is, in the case of the = code returned to a web browser (acting on behalf of a web client), for = the browser to then pass the code on to the web client over TLS. >>>>=20 >>>> Maybe you can elaborate the attack you are considering by listing = each network request/response between the mobile client and any servers? >>>>=20 >>>> I'll repeat again that the attack I've seen described thus far = doesn't apply to mobile apps with( or without) many copies because there = is no local redirect involved. (The redirect URI is merely an identifier = that says "here's the code!" - it need not be a network location, and if = it is, it's just a local location on the same device - eg, another app = running on the same device). >>>>=20 >>>> skylar >>>>=20 >>>> On Apr 4, 2011, at 3:38 PM, Phil Hunt wrote: >>>>=20 >>>>> If you run a scanner, you will see that many of the current draft = implementations pass the authorization code by redirect without SSL. = I've seen several implementations where the authorization code is easy = to scan. >>>>>=20 >>>>> I suspect this occurs because the HTTP response isn't directly in = response to the original outgoing authorization. When I run the scanner, = the resource provider is performing a workflow with the user that = accomplishes form based authentication and authorization with the user, = some of which is not on SSL. What happens is the redirect is then not = sent by SSL. It seems like only a natural consequence of typical = authentication/authorization workflows. Or at best, it is difficult the = guarantee that the authorization code will always be returned in a = secure TLS channel. >>>>>=20 >>>>> Several people stated that the redirect end-point cannot implement = server-side security (called local redirect) and I think their request = is reasonable as it would require each client to have its own server = certificate. That *might* be acceptable to most web apps, but likely = won't work for apps with many many copies like mobile apps. >>>>>=20 >>>>> So, I'm making the assumption that if we can minimally count on = outbound TLS security, the transaction id would suffice to allow the = token service to connect the originating authorization client with the = client requesting an access token. >>>>>=20 >>>>> Phil >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2011-04-04, at 12:28 PM, Skylar Woodward wrote: >>>>>=20 >>>>>> But mobile clients aren't vulnerable to this type of attack = because all of their code is contained on the device and they make all = outgoing requests to the provider via SSL. There are no redirects to = insecure remote endpoints. A mobile device incapable of making outgoing = SSL requests would not be able to run an OAuth-compliant client as the = spec is currently written. >>>>>>=20 >>>>>> Where in this example is the un-encrypted exchange you are trying = to protect? >>>>>>=20 >>>>>>=20 >>>>>> On Apr 4, 2011, at 3:12 PM, Phil Hunt wrote: >>>>>>=20 >>>>>>> I was referring to a mobile client that passes the request via = an external browser. That browser is capable of running SSL with server = authentication only. >>>>>>>=20 >>>>>>> Phil >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2011-04-04, at 12:08 PM, Skylar Woodward wrote: >>>>>>>=20 >>>>>>>> Maybe you can explain your example in more detail then? I'm = assuming your "client app" is a web application hosted on web server = supporting only HTTP. >>>>>>>>=20 >>>>>>>> How does the nonce or request_id get to the provider as part of = the authorization request in your example? (step 1) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Apr 4, 2011, at 3:03 PM, Phillip Hunt wrote: >>>>>>>>=20 >>>>>>>>> It doesn't require client side ssl.=20 >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> Sent from my phone.=20 >>>>>>>>>=20 >>>>>>>>> On 2011-04-04, at 11:47, Skylar Woodward = wrote: >>>>>>>>>=20 >>>>>>>>>> How does the client app transmit the nonce (random number) to = the web browser for redirect to the provider? If the client app does not = support HTTPS, it can't set up a secure session on its own to give the = browser/user something to pass on during the provider authorization. >>>>>>>>>>=20 >>>>>>>>>> To me, this is nothing different that a unique value of = "state" which robust clients will already use to differentiate request = flows. Such a state variable would be exposed both on its way and back = of the provider's redirect. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> In any case, I see HTTPS as the simple solution here. I = question if it is in the scope of OAuth to provide a mechanism to the = community to protect against such MITM attacks between a hosted web = application and the web browser. If the nature of the data requires = such protection, the app developer (or the provider) can work to provide = such security outside of HTTPS. In the right context, tunneling = customer traffic through a provider-provided VPN could be considered a = reasonable protection for the cases folks have outlined. It just = doesn't seem like a popular need at this point, and there seem to be no = easy wins for hosted clients unable to register with a certificate = authority. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote: >>>>>>>>>>=20 >>>>>>>>>>> I have been wondering if we can combine a couple of things = such as a client generated transaction secret and use limited TLS to = achieve a fix. Note: this would address a hacker sniffing a returned = authorization code, but it probably does little for the MITM scenario = that was also outlined. >>>>>>>>>>>=20 >>>>>>>>>>> 1. The client app generate a random number or sequence of = characters, lets call it "request_id", then that value would be included = and securely (using TLS) transmitted in the authorization request. >>>>>>>>>>> 2. The authorization server does its usual thing and = returns, preferably securely but not necessarily, the authorization code = to the client app. >>>>>>>>>>> 3. Upon requesting an access_token, the client app also = includes the same request_id in its secure request to the token = endpoint. >>>>>>>>>>> 4. The token server verifies that the "request_id" matches = the request_id supplied in the authorize request (in addition to all the = other processing). >>>>>>>>>>>=20 >>>>>>>>>>> Since both requests are sent securely a sniffing client = cannot obtain the client request_id even though it might be able to = obtain the authorization code being returned. >>>>>>>>>>>=20 >>>>>>>>>>> What this might allow is that the client can transmit a = secret protected by TLS in its outbound request, but can accept = non-secure delivery of the authorization code. The token server then = has a means to verify that the client exchanging the authorization code = is the same one that made the initial request. >>>>>>>>>>>=20 >>>>>>>>>>> This is off the top of my head, I am sure the proposal is = likely not yet a complete solution, but maybe someone can build on that. >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 2011-04-04, at 10:52 AM, Oleg Gryb wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> After looking into exiting (and working) implementations of = OAuth 1.0 in mobile world I have strong doubts about possibility of = implementing what was suggested in option #3.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> In my view, two conditions are needed to achieve that: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. Something unique stored on a mobile client. >>>>>>>>>>>> 2. That something should be a secret, so other (malicious) = clients could not reuse it. >>>>>>>>>>>>=20 >>>>>>>>>>>> Distribution of that "unique secrets" should be automated = in the mobile world and is usually included to mobile application=20 >>>>>>>>>>>> activation process, but that activation process can't make = conditions 1 & 2 above met in full, becuase: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. As soon as secrets are distributed to a mobile device = they are not quite secret any more >>>>>>>>>>>> 2. As soon as the secret becomes known, a simulator or = other mobile device can be used to spoof the traffic >>>>>>>>>>>>=20 >>>>>>>>>>>> I would consider option #3 as an illusion until somebody = comes up with a solution that would address the described issues. >>>>>>>>>>>>=20 >>>>>>>>>>>> BTW, the draft of "OAuth Dynamic Client Registration = Protocol" (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has = expired on Feb. 12 and I didn't see any attempts to re-vitalise it. I = think it would be better and more beneficial for the community to return = to this protocol rather than inventing a new method of "mutual = authentication".=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> From: Phil Hunt >>>>>>>>>>>> To: Prateek Mishra >>>>>>>>>>>> Cc: OAuth WG >>>>>>>>>>>> Sent: Mon, April 4, 2011 9:52:17 AM >>>>>>>>>>>> Subject: Re: [OAUTH-WG] Authorization code security issue = (reframed) >>>>>>>>>>>>=20 >>>>>>>>>>>> Apologies for the long message (again). I have attempted to = sum things up and bring out the issue without using any existing service = or party as an example of problems. It seems some have taken offence to = my previous message pushing for a solution. As a result it was not = productive. I apologize. Hopefully this message sticks to the issue of = developing an appropriate counter measure to threats as that is my only = intent. >>>>>>>>>>>>=20 >>>>>>>>>>>> As Prateek clarified in the previous message to Francisco, = SAML also uses SHOULD, but artifact security is achieved by an = additional counter-measure... >>>>>>>>>>>>> The identity provider MUST ensure that only the service = provider to whom the message has >>>>>>>>>>>>> been issued is given the message as the result of an = request. >>>>>>>>>>>>=20 >>>>>>>>>>>> Yet, in OAuth the client app is not unique for a particular = set of client credentials we currently have no way to verify that the = correct client got the code. This has been the mechanism that the = community has been assuming solves the problem. Client credentials do = not always work to protect the authorization code because in OAuth you = can have many many clients with the same credential. For example = everyone with the same mobile app likely has the same client credential. = Thus a copy of a valid client app which is easy to obtain becomes the = hacker's attack vector. So, the client credential is not an effective = counter in this case. >>>>>>>>>>>>=20 >>>>>>>>>>>> Several have commented that there are other supplementary = techniques for protection, but in my view, most of them work indirectly = and/or depend on correct collective configuration of several components. = Some of these are: tokens may be used one time; tokens are invalidated = if used a second time, tokens are sufficiently unique, etc. All of = these will help. But none are designed to directly counter the attack. = In fact the best one - token invalidation carries the additional problem = of unreliable service for the legitimate client. The hacker can deny = service to anyone in the room simply by re-using any tokens seen. >>>>>>>>>>>>=20 >>>>>>>>>>>> =46rom my perspective, the "easy" solution was to increase = the requirements on TLS from SHOULD to MUST to prevent eavesdropping of = the code. This was echoed by several others. I agree this will not work = for everyone. Many have made strong arguments for why they can't use it. = But without a MUST we are still missing a direct counter to the threat. >>>>>>>>>>>>=20 >>>>>>>>>>>> I don't want to change things at this late date, but maybe = this means introducing some form of mutual authentication -- some way = for the requesting client "instance" to prove that they are the copy = eligible to use an authorization code.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> To end this discussion, I propose we vote on the proposal = from Eran plus one new option... >>>>>>>>>>>> 1. Include a normative MUST use TLS for the client = redirection URI endpoint. >>>>>>>>>>>> 2. Include a normative SHOULD use TLS for the client = redirection URI endpoint with strong language explaining the various = attacks possible if the endpoint is not made secure. >>>>>>>>>>>> 3. Keep current language of SHOULD, but develop a direct = counter-measure to token theft such as specific client instance = identification or mutual authentication. >>>>>>>>>>>>=20 >>>>>>>>>>>> Phil >>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 2011-04-04, at 8:57 AM, Prateek Mishra wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Francisco, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> You are right, I was in error to suggest that it was a = MUST. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I think my main concern was that security considerations = should not be based on polling developers/deployers of an existing or = legacy protocol. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> SAML does include some additional countermeasures though - = for example (lines 595-596, profiles document) - that specifically deal = with the >>>>>>>>>>>>> artifact being leaked -=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [quote] >>>>>>>>>>>>> The identity provider MUST ensure that only the service = provider to whom the message has >>>>>>>>>>>>> been issued is given the message as the result of an = request. >>>>>>>>>>>>> [\quote] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> - prateek >>>>>>>>>>>>>> Hi Prateek, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I would like to strongly disagree with this proposal. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> It amounts to explicitly making OAuth 2.0 insecure so as = to >>>>>>>>>>>>>>> satisfy some mysterious and unspecified set of legacy = OAuth >>>>>>>>>>>>>>> 1.0 deployments. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The SAML web SSO (artifact) profile - which shares many >>>>>>>>>>>>>>> characteristics with the initial steps in OAuth - = requires >>>>>>>>>>>>>>> precisely such a counter-measure and is widely = implemented >>>>>>>>>>>>>>> in 1000s of deployments. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> What counter-measure is this? Can you provide a = reference? >>>>>>>>>>>>>> Section 4.1.3.5 of=20 >>>>>>>>>>>>>> = http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>>>>>>>>>>>>> recommends TLS but does not require it. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Francisco >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 From SRS0=rjaflL=W5=lodderstedt.net=torsten@srs.bis7.eu.blackberry.com Mon Apr 4 22:13:35 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920E73A68AA for ; Mon, 4 Apr 2011 22:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.642 X-Spam-Level: X-Spam-Status: No, score=-4.642 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rvasn7fBBFOv for ; Mon, 4 Apr 2011 22:13:34 -0700 (PDT) Received: from smtp08.bis7.eu.blackberry.com (smtp08.bis7.eu.blackberry.com [178.239.85.13]) by core3.amsl.com (Postfix) with ESMTP id 0F4CF3A68A7 for ; Mon, 4 Apr 2011 22:13:33 -0700 (PDT) Received: from b1.c11.bise7.blackberry ([192.168.0.101]) by srs.bis7.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p355FFo0032730; Tue, 5 Apr 2011 05:15:15 GMT Received: from ups31.c11.bise7.blackberry (cmp31.c11.bise7.blackberry [172.18.204.201]) by b1.c11.bise7.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p355FDBG002597; Tue, 5 Apr 2011 05:15:13 GMT X-rim-org-msg-ref-id: 1567368214 Message-ID: <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> In-Reply-To: <38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> Sensitivity: Normal Importance: Normal To: "Skylar Woodward" From: torsten@lodderstedt.net Date: Tue, 5 Apr 2011 05:15:12 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 05:30:20 -0000 SGkgU2t5bGFyLA0KDQpUaGFuayB5b3UgZm9yIHNoYXJpbmcgdGhpcyBpbmZvcm1hdGlvbiB3aXRo IHVzLiBTb21lIHRob3VndHM6DQoNClRoZSBlbXB0eSBzdHJpbmcgbWFrZXMgeW91ciBpbXBsZW1l bnRhdGlvbiBzeW50YWN0aWNhbGx5IGNvbXBsaWFudCBidXQgZG9lcyBvYnZpb3VzbHkgbm90IGNv bXBseSB3aXRoIGl0cyBzZW1hbnRpY3MgYW5kIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy9l eHBlY3RhdGlvbnMgYXNzb2NpYXRlZCB3aXRoIGEgc2VjcmV0LiBNb3Jlb3Zlciwgd2hhdCBhYm91 dCBpbnRlcm9wZXJhYmlsaXR5PyANCg0KSSB0aGluayBub3QgdXNpbmcgc2VjcmV0cyBmb3Igc3Vj aCBjbGllbnRzIGlzIHRoZSBob25lc3Qgc29sdXRpb24uIFdlIGNhbiBqdXN0IGNoYW5nZSB0aGUg c3BlYydzIHRleHQgdG8gZXhwcmVzcyB3aGF0IHdlIHRoaW5rIGlzIHRoZSByaWdodCB3YXkuDQoN CnJlZ2FyZHMsDQpUb3JzdGVuLg0KR2VzZW5kZXQgbWl0IEJsYWNrQmVycnmuIFdlYm1haWwgdm9u IFRlbGVrb20gRGV1dHNjaGxhbmQgIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogU2t5bGFyIFdvb2R3YXJkIDxza3lsYXJAa2l2YS5vcmc+DQpEYXRlOiBNb24sIDQgQXByIDIw MTEgMTk6MTQ6NTMgDQpUbzogVG9yc3RlbiBMb2RkZXJzdGVkdDx0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldD4NCkNjOiBaZWx0c2FuLCBaYWNoYXJ5IChaYWNoYXJ5KTx6YWNoYXJ5LnplbHRzYW5AYWxj YXRlbC1sdWNlbnQuY29tPjsgS3JpcyBTZWxkZW48a3Jpcy5zZWxkZW5AZ21haWwuY29tPjsgb2F1 dGhAaWV0Zi5vcmc8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBGbG93 Y2hhcnQgZm9yIGxlZ3Mgb2YgT0F1dGgNCg0KSW4gb3VyIGltcGxlbWVudGF0aW9uIChub3QgeWV0 IHB1YmxpYykgd2UgYWNjZXB0IHRoZSBlbXB0eSBzdHJpbmcgKCIiKSBhcyB0aGUgdmFsdWUgZm9y IGNsaWVudHMgbm90IGlzc3VlZCBzZWNyZXRzLiBXaGlsZSB0aGlzIHdhcyBkb25lIHRvIHNpbXBs aWZ5IHRoZSBpbnRlcmZhY2UgYW5kIGltcGxlbWVudGF0aW9uLCBpdCB3b3VsZCBtYWtlIGl0IGNv bXBsaWFudCBpbiBteSB2aWV3LiAgSW4gdGhpcyBjYXNlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgaXMgdmFsaWRhdGluZyB0aGUgY3JlZGVudGlhbHMsIHdoaWNoIGFyZSB0aGUgY2xpZW50IElE IGFuZCB0aGUgZW1wdHkgc3RyaW5nLCB3aGljaCBpcyBlcXVpdmFsZW50IHNlY3VyaXR5LXdpc2Ug dG8gYW55IG90aGVyIGxlbmd0aCBvZiAic2VjcmV0IiBpc3N1ZWQgdG8gYSBuYXRpdmUgY2xpZW50 Lg0KDQpCZXNpZGVzLCBmb3IgbWFueSBwcm92aWRlcnMsIHRoZSBjbGllbnQgY3JlZGVudGlhbHMg d2lsbCBvbmx5IGJlIGEgY2xpZW50IElELiBUaGV5IHdvdWxkIHBsYW4gdG8gc2VjdXJlIGFsbCBl eGNoYW5nZXMgb3ZlciBUTFMgYW5kIGNyZWRlbnRpYWxzIHNlcnZlIGp1c3QgYXMgYSB0cmFja2lu ZyBkZXZpY2Ugb3IgYXQgYmVzdCwgYSB3ZWFrIGZvcm0gb2YgaWRlbnRpZmljYXRpb24uDQoNCnNr eWxhcg0KDQpPbiBBcHIgNCwgMjAxMSwgYXQgNTowMSBQTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCB3 cm90ZToNCg0KPiBBbSAwNC4wNC4yMDExIDIxOjM4LCBzY2hyaWViIFplbHRzYW4sIFphY2hhcnkg KFphY2hhcnkpOg0KPj4gQWNjb3JkaW5nIHRvIHNlY3Rpb24gIjYgUmVmcmVzaGluZyBhbiBBY2Nl c3MgVG9rZW4iICgtMTMudHh0KSwgY2xpZW50IHdoZW4gbWFraW5nIGEgcmVxdWVzdCBmb3IgZXhj aGFuZ2luZyBhIHJlZnJlc2ggdG9rZW4gZm9yIGFuIGFjY2VzcyB0b2tlbiBoYXMgdG8gaW5jbHVk ZSBpdHMgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbHMsIGFuZCB0aGUgImF1dGhvcml6YXRpb24g c2VydmVyIE1VU1QgdmFsaWRhdGUgdGhlIGNsaWVudCBjcmVkZW50aWFscyIuDQo+PiBIb3cgY2Fu IHRoaXMgYmUgZG9uZSBpZiBhIGNsaWVudCBpcyBhbiBhcHBsaWNhdGlvbiB0aGF0IGNhbid0IGhh dmUgYSBjbGllbnQgc2VjcmV0Pw0KPj4gVGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCBkb2Vz IHJlcXVpcmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIChwZXIgc2VjdGlvbiA0LjEpOg0KPj4gDQo+ PiAoRCkgIFRoZSBjbGllbnQgcmVxdWVzdHMgYW4gYWNjZXNzIHRva2VuIGZyb20gdGhlIGF1dGhv cml6YXRpb24NCj4+ICAgICAgICAgc2VydmVyJ3MgdG9rZW4gZW5kcG9pbnQgYnkgYXV0aGVudGlj YXRpbmcgdXNpbmcgaXRzIGNsaWVudA0KPj4gICAgICAgICBjcmVkZW50aWFscywgYW5kIGluY2x1 ZGVzIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgcmVjZWl2ZWQgaW4gdGhlDQo+PiAgICAgICAgIHBy ZXZpb3VzIHN0ZXAuDQo+PiANCj4+IEl0IGFwcGVhcnMgdGhhdCB0aGUgY2xpZW50cyB0aGF0IGNh bm5vdCBrZWVwIGl0cyBzZWNyZXQgY2Fubm90IHVzZSAoYmUgaXNzdWVkKSB0aGUgcmVmcmVzaCB0 b2tlbnMuDQo+IA0KPiBJbiBteSBvcGluaW9uLCB0aGlzIHBhcnQgb2YgdGhlIHNwZWMgaXMgbWlz bGVhZGluZy4gQXV0aG9yaXphdGlvbiBjb2RlIE1VU1QgYmUgcG9zc2libGUgd2l0aG91dCBjbGll bnQgYXV0aGVudGljYXRpb24uIE90aGVyd2lzZSwgT0F1dGggaXMgdXNlbGVzcyBmb3IgbmF0aXZl IGFwcHMuDQo+IA0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb2RkZXJzdGVk dC1vYXV0aC1zZWN1cml0eWNvbnNpZGVyYXRpb25zLTAxI3NlY3Rpb24tMi4xMCBkZXNjcmliZXMg aG93IHRoZSBmbG93IGNhbiBiZSBwcm90ZWN0ZWQgaW4gc3VjaCBjYXNlcy4NCj4gDQo+IHJlZ2Fy ZHMsDQo+IFRvcnN0ZW4uDQo+PiBaYWNoYXJ5DQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcml1cyBTY3VydGVzY3UNCj4+IFNlbnQ6IE1v bmRheSwgQXByaWwgMDQsIDIwMTEgMjozMCBQTQ0KPj4gVG86IEtyaXMgU2VsZGVuDQo+PiBDYzog b2F1dGhAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEZsb3djaGFydCBmb3Ig bGVncyBvZiBPQXV0aA0KPj4gDQo+PiBPbiBNb24sIEFwciA0LCAyMDExIGF0IDEwOjQ3IEFNLCBL cmlzIFNlbGRlbjxrcmlzLnNlbGRlbkBnbWFpbC5jb20+ICB3cm90ZToNCj4+PiBBIHR5cGljYWwg aVBob25lIGFwcCBjYW5ub3QgYmUgc2hpcHBlZCB3aXRoIGEgY2xpZW50IHNlY3JldCBhbmQgcmln aHRseSBvciB3cm9uZ2x5IHVzZXJzIGV4cGVjdCB0byBvbmx5IGhhdmUgdG8gZW50ZXIgdGhlaXIg Y3JlZGVudGlhbHMgb25jZS4NCj4+PiANCj4+PiBXaGF0IGlzIHRoZSBiZXN0IHByb2ZpbGUgdG8g dXNlIGZvciBhbiBhcHAgdGhhdCBjYW4ndCBoYXZlIGEgY2xpZW50IHNlY3JldCBhbmQgbmVlZHMg YSByZWZyZXNoIHRva2VuIG9yIGEgbG9uZyBsaXZlZCBhY2Nlc3MgdG9rZW4/DQo+PiBUaGUgYXV0 aG9yaXphdGlvbiBjb2RlIGdyYW50LCBha2Egd2ViIHNlcnZlciBmbG93Lg0KPj4gDQo+PiBUaGUg c3BlYyBpcyBtaXNsZWFkaW5nIGluIHRoaXMgcmVzcGVjdCBJTU8uDQo+PiANCj4+IE1hcml1cw0K Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gT0F1 dGggbWFpbGluZyBsaXN0DQo+PiBPQXV0aEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gT0F1dGggbWFpbGluZyBsaXN0DQo+PiBPQXV0aEBpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1h aWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQoNCg== From eran@hueniverse.com Mon Apr 4 22:58:04 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6423A68B5 for ; Mon, 4 Apr 2011 22:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhOFEXIVv2vJ for ; Mon, 4 Apr 2011 22:58:03 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4E6A33A6806 for ; Mon, 4 Apr 2011 22:58:03 -0700 (PDT) Received: (qmail 22983 invoked from network); 5 Apr 2011 05:59:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 5 Apr 2011 05:59:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 4 Apr 2011 22:59:35 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 4 Apr 2011 22:59:30 -0700 Thread-Topic: [OAUTH-WG] Authorization code security issue (reframed) Thread-Index: AcvzKtz/sEwa3PaRR9eEdnl4Y8quvwAJvUUQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DCCA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664D9B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <612045.49458.qm@web55805.mail.re3.yahoo.com> In-Reply-To: <612045.49458.qm@web55805.mail.re3.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 05:58:04 -0000 QmxhaW5lLCBIYW5uZXMsDQoNClRoaXMgdGhyZWFkIGhhcyBnb25lIGFzIGZhciBhcyBpdCBjYW4u IFdlIG5lZWQgdG8gc2h1dCBpdCBkb3duIGFuZCBtb3ZlIHRoaXMgaXRlbSB0byB0aGUgY2hhaXJz IChhbmQgcG90ZW50aWFsbHkgdGhlIEFEKSB0byByZXNvbHZlLCBnaXZlbiB0aGF0IHRoaXMgaXMg bm90IGEgdGVjaG5pY2FsIGlzc3VlLCBidXQgYSBwb2xpdGljYWwvcHJvY2VkdXJhbCBvbmUuIEkn bSBhc2tpbmcgdGhlIGNoYWlycyB0byBtYWtlIGEgZGVjaXNpb24gYWJvdXQgdGhpcywgZ2l2ZW4g dGhhdCB0aGUgd29ya2luZyBncm91cCBpcyB1bmFibGUgdG8gcmVhY2ggYSBjb25jbHVzaW9uLg0K DQpSYW50IGlubGluZSBiZWxvdy4uLg0KDQpFSEwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IEZyYW5jaXNjbyBDb3JlbGxhIFttYWlsdG86ZmNvcmVsbGFAcG9tY29y LmNvbV0NCj4gU2VudDogTW9uZGF5LCBBcHJpbCAwNCwgMjAxMSA1OjQ2IFBNDQoNCj4gSWYgdGhl IElFVEYgZW5kb3JzZWQgYSBwcm90b2NvbCBzdWNoIHRoYXQgYSBjb21wbGlhbnQgaW1wbGVtZW50 YXRpb24gYWxsb3dzDQo+IHVzZXIgaW1wZXJzb25hdGlvbiBhbmQgdW5hdXRob3JpemVkIGFjY2Vz cyB0byBwcm90ZWN0ZWQgcmVzb3VyY2UsIHRoZW4gdGhlDQo+IElFVEYgd291bGQgYmUgZW5kb3Jz aW5nIGxhY2sgb2Ygc2VjdXJpdHkuwqAgSG93IGlzIHRoYXQgaW5hY2N1cmF0ZT8NCg0KQmVjYXVz ZSB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzIGFuIElFVEYgZW5kb3JzZW1lbnQsIGFuZCBhIHB1 YmxpY2F0aW9uIG9mIGFuIFJGQyBvbmx5IG1lYW5zIHRoYXQgdGhlIGNvbW11bml0eSBoYXMgcmV2 aWV3ZWQgYSBkb2N1bWVudCBhbmQgaXQgcmVwcmVzZW50IGFzIGZ1bGwgcGljdHVyZSBhcyBwb3Nz aWJsZSAoYXQgdGhhdCB0aW1lKS4gVGhlcmUgaXMgbm90aGluZyBhYm91dCBhbiBJRVRGIHN0YW5k YXJkIHRoYXQgcmVxdWlyZXMgaXQgdG8gYWx3YXlzIHBpY2sgc2VjdXJpdHkgb3ZlciB1c2FiaWxp dHksICphcyBsb25nIGFzKiB0aGUgc2VjdXJpdHkgaXNzdWVzIGFyZSB3ZWxsIGRvY3VtZW50ZWQs IGV4cGxhaW5lZCwgYW5kIGdpdmVuIHRoZSBwcm9wZXIgY29udGV4dCBhbmQgd2FybmluZ3MuDQoN CkRvY3VtZW50aW5nIGEgc2VjdXJpdHkgaXNzdWUgYW5kIHJlY29tbWVuZGluZyBhIHNvbHV0aW9u IGlzIHdlbGwgd2l0aGluIElFVEYgcHJhY3RpY2UuIFRoZSBwb2ludCBvZiB0aGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbiBzZWN0aW9uIGlzIHRvIG1ha2Ugc3VyZSB0aG9zZSBpbXBsZW1lbnRpbmcg dGhlIHN0YW5kYXJkIHVuZGVyc3RhbmQgdGhlIHNlY3VyaXR5IGlzc3VlcyBpbnZvbHZlZC4gTm8g SUVURiBSRkMgY2xhaW1zIHRvIGJlIDEwMCUgc2VjdXJlIGFuZCB0aGF0IGFueSBpbXBsZW1lbnRh dGlvbiBvZiBpdCBjYW4gYmUgJ3RydXN0ZWQnLiBUaGUgSUVURiBzaG91bGQgKnByb21vdGUqIGJl c3Qgc2VjdXJpdHkgcHJhY3RpY2VzLCBhcyBsb25nIGFzIHRoZXkgYXJlIHByYWN0aWNhbC4NCg0K PiBUaGUgc3RhdGVtZW50IGlzIGhlbHBmdWwgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUg dXNlcnMgd2hvIHdvdWxkIGJlDQo+IHRoZSB2aWN0aW1zIG9mIHRoZSBhdHRhY2tzLsKgIFlvdSBz ZWVtIHRvIGJlIGNvbmNlcm5lZCBhYm91dCBjb21wYW5pZXMgYW5kDQo+IGRldmVsb3BlcnMgYnV0 IG5vdCBhYm91dCB1c2Vycy4NCg0KVGhhdCdzIGNyYXAuIFRoZSB1c2VyIGhhcyBubyB3YXkgb2Yg Z2FnaW5nIGFueXRoaW5nIHdpdGggcmVnYXJkIHRvIHRoZSBjbGllbnQgb3Igc2VydmVyIGltcGxl bWVudGF0aW9uLiBJdCBjYW5ub3QgdGVsbCBpZiB0aGUgc2VydmVyIGhhcyBpbXBsZW1lbnRlZCBh bnl0aGluZyBjb3JyZWN0bHkuIFRoZSB1c2VyIHdpbGwgbmV2ZXIgZXZlbiBrbm93IE9BdXRoIGV4 aXN0cy4gU2luY2Ugd2hlbiBkb2VzIGEgc3RhbmRhcmQgcHJvdGVjdCB1c2Vycz8gVGhlcmUgaXMg bm8gZW5mb3JjZW1lbnQuIE5vIElFVEYgcG9saWNlLiBJIGFtIG5vdCBldmVuIHN1cmUgdGhlIElF VEYgb3JnYW5pemF0aW9uIGNhbiBzYXkgYW55dGhpbmcgcHVibGljYWxseSBhYm91dCBhbnkgcGFy dGljdWxhciBpbXBsZW1lbnRhdGlvbiB3aXRob3V0IG9wZW5pbmcgaXRzZWxmIHRvIGxpdGlnYXRp b24uDQoNClVzZXJzIHZvdGUgd2l0aCB0aGVpciBmZWV0LiBIb3cgbWFueSBwZW9wbGUgc3RvcHBl ZCB1c2luZyB3ZWJtYWlsIHNlcnZpY2VzIG9uY2UgdGhleSBsZWFybmVkIGFib3V0IHRoZSBkYW5n ZXIgb2YgRmlyZVNoZWVwPyBQcmFjdGljYWxseSBub25lLiBPdXIgam9iIGlzIHRvIHByb2R1Y2Ug dGVjaG5pY2FsIGRvY3VtZW50cyB0aGF0IGltcHJvdmUgaW50ZXJvcGVyYWJpbGl0eSBhbmQgYWJp ZGUgYnkgdGhlIGJlc3Qgc2VjdXJpdHkgcHJhY3RpY2VzIHBvc3NpYmxlLiBPdXIgb25seSBhdWRp ZW5jZSBhcmUgdGhlIHBlb3BsZSBpbXBsZW1lbnRpbmcgdGhlIHN0YW5kYXJkLiBUaGUgb25seSBx dWVzdGlvbiBpcywgd2lsbCBhbiBhdmVyYWdlIGRldmVsb3BlciByZWFkaW5nIHRoZSBkb2N1bWVu dCB1bmRlcnN0YW5kIHRoZSBpc3N1ZSBhbmQgZG8gYXMgbXVjaCBhcyBwb3NzaWJsZSB0byBhZGRy ZXNzIGl0Pw0KDQpJJ20gaW4gdGhlIGJ1c2luZXNzIG9mIGJ1aWxkaW5nIGNvbnN1bWVyIHdlYiBw cm9kdWN0cy4gV2hvIGRvIHlvdSB0aGluayBhcmUgbXkgY3VzdG9tZXJzPyBXZSBhcmUgYWxsIGhl cmUgdG8gc2VydmUgdGhlIG5lZWRzIG9mIHRoZSBlbmQgdXNlci4gQnV0IHdlIGFsc28gbGl2ZSBp biB0aGUgcmVhbCB3b3JsZCB3aGVyZSB0aGUgd2ViIGlzIGluc2VjdXJlIGFuZCB3ZSBoYXZlIHRv IHdvcmsgd2l0aCB3aGF0IHdlJ3ZlIGdvdC4gWW91ciBwb3NpdGlvbiBpcyB0aGF0IGl0IGlzIGJl dHRlciB0byBtYWtlIGEgc3RhbmQgYW5kIGZvcmNlIGFsbW9zdCBldmVyeSBjb25zdW1lciB3ZWIg Y29tcGFueSB0byB2aW9sYXRlIHRoZSBzcGVjaWZpY2F0aW9uIChzaW5jZSB5b3UgY2FuJ3QgZm9y Y2UgdGhlbSB0byBhYmlkZSBieSBpdCkuIE15IHBvc2l0aW9uIGlzIHRoYXQgbW9yZSBwZW9wbGUg d2lsbCBwYXkgYXR0ZW50aW9uIHRvIHRoZSBpc3N1ZSBpZiB3ZSBleHBsYWluIGl0IGFuZCBub3Qg Z2l2ZSB0aGVtIGFuIGV4Y3VzZSB0byBpZ25vcmUgb3RoZXIgc2VjdXJpdHkgcmVsYXRlZCBNVVNU cyAob25jZSB5b3UgaWdub3JlIHRoZSBmaXJzdCwgdGhlIDJuZCwgM3JkLCAxMHRoIGNvbWUgZWFz eSkuDQogDQpJZiB3ZSBtYWtlIHRoaXMgYSBNVVNULCB3ZSBrbm93IEZhY2Vib29rIGlzIGdvaW5n IHRvIGlnbm9yZSBpdCBiZWNhdXNlIHRoZXkgaGF2ZSBubyBvdGhlciBvcHRpb25zIGF0IHRoaXMg cG9pbnQgaW4gdGltZS4gVGhleSBhcmUgbm90IGdvaW5nIHRvIHdyaXRlICdBbG1vc3QgT0F1dGgg Mi4wIGNvbXBsaWFudCcgb24gdGhlaXIgc2l0ZS4gVGhleSBhcmUgbm90IGdvaW5nIHRvIGV2ZW4g bWVudGlvbiBPQXV0aCB0byB0aGVpciB1c2Vycy4gQnV0IG9uIHRoZWlyIGRldmVsb3BlciBzaXRl IHRoZXkgd2lsbCBzYXkgdGhleSBzdXBwb3J0IE9BdXRoIDIuMC4gVGhlbiB5b3Ugd2lsbCBjb21l IGFuZCB3cml0ZSBhIGxvbmcgYmxvZyBwb3N0IGFib3V0IGhvdyB0aGV5IGFyZSBub3QgcmVhbGx5 IE9BdXRoIDIuMCBjb21wbGlhbnQuIEdyZWF0LiBOb3cgd2hhdD8gNjAwIG1pbGxpb24gcGVvcGxl IHdpbGwgc3RvcCB1c2luZyBGYWNlYm9vaz8NCg0KWW91J3ZlIGJlZW4gdG9sZCBjbGVhcmx5IHRo YXQgdGhlIHRocmVlIGxhcmdlc3QgY29uc3VtZXIgd2ViIGNvbXBhbmllcyAoYnkgYXVkaWVuY2Up OiBZYWhvbyEsIEZhY2Vib29rLCBhbmQgR29vZ2xlLCBhcmUgYWxsIGdvaW5nIHRvIGlnbm9yZSBh IE1VU1QgaWYgdGhpcyBpcyB3aGF0IHdlIGFyZSBnb2luZyB0byBzcGVjaWZ5LiBFaXRoZXIgeW91 IGp1c3QgZG9uJ3QgY2FyZSBwcm9kdWNpbmcgYSBkb2N1bWVudCB0aGF0IHRoZSB0aHJlZSBiaWdn ZXN0IHBsYXllcnMgb24gdGhlIHdlYiBpZ25vcmUsIG9yIHlvdSBraWRkaW5nIHlvdXJzZWxmIHRo YXQgdGhleSB3aWxsIGFsbCBjb21taXQgYnVzaW5lc3Mgc3VpY2lkZSBhbmQgZW5mb3JjZSBpdCAt IGZvcmNpbmcgdGhlaXIgZGV2ZWxvcGVycyB0byBwcm9kdWNlIHVudXNhYmxlIGNsaWVudCBhcHBs aWNhdGlvbnMgKGFuZCB0aGF0IGNsaWVudCBkZXZlbG9wZXJzIHdpbGwgZ28gYWxvbmcgd2l0aCBp dCwgd2FzdGluZyB0aW1lIG9uIHVudXNhYmxlIHByb2R1Y3RzKS4NCg0KVGhlIHdvcmxkIGRvZXNu J3QgZ2V0IGFueSBzYWZlciB3aXRoIHRoaXMgbGFuZ3VhZ2UsIGJ1dCB0aGUgc3BlYyBnZXRzIGZ1 cnRoZXIgYXdheSBmcm9tIHJlYWxpdHkgYW5kIHdlIGFsbCBrbm93IHdoYXQgYSBzbGlwcGVyeSBz bG9wZSB0aGF0IGlzIHdoZW4gaW1wbGVtZW50YXRpb24gYW5kIHN0YW5kYXJkcyBzdGFydCBkcmlm dGluZyBhcGFydC4NCg0KT3VyIGpvYiBpcyB0byBmdWxseSBkb2N1bWVudCBhbnkgc2VjdXJpdHkg c2hvcnRjb21pbmcgd2UgYXJlIGF3YXJlIG9mLiBBIFNIT1VMRCBkb2VzIGp1c3QgdGhhdCBhbmQg aXMgcGVyZmVjdGx5IHJlYXNvbmFibGUuDQoNCkVITA0KDQoNCg0KDQoNCg0KDQoNCg== From romeda@gmail.com Tue Apr 5 00:27:19 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31423A68DC for ; Tue, 5 Apr 2011 00:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVw8F5xItA6F for ; Tue, 5 Apr 2011 00:27:18 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id AA6863A67EF for ; Tue, 5 Apr 2011 00:27:16 -0700 (PDT) Received: by qwc23 with SMTP id 23so63482qwc.31 for ; Tue, 05 Apr 2011 00:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=RHl6NH+PXTAxyfhy92L5WpcT/VYRptcLUER/XSYQ30k=; b=LTshM82MakzFSzAVjv/QaLnUpRouvQdgrmt9CWrD8AmthXte0IH/hvUYdbOuyuktTO jT0ePfsL9ZFaTjiz0Tj7neujIkcwCWxhhX6ZDsBYELB19DYUJHpT/TXBxl77ArGQ0ppK 4uDVzo/5Ekgi8bdlmzjLd/XZ6KYYm/ahNb8Ko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=s6nEtGGRFjHGUPm5YZIBJxbVqgY0uaAKt9BeQcn19OHwYj6kDTgArZJ5rHenzq9hWb y4wUxTpafNGOXCwOX7LfOTP5NHvFdlKrDDewjFeDA8E6NQD8K3rPZ+bdogxPMKbeZ2me WobYrkquIR+QIlJtp7Bl8Z09GR3ByZ9vn64Tg= Received: by 10.229.136.208 with SMTP id s16mr6610331qct.134.1301988539460; Tue, 05 Apr 2011 00:28:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.54.72 with HTTP; Tue, 5 Apr 2011 00:28:39 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664DCCA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664D9B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <612045.49458.qm@web55805.mail.re3.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234465664DCCA@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Blaine Cook Date: Tue, 5 Apr 2011 08:28:39 +0100 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 07:27:19 -0000 DO NOT REPLY TO THIS EMAIL. To Eran's point, before reaching the end of this thread after limited access to email over the weekend, I was going to shut this thread down anyways. I'm not going to issue a call for consensus on this issue, because I don't believe anyone on the list (except for a small handful of active participants) have read even a fraction of the thread. Furthermore, I'm sure that we understand this threat, and we will ensure that it is properly documented in the Security Considerations. If you are reading this, have not had your voice heard on this matter, and think that this issue is unrepresented in the Security Considerations, please email the chairs directly. b. nb: The OAuth working group's job is to ship OAuth 2.0; while this is includes ensuring a secure protocol, "secure" does not equal "impenetrable". If you believe that cookies and security in HTTP is flawed, please go talk to the HTTP working group and lobby for a MUST of TLS over all HTTP connections. I also urge you to consider the implications of Comodogate =E2=80=93 $100 certs ain't what they used to be. On 5 April 2011 06:59, Eran Hammer-Lahav wrote: > Blaine, Hannes, > > This thread has gone as far as it can. We need to shut it down and move t= his item to the chairs (and potentially the AD) to resolve, given that this= is not a technical issue, but a political/procedural one. I'm asking the c= hairs to make a decision about this, given that the working group is unable= to reach a conclusion. > > Rant inline below... > > EHL > > >> -----Original Message----- >> From: Francisco Corella [mailto:fcorella@pomcor.com] >> Sent: Monday, April 04, 2011 5:46 PM > >> If the IETF endorsed a protocol such that a compliant implementation all= ows >> user impersonation and unauthorized access to protected resource, then t= he >> IETF would be endorsing lack of security.=C2=A0 How is that inaccurate? > > Because there is no such thing as an IETF endorsement, and a publication = of an RFC only means that the community has reviewed a document and it repr= esent as full picture as possible (at that time). There is nothing about an= IETF standard that requires it to always pick security over usability, *as= long as* the security issues are well documented, explained, and given the= proper context and warnings. > > Documenting a security issue and recommending a solution is well within I= ETF practice. The point of the security consideration section is to make su= re those implementing the standard understand the security issues involved.= No IETF RFC claims to be 100% secure and that any implementation of it can= be 'trusted'. The IETF should *promote* best security practices, as long a= s they are practical. > >> The statement is helpful from the point of view of the users who would b= e >> the victims of the attacks.=C2=A0 You seem to be concerned about compani= es and >> developers but not about users. > > That's crap. The user has no way of gaging anything with regard to the cl= ient or server implementation. It cannot tell if the server has implemented= anything correctly. The user will never even know OAuth exists. Since when= does a standard protect users? There is no enforcement. No IETF police. I = am not even sure the IETF organization can say anything publically about an= y particular implementation without opening itself to litigation. > > Users vote with their feet. How many people stopped using webmail service= s once they learned about the danger of FireSheep? Practically none. Our jo= b is to produce technical documents that improve interoperability and abide= by the best security practices possible. Our only audience are the people = implementing the standard. The only question is, will an average developer = reading the document understand the issue and do as much as possible to add= ress it? > > I'm in the business of building consumer web products. Who do you think a= re my customers? We are all here to serve the needs of the end user. But we= also live in the real world where the web is insecure and we have to work = with what we've got. Your position is that it is better to make a stand and= force almost every consumer web company to violate the specification (sinc= e you can't force them to abide by it). My position is that more people wil= l pay attention to the issue if we explain it and not give them an excuse t= o ignore other security related MUSTs (once you ignore the first, the 2nd, = 3rd, 10th come easy). > > If we make this a MUST, we know Facebook is going to ignore it because th= ey have no other options at this point in time. They are not going to write= 'Almost OAuth 2.0 compliant' on their site. They are not going to even men= tion OAuth to their users. But on their developer site they will say they s= upport OAuth 2.0. Then you will come and write a long blog post about how t= hey are not really OAuth 2.0 compliant. Great. Now what? 600 million people= will stop using Facebook? > > You've been told clearly that the three largest consumer web companies (b= y audience): Yahoo!, Facebook, and Google, are all going to ignore a MUST i= f this is what we are going to specify. Either you just don't care producin= g a document that the three biggest players on the web ignore, or you kiddi= ng yourself that they will all commit business suicide and enforce it - for= cing their developers to produce unusable client applications (and that cli= ent developers will go along with it, wasting time on unusable products). > > The world doesn't get any safer with this language, but the spec gets fur= ther away from reality and we all know what a slippery slope that is when i= mplementation and standards start drifting apart. > > Our job is to fully document any security shortcoming we are aware of. A = SHOULD does just that and is perfectly reasonable. > > EHL > > > > > > > > > From jricher@mitre.org Tue Apr 5 06:23:03 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379C328C101 for ; Tue, 5 Apr 2011 06:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.057 X-Spam-Level: X-Spam-Status: No, score=-5.057 tagged_above=-999 required=5 tests=[AWL=1.542, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHj+2705TUEY for ; Tue, 5 Apr 2011 06:22:56 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 2033528C0FE for ; Tue, 5 Apr 2011 06:22:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 081FA21B1018; Tue, 5 Apr 2011 09:24:39 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 00A8221B01D1; Tue, 5 Apr 2011 09:24:39 -0400 (EDT) Received: from [129.83.50.23] (129.83.50.23) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Tue, 5 Apr 2011 09:24:38 -0400 From: Justin Richer To: Phil Hunt In-Reply-To: References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <1301947797.31750.53.camel@ground> Content-Type: text/plain; charset="UTF-8" Date: Tue, 5 Apr 2011 09:24:51 -0400 Message-ID: <1302009891.31750.1113.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 13:23:03 -0000 Phil, It's completely within the normative language of the spec to do things this way right now -- the question is how the editorial text surrounding the normative text presents different flows and use cases and how to map between them. As it's written in the latest drafts, it sounds like the implicit flow is the best option for native clients, but that doesn't match with current and planned deployments. -- Justin On Mon, 2011-04-04 at 16:59 -0400, Phil Hunt wrote: > Does section 3.2 help you? > "In addition, the authorization server MAY allow unauthenticated access token requests when the client identity does not matter (e.g. anonymous client) or when the client identity is established via other means." > > Phil > phil.hunt@oracle.com > > > > > On 2011-04-04, at 1:09 PM, Justin Richer wrote: > > > Agreed - we are planning to use the auth-code flow for native apps and > > have no immediate plans to use implicit mode for native clients, either. > > We'd be using the auth-code flow with a client id only and no client > > secret, which I think is the pattern that everyone else is planning to > > follow. > > > > -- justin > > > > On Mon, 2011-04-04 at 14:54 -0400, Skylar Woodward wrote: > >> I agree with Marius' points. We plan to support the auth-code flow for native apps as well. There is no reason why native apps can't perform a successful auth-code flow, they just do so without client credentials. However, the spec doesn't make it clear that this is viable option. > >> > >> skylar > >> > >> > >> On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote: > >> > >>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wrote: > >>>> A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once. > >>>> > >>>> What is the best profile to use for an app that can't have a client secret and needs a refresh token or a long lived access token? > >>> > >>> The authorization code grant, aka web server flow. > >>> > >>> The spec is misleading in this respect IMO. > >>> > >>> Marius > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > From phil.hunt@oracle.com Tue Apr 5 07:54:31 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE19F28C0DE for ; Tue, 5 Apr 2011 07:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.835 X-Spam-Level: X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX5RhRuwgGj6 for ; Tue, 5 Apr 2011 07:54:22 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A83A63A6939 for ; Tue, 5 Apr 2011 07:54:17 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p35Etw6Y009353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2011 14:55:59 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p35Etv1c009956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 14:55:57 GMT Received: from abhmt016.oracle.com (abhmt016.oracle.com [141.146.116.25]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p35EtuO7000577; Tue, 5 Apr 2011 09:55:56 -0500 Received: from [192.168.1.136] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Apr 2011 07:55:54 -0700 References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <1301947797.31750.53.camel@ground> <1302009891.31750.1113.camel@ground> In-Reply-To: <1302009891.31750.1113.camel@ground> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Type: text/plain; charset=us-ascii Message-Id: <1F15EE2D-EF72-4097-9EEE-B4DBD4B9610B@oracle.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8G4) From: Phillip Hunt Date: Tue, 5 Apr 2011 07:55:51 -0700 To: Justin Richer X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4D9B2D7D.0146:SCFSTAT5015188,ss=1,fgs=0 Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:54:31 -0000 Yes agreed. The way I read it any flow can omit client credential if they ha= ve another means to identify it.=20 Phil Sent from my phone.=20 On 2011-04-05, at 6:24, Justin Richer wrote: > Phil, >=20 > It's completely within the normative language of the spec to do things > this way right now -- the question is how the editorial text surrounding > the normative text presents different flows and use cases and how to map > between them. As it's written in the latest drafts, it sounds like the > implicit flow is the best option for native clients, but that doesn't > match with current and planned deployments. >=20 > -- Justin >=20 > On Mon, 2011-04-04 at 16:59 -0400, Phil Hunt wrote: >> Does section 3.2 help you? >> "In addition, the authorization server MAY allow unauthenticated access t= oken requests when the client identity does not matter (e.g. anonymous clien= t) or when the client identity is established via other means." >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-04-04, at 1:09 PM, Justin Richer wrote: >>=20 >>> Agreed - we are planning to use the auth-code flow for native apps and >>> have no immediate plans to use implicit mode for native clients, either.= >>> We'd be using the auth-code flow with a client id only and no client >>> secret, which I think is the pattern that everyone else is planning to >>> follow. >>>=20 >>> -- justin >>>=20 >>> On Mon, 2011-04-04 at 14:54 -0400, Skylar Woodward wrote: >>>> I agree with Marius' points. We plan to support the auth-code flow for n= ative apps as well. There is no reason why native apps can't perform a succ= essful auth-code flow, they just do so without client credentials. However,= the spec doesn't make it clear that this is viable option. >>>>=20 >>>> skylar >>>>=20 >>>>=20 >>>> On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote: >>>>=20 >>>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden w= rote: >>>>>> A typical iPhone app cannot be shipped with a client secret and right= ly or wrongly users expect to only have to enter their credentials once. >>>>>>=20 >>>>>> What is the best profile to use for an app that can't have a client s= ecret and needs a refresh token or a long lived access token? >>>>>=20 >>>>> The authorization code grant, aka web server flow. >>>>>=20 >>>>> The spec is misleading in this respect IMO. >>>>>=20 >>>>> Marius >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 From cmortimore@salesforce.com Tue Apr 5 07:56:11 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A4E3A67FB for ; Tue, 5 Apr 2011 07:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA4h8tpbhrjT for ; Tue, 5 Apr 2011 07:56:04 -0700 (PDT) Received: from exprod8og108.obsmtp.com (exprod8og108.obsmtp.com [64.18.3.96]) by core3.amsl.com (Postfix) with SMTP id F33AF3A693F for ; Tue, 5 Apr 2011 07:56:03 -0700 (PDT) Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob108.postini.com ([64.18.7.12]) with SMTP ID DSNKTZst6kMq+Wo2EvD7kcm2jt1OJR+nOR8C@postini.com; Tue, 05 Apr 2011 07:57:47 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Tue, 5 Apr 2011 07:57:46 -0700 From: Chuck Mortimore To: Justin Richer Date: Tue, 5 Apr 2011 07:57:44 -0700 Thread-Topic: [OAUTH-WG] Flowchart for legs of OAuth Thread-Index: AcvzodKTL2zSCqjxQJqRXy+sNZadmg== Message-ID: References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <1301947797.31750.53.camel@ground> <1302009891.31750.1113.camel@ground> In-Reply-To: <1302009891.31750.1113.camel@ground> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:56:11 -0000 In respect to current deployments we have a pretty broad deployment of diff= erent clients using implicit grant. We also support the code flow as descr= ibed here, but haven't found good reason to use it. =20 - cmort On Apr 5, 2011, at 6:24 AM, "Justin Richer" wrote: > Phil, >=20 > It's completely within the normative language of the spec to do things > this way right now -- the question is how the editorial text surrounding > the normative text presents different flows and use cases and how to map > between them. As it's written in the latest drafts, it sounds like the > implicit flow is the best option for native clients, but that doesn't > match with current and planned deployments. >=20 > -- Justin >=20 > On Mon, 2011-04-04 at 16:59 -0400, Phil Hunt wrote: >> Does section 3.2 help you? >> "In addition, the authorization server MAY allow unauthenticated access = token requests when the client identity does not matter (e.g. anonymous cli= ent) or when the client identity is established via other means." >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-04-04, at 1:09 PM, Justin Richer wrote: >>=20 >>> Agreed - we are planning to use the auth-code flow for native apps and >>> have no immediate plans to use implicit mode for native clients, either= . >>> We'd be using the auth-code flow with a client id only and no client >>> secret, which I think is the pattern that everyone else is planning to >>> follow. >>>=20 >>> -- justin >>>=20 >>> On Mon, 2011-04-04 at 14:54 -0400, Skylar Woodward wrote: >>>> I agree with Marius' points. We plan to support the auth-code flow for= native apps as well. There is no reason why native apps can't perform a s= uccessful auth-code flow, they just do so without client credentials. Howe= ver, the spec doesn't make it clear that this is viable option. >>>>=20 >>>> skylar >>>>=20 >>>>=20 >>>> On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote: >>>>=20 >>>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden = wrote: >>>>>> A typical iPhone app cannot be shipped with a client secret and righ= tly or wrongly users expect to only have to enter their credentials once. >>>>>>=20 >>>>>> What is the best profile to use for an app that can't have a client = secret and needs a refresh token or a long lived access token? >>>>>=20 >>>>> The authorization code grant, aka web server flow. >>>>>=20 >>>>> The spec is misleading in this respect IMO. >>>>>=20 >>>>> Marius >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From zachary.zeltsan@alcatel-lucent.com Tue Apr 5 08:12:39 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0509B3A6949 for ; Tue, 5 Apr 2011 08:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 546oG4jBsH6d for ; Tue, 5 Apr 2011 08:12:38 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id CAE6B3A680D for ; Tue, 5 Apr 2011 08:12:37 -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 p35FEIVI017640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2011 10:14:19 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p35FEIvm012093 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Apr 2011 10:14:18 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 5 Apr 2011 10:14:18 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'torsten@lodderstedt.net'" , Skylar Woodward Date: Tue, 5 Apr 2011 10:14:17 -0500 Thread-Topic: Re: [OAUTH-WG] Flowchart for legs of OAuth Thread-Index: AcvzUHUXqXeCWhZOS9OZUHVWGT24OQAUUvsg Message-ID: <5710F82C0E73B04FA559560098BF95B12505F041B7@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> In-Reply-To: <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 15:12:39 -0000 +1 for making the specification clear. It should say that the native applic= ation clients participating in the authorization code flow do not use the c= lient secrets.=20 Zachary -----Original Message----- From: torsten@lodderstedt.net [mailto:torsten@lodderstedt.net]=20 Sent: Tuesday, April 05, 2011 1:15 AM To: Skylar Woodward Cc: Zeltsan, Zachary (Zachary); Kris Selden; oauth@ietf.org Subject: AW: Re: [OAUTH-WG] Flowchart for legs of OAuth Hi Skylar, Thank you for sharing this information with us. Some thougts: The empty string makes your implementation syntactically compliant but does= obviously not comply with its semantics and the security considerations/ex= pectations associated with a secret. Moreover, what about interoperability?= =20 I think not using secrets for such clients is the honest solution. We can j= ust change the spec's text to express what we think is the right way. regards, Torsten. Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland =20 -----Original Message----- From: Skylar Woodward Date: Mon, 4 Apr 2011 19:14:53=20 To: Torsten Lodderstedt Cc: Zeltsan, Zachary (Zachary); Kris Se= lden; oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth In our implementation (not yet public) we accept the empty string ("") as t= he value for clients not issued secrets. While this was done to simplify th= e interface and implementation, it would make it compliant in my view. In = this case, the authorization server is validating the credentials, which ar= e the client ID and the empty string, which is equivalent security-wise to = any other length of "secret" issued to a native client. Besides, for many providers, the client credentials will only be a client I= D. They would plan to secure all exchanges over TLS and credentials serve j= ust as a tracking device or at best, a weak form of identification. skylar On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote: > Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): >> According to section "6 Refreshing an Access Token" (-13.txt), client wh= en making a request for exchanging a refresh token for an access token has = to include its authentication credentials, and the "authorization server MU= ST validate the client credentials". >> How can this be done if a client is an application that can't have a cli= ent secret? >> The authorization code grant does require client authentication (per sec= tion 4.1): >>=20 >> (D) The client requests an access token from the authorization >> server's token endpoint by authenticating using its client >> credentials, and includes the authorization code received in the >> previous step. >>=20 >> It appears that the clients that cannot keep its secret cannot use (be i= ssued) the refresh tokens. >=20 > In my opinion, this part of the spec is misleading. Authorization code MU= ST be possible without client authentication. Otherwise, OAuth is useless f= or native apps. >=20 > http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations= -01#section-2.10 describes how the flow can be protected in such cases. >=20 > regards, > Torsten. >> Zachary >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f Marius Scurtescu >> Sent: Monday, April 04, 2011 2:30 PM >> To: Kris Selden >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>=20 >> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wro= te: >>> A typical iPhone app cannot be shipped with a client secret and rightly= or wrongly users expect to only have to enter their credentials once. >>>=20 >>> What is the best profile to use for an app that can't have a client sec= ret and needs a refresh token or a long lived access token? >> The authorization code grant, aka web server flow. >>=20 >> The spec is misleading in this respect IMO. >>=20 >> Marius >>_______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>_______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From pathogenix@gmail.com Tue Apr 5 09:08:32 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6896728C11D; Tue, 5 Apr 2011 09:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix4cAqaafa5k; Tue, 5 Apr 2011 09:08:30 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 4E2BF28C0DE; Tue, 5 Apr 2011 09:08:30 -0700 (PDT) Received: by qyk29 with SMTP id 29so1760871qyk.10 for ; Tue, 05 Apr 2011 09:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tAnIT6vUhE9Qgk3RwqiQYqL7tpokYYxGP+lLiyF7rYk=; b=JV/u0LrNMgdT9gqAkgwf939QNlPxfbnTnuFubo0hi/jof8/fRBYEnt9STlIHTHsR8t sDMTd7KQJLLLzApqb4nFBzgL8dofO0+jq2RtpJKVHvyADAbh4sz/ElNarqGrtHfk144f fL6xxvCH/4wlxoz2akUsKn5TUSZSdYDPlsJqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=usa+Td6yCKjiI3yGJLppH95cMcWNt8AnRVJ0GE1oxZIGWum03Vaa8wNz2tu/fxa+hD 2lgHN3pqRjSK8v+aRfvNkmTCg445z59J6cg5UVL0jH2OhI9wSByWxQifOQU0YqKpG12k idhVz+hl/W19vlX8GzWQsDTeBEgImxidJgV3k= MIME-Version: 1.0 Received: by 10.229.8.194 with SMTP id i2mr7596657qci.190.1302019812859; Tue, 05 Apr 2011 09:10:12 -0700 (PDT) Received: by 10.229.11.136 with HTTP; Tue, 5 Apr 2011 09:10:12 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252BA221@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943252B2BB6@TK5EX14MBXC203.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943252BA221@TK5EX14MBXC203.redmond.corp.microsoft.com> Date: Tue, 5 Apr 2011 17:10:12 +0100 Message-ID: From: Bob Gregory To: Mike Jones Content-Type: multipart/alternative; boundary=0016e64986486f9ebf04a02e1c0d Cc: "openid-specs-ab@lists.openid.net" , "woes@ietf.org" , "oauth@ietf.org" , "openid-specs@lists.openid.net" Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Draft -04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 16:08:32 -0000 --0016e64986486f9ebf04a02e1c0d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mike, I'm going to start implementing draft 4 in the near future. At a cursory reading, I'm concerned that splitting the specifications has not simplified the language, rather it has confused the specification, and introduced generalisation where there were formerly simple, specific cases. If the long-term intent is that JWS and JWE should form composable operations for signing and encrypting content, while JWT specifies a payloa= d format, then the specifications should be more clearly delineated. The current JWT draft makes repeated references to headers and signatures, and includes an appendix entry giving examples of signing. If JWS is the specification for signing, then the JWT draft should drop these sections. JWT then becomes a teeny-weeny specification consisting of an overview, a table for reserved claim names, the rules for verifying those claims, and some notes on creating custom claims. Likewise, if JWS is intended to be a general mechanism for signing messages= , it would be preferable to see examples in the JWS spec which do not refer t= o the JWT spec. Simple strings, or base64 encoded binary would make better examples for JWS, without coupling the two specifications together. As it stands, it's impossible to implement JWT without continual cross-reference. It's much harder to gain a sense of how an implementation ought to hang together than it used to be. It's still possible for Jwt4net to be a compliant implementation of JWT without supporting a generalised JWS implementation, but checking complianc= e is going to be much harder. I think the next steps for the library, once I've fixed a couple of glaring holes, will be to refactor out a full JWS implementation, and treat JWT as a special case, but that adds accidental complexity to what was a relatively simple library (barring my own over-complication through stupidity). I'm still a big fan of JWT as a standard, but I think the current spec language is a step backwards for implementation. -- Bob Gregory On Wed, Mar 30, 2011 at 4:37 PM, Mike Jones wr= ote: > Thanks, Bob. That=92s great to hear! > > > > I look forward to your feedback on the spec based upon your actual use. > > > > -- Mike > > > > *From:* Bob Gregory [mailto:pathogenix@gmail.com] > *Sent:* Wednesday, March 30, 2011 8:36 AM > *To:* Mike Jones > *Cc:* woes@ietf.org; oauth@ietf.org; openid-specs-ab@lists.openid.net; > openid-specs@lists.openid.net > > *Subject:* Re: [OAUTH-WG] JSON Web Token (JWT) Draft -04 > > > > I've just uploaded a .Net implementation of JWT issuance and consumption = to > GitHub @ https://github.com/BobFromHuddle/Jwt4Net > > > > This is no way ready for public release, but is in use in a production > system. It's based on draft 1, and I'll try and update it to draft 4 > compliance next week. > > > > We're intending to provide full coverage of the JWT spec as it matures, > the major block for us at the moment is the lack of a specification for t= he > "jku" key encoding scheme. Until that's decided, we're using .Net's defau= lt > serialization of private keys which is based on RFC 4050. > > > > -- Bob Gregory > > > > On Wed, Mar 30, 2011 at 9:57 AM, Mike Jones > wrote: > > Draft -04 of the JSON Web Token (JWT)specification is available. It corrects a typo f= ound by John Bradley in > -03. > > > > The draft is available at these locations: > > =B7 > http://www.ietf.org/internet-drafts/draft-jones-json-web-token-04.txt > > =B7 > http://www.ietf.org/internet-drafts/draft-jones-json-web-token-04.xml > > =B7 http://self-issued.info/docs/draft-jones-json-web-token-04.htm= l > > =B7 http://self-issued.info/docs/draft-jones-json-web-token-04.txt > > =B7 http://self-issued.info/docs/draft-jones-json-web-token-04.xml > > =B7 http://self-issued.info/docs/draft-jones-json-web-token.html(w= ill point to new versions as they are posted) > > =B7 http://self-issued.info/docs/draft-jones-json-web-token.txt (w= ill > point to new versions as they are posted) > > =B7 http://self-issued.info/docs/draft-jones-json-web-token.xml (w= ill > point to new versions as they are posted) > > =B7 http://svn.openid.net/repos/specifications/json_web_token/1.0/= (Subversion repository, with html, txt, and html versions available) > > > > -- Mike > > > > > > > -- > An infinite number of mathematicians walk into a bar. The first one order= s > a beer. The second orders half a beer. The third, a quarter of a beer. Th= e > bartender says "You're all idiots", and pours two beers. > --=20 An infinite number of mathematicians walk into a bar. The first one orders = a beer. The second orders half a beer. The third, a quarter of a beer. The bartender says "You're all idiots", and pours two beers. --0016e64986486f9ebf04a02e1c0d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Mike,

I'm going to start implementing = draft 4 in the near future. At a cursory reading, I'm concerned that sp= litting the specifications has not simplified the language, rather it has c= onfused the specification, and introduced generalisation where there were f= ormerly simple, specific cases.

If the long-term intent is that JWS and JWE should form= composable operations for signing and encrypting content, while JWT specif= ies a payload format, then the specifications should be more clearly deline= ated. The current JWT draft makes repeated references to headers and signat= ures, and includes an appendix entry giving examples of signing. If JWS is = the specification for signing, then the JWT draft should drop these section= s.

JWT then becomes a teeny-weeny specification consisting= of an overview, a table for reserved claim names, the rules for verifying = those claims, and some notes on creating custom claims.=A0

Likewise, if JWS is intended to be a general mechanism for signi= ng messages, it would be preferable to see examples in the JWS spec which d= o not refer to the JWT spec. Simple strings, or base64 encoded binary would= make better examples for JWS, without coupling the two specifications toge= ther.

As it stands, it's impossible to implement JWT with= out continual cross-reference. It's much harder to gain a sense of how = an implementation ought to hang together than it used to be.

It's still possible for Jwt4net to be a compliant implem= entation of JWT without supporting a generalised JWS implementation, but ch= ecking compliance is going to be much harder. I think the next steps for th= e library, once I've fixed a couple of glaring holes, will be to refact= or out a full JWS implementation, and treat JWT as a special case, but that= adds accidental complexity to what was a relatively simple library (barrin= g my own over-complication through stupidity).

I'm still a big fan of JWT as a standard, but I thi= nk the current spec language is a step backwards for implementation.
<= div>
=A0-- Bob Gregory

On= Wed, Mar 30, 2011 at 4:37 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thank= s, Bob.=A0 That=92s great to hear!

=A0

I loo= k forward to your feedback on the spec based upon your actual use.

=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:= Bob Gregory [mailto:pathogenix@gmail.com]
Sent: Wednesday, March 30, 2011 8:36 AM
To: Mike Jones
Cc: woes@ietf.org= ; oauth@ietf.org; op= enid-specs-ab@lists.openid.net; openid-specs@lists.openid.net


Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Draft -04

=A0

I've just uploaded a .Net implementation of JWT = issuance and consumption to GitHub @=A0https://github.com/BobFromHuddle/Jwt4Net=

=A0

This is no way ready for public release, but is in u= se in a production system. It's based on draft 1, and I'll try and = update it to draft 4 compliance next week.

=A0

We're intending to provide full coverage of =A0t= he JWT spec as it matures, the major block for us at the moment is the lack= of a specification for the "jku" key encoding scheme. Until that= 's decided, we're using .Net's default serialization of private keys which is based on RFC 4050.

=A0

=A0-- Bob Gregory

=A0

On Wed, Mar 30, 2011 at 9:57 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Draft -04 of the JSON Web Token (JWT) specification is available.=A0 It corrects a typo = found by John Bradley in -03.

=A0

The draft is available at these locations:

=B7=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/internet-drafts/draft-j= ones-json-web-token-04.txt

=B7=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/internet-drafts/draft-j= ones-json-web-token-04.xml

=B7=A0=A0=A0=A0=A0=A0=A0 http://self-issued.info/docs/draft-jones-json-web= -token-04.html

=B7=A0=A0=A0=A0=A0=A0=A0 http://self-issued.info/docs/draft-jones-json-web-= token-04.txt

=B7=A0=A0=A0=A0=A0=A0=A0 http://self-issued.info/docs/draft-jones-json-web-= token-04.xml

=B7=A0=A0=A0=A0=A0=A0=A0 http://self-issued.info/docs/draft-jones-json-web-to= ken.html (will point to new versions as they are posted)

=B7=A0=A0=A0=A0=A0=A0=A0 http://self-issued.info/docs/draft-jones-json-web-tok= en.txt (will point to new versions as they are posted)

=B7=A0=A0=A0=A0=A0=A0=A0 http://self-issued.info/docs/draft-jones-json-web-tok= en.xml (will point to new versions as they are posted)

=B7=A0=A0=A0=A0=A0=A0=A0 http://svn.openid.net/repos/specifications/json_we= b_token/1.0/ (Subversion repository, with html, txt, and html versions = available)

=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




--
An infinite number of mathematicians walk into a bar. The first one orders = a beer. The second orders half a beer. The third, a quarter of a beer. The = bartender says "You're all idiots", and pours two beers.




--
An infinite number of m= athematicians walk into a bar. The first one orders a beer. The second orde= rs half a beer. The third, a quarter of a beer. The bartender says "Yo= u're all idiots", and pours two beers.
--0016e64986486f9ebf04a02e1c0d-- From Michael.Jones@microsoft.com Tue Apr 5 10:54:25 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73F1228C13C; Tue, 5 Apr 2011 10:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.284 X-Spam-Level: X-Spam-Status: No, score=-10.284 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDPP9jpaZ34w; Tue, 5 Apr 2011 10:54:13 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 0B3BC28C136; Tue, 5 Apr 2011 10:54:12 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Apr 2011 10:55:55 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.38]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0270.002; Tue, 5 Apr 2011 10:55:55 -0700 From: Mike Jones To: Bob Gregory Thread-Topic: [OAUTH-WG] JSON Web Token (JWT) Draft -04 Thread-Index: AcvuuIVAmFKf4FToR3mJsYxJZdQlsgAckiCAAA6ifnABIFFvAAALoptQ Date: Tue, 5 Apr 2011 17:55:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252CCB0C@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943252B2BB6@TK5EX14MBXC203.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943252BA221@TK5EX14MBXC203.redmond.corp.microsoft.com> 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.72] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252CCB0CTK5EX14MBXC203r_" MIME-Version: 1.0 Cc: "openid-specs-ab@lists.openid.net" , "woes@ietf.org" , "oauth@ietf.org" , "openid-specs@lists.openid.net" Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Draft -04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 17:54:25 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252CCB0CTK5EX14MBXC203r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the candid feedback, Bob. I agree that the specs can be more cl= early delineated and I'll make that an editorial goal in the next round of = revisions. In particular, I agree that a non-JWT example should be added t= o the JWS spec. I intentionally kept complete JWT examples in the JWT spec, including examp= les of the actual signing computations, so that people can verify that thei= r JWT implementations are compatible with these values. But I'd be open to= input on how complete these examples should be, versus those in the JWS sp= ec (which describe all the signing steps in full detail, unlike the JWT dra= ft). -- Mike From: Bob Gregory [mailto:pathogenix@gmail.com] Sent: Tuesday, April 05, 2011 9:10 AM To: Mike Jones Cc: woes@ietf.org; oauth@ietf.org; openid-specs-ab@lists.openid.net; openid= -specs@lists.openid.net Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Draft -04 Hi Mike, I'm going to start implementing draft 4 in the near future. At a cursory re= ading, I'm concerned that splitting the specifications has not simplified t= he language, rather it has confused the specification, and introduced gener= alisation where there were formerly simple, specific cases. If the long-term intent is that JWS and JWE should form composable operatio= ns for signing and encrypting content, while JWT specifies a payload format= , then the specifications should be more clearly delineated. The current JW= T draft makes repeated references to headers and signatures, and includes a= n appendix entry giving examples of signing. If JWS is the specification fo= r signing, then the JWT draft should drop these sections. JWT then becomes a teeny-weeny specification consisting of an overview, a t= able for reserved claim names, the rules for verifying those claims, and so= me notes on creating custom claims. Likewise, if JWS is intended to be a general mechanism for signing messages= , it would be preferable to see examples in the JWS spec which do not refer= to the JWT spec. Simple strings, or base64 encoded binary would make bette= r examples for JWS, without coupling the two specifications together. As it stands, it's impossible to implement JWT without continual cross-refe= rence. It's much harder to gain a sense of how an implementation ought to h= ang together than it used to be. It's still possible for Jwt4net to be a compliant implementation of JWT wit= hout supporting a generalised JWS implementation, but checking compliance i= s going to be much harder. I think the next steps for the library, once I'v= e fixed a couple of glaring holes, will be to refactor out a full JWS imple= mentation, and treat JWT as a special case, but that adds accidental comple= xity to what was a relatively simple library (barring my own over-complicat= ion through stupidity). I'm still a big fan of JWT as a standard, but I think the current spec lang= uage is a step backwards for implementation. -- Bob Gregory On Wed, Mar 30, 2011 at 4:37 PM, Mike Jones > wrote: Thanks, Bob. That's great to hear! I look forward to your feedback on the spec based upon your actual use. -- Mike From: Bob Gregory [mailto:pathogenix@gmail.com= ] Sent: Wednesday, March 30, 2011 8:36 AM To: Mike Jones Cc: woes@ietf.org; oauth@ietf.org; openid-specs-ab@lists.openid.net; openid-specs@lists.openid.net Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Draft -04 I've just uploaded a .Net implementation of JWT issuance and consumption to= GitHub @ https://github.com/BobFromHuddle/Jwt4Net This is no way ready for public release, but is in use in a production syst= em. It's based on draft 1, and I'll try and update it to draft 4 compliance= next week. We're intending to provide full coverage of the JWT spec as it matures, th= e major block for us at the moment is the lack of a specification for the "= jku" key encoding scheme. Until that's decided, we're using .Net's default = serialization of private keys which is based on RFC 4050. -- Bob Gregory On Wed, Mar 30, 2011 at 9:57 AM, Mike Jones > wrote: Draft -04 of the JSON Web Token (JWT) specification is available. It corrects a typo fo= und by John Bradley in -03. The draft is available at these locations: * http://www.ietf.org/internet-drafts/draft-jones-json-web-token-04.= txt * http://www.ietf.org/internet-drafts/draft-jones-json-web-token-04.= xml * http://self-issued.info/docs/draft-jones-json-web-token-04.html * http://self-issued.info/docs/draft-jones-json-web-token-04.txt * http://self-issued.info/docs/draft-jones-json-web-token-04.xml * http://self-issued.info/docs/draft-jones-json-web-token.html (will= point to new versions as they are posted) * http://self-issued.info/docs/draft-jones-json-web-token.txt (will = point to new versions as they are posted) * http://self-issued.info/docs/draft-jones-json-web-token.xml (will = point to new versions as they are posted) * http://svn.openid.net/repos/specifications/json_web_token/1.0/ (Su= bversion repository, with html, txt, and html versions available) -- Mike -- An infinite number of mathematicians walk into a bar. The first one orders = a beer. The second orders half a beer. The third, a quarter of a beer. The = bartender says "You're all idiots", and pours two beers. -- An infinite number of mathematicians walk into a bar. The first one orders = a beer. The second orders half a beer. The third, a quarter of a beer. The = bartender says "You're all idiots", and pours two beers. --_000_4E1F6AAD24975D4BA5B1680429673943252CCB0CTK5EX14MBXC203r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the candid fee= dback, Bob.  I agree that the specs can be more clearly delineated and= I’ll make that an editorial goal in the next round of revisions.&nbs= p; In particular, I agree that a non-JWT example should be added to the JWS s= pec.

 <= /p>

I intentionally kept comp= lete JWT examples in the JWT spec, including examples of the actual signing= computations, so that people can verify that their JWT implementations are compatible with these values.  But I’d be o= pen to input on how complete these examples should be, versus those in the = JWS spec (which describe all the signing steps in full detail, unlike the J= WT draft).

 <= /p>

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

 <= /p>

From: Bob Greg= ory [mailto:pathogenix@gmail.com]
Sent: Tuesday, April 05, 2011 9:10 AM
To: Mike Jones
Cc: woes@ietf.org; oauth@ietf.org; openid-specs-ab@lists.openid.net;= openid-specs@lists.openid.net
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Draft -04

 

Hi Mike,

 

I'm going to start implementing draft 4 in the near = future. At a cursory reading, I'm concerned that splitting the specificatio= ns has not simplified the language, rather it has confused the specificatio= n, and introduced generalisation where there were formerly simple, specific cases.

 

If the long-term intent is that JWS and JWE should f= orm composable operations for signing and encrypting content, while JWT spe= cifies a payload format, then the specifications should be more clearly del= ineated. The current JWT draft makes repeated references to headers and signatures, and includes an appendix en= try giving examples of signing. If JWS is the specification for signing, th= en the JWT draft should drop these sections.

 

JWT then becomes a teeny-weeny specification consist= ing of an overview, a table for reserved claim names, the rules for verifyi= ng those claims, and some notes on creating custom claims. =

 

Likewise, if JWS is intended to be a general mechani= sm for signing messages, it would be preferable to see examples in the JWS = spec which do not refer to the JWT spec. Simple strings, or base64 encoded = binary would make better examples for JWS, without coupling the two specifications together.

 

As it stands, it's impossible to implement JWT witho= ut continual cross-reference. It's much harder to gain a sense of how an im= plementation ought to hang together than it used to be.

 

It's still possible for Jwt4net to be a compliant im= plementation of JWT without supporting a generalised JWS implementation, bu= t checking compliance is going to be much harder. I think the next steps fo= r the library, once I've fixed a couple of glaring holes, will be to refactor out a full JWS implementation, and t= reat JWT as a special case, but that adds accidental complexity to what was= a relatively simple library (barring my own over-complication through stup= idity).

 

I'm still a big fan of JWT as a standard, but I thin= k the current spec language is a step backwards for implementation.

 

 -- Bob Gregory

 

On Wed, Mar 30, 2011 at 4:37 PM, Mike Jones <Michael.Jones@microsoft.com&= gt; wrote:

Thanks, Bob.  = That’s great to hear!

 <= /o:p>

I look forward to y= our feedback on the spec based upon your actual use.

 <= /o:p>

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

 <= /o:p>

From: Bob Gregory [mailto:pathogenix@gmail.com]
Sent: Wednesday, March 30, 2011 8:36 AM
To: Mike Jones
Cc: woes@ietf.org= ; oauth@ietf.org; openid-specs-ab@lists.openid.net; openid-specs@lists.openid.net


Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Draft -04

 

I've just uploaded a .Net implementation of JWT issuance and consu= mption to GitHub @ https://github.com/BobFromHuddle/Jwt4Net=

 

This is no way ready for public release, but is in use in a produc= tion system. It's based on draft 1, and I'll try and update it to draft 4 c= ompliance next week.

 

We're intending to provide full coverage of  the JWT spec as = it matures, the major block for us at the moment is the lack of a specifica= tion for the "jku" key encoding scheme. Until that's decided, we're using .Net's default serialization of private keys w= hich is based on RFC 4050.

 

 -- Bob Gregory

 

On Wed, Mar 30, 2011 at 9:57 AM, Mike Jones <Michael.Jones@microsoft.com<= /a>> wrote:

Draft -04 of the JSON Web Token (JWT) specification is available.  It corrects a ty= po found by John Bradley in -03.

 

The draft is available at these locations:

·        http://www.ietf.org/internet-drafts/draft-j= ones-json-web-token-04.txt

·        http://www.ietf.org/internet-drafts/draft-j= ones-json-web-token-04.xml

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

·        http://self-issued.info/docs/draft-jones-json-web-= token-04.txt

·        http://self-issued.info/docs/draft-jones-json-web-= token-04.xml

·        http://self-issued.info/docs/draft-jones-json-web-to= ken.html (will point to new versions as they are posted)

·        http://self-issued.info/docs/draft-jones-json-web-tok= en.txt (will point to new versions as they are posted)

·        http://self-issued.info/docs/draft-jones-json-web-tok= en.xml (will point to new versions as they are posted)

·        http://svn.openid.net/repos/specifications/json_we= b_token/1.0/ (Subversion repository, with html, txt, and html versions = available)

 

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

 




--
An infinite number of mathematicians walk into a bar. The first one orders = a beer. The second orders half a beer. The third, a quarter of a beer. The = bartender says "You're all idiots", and pours two beers.




--
An infinite number of mathematicians walk into a bar. The first one orders = a beer. The second orders half a beer. The third, a quarter of a beer. The = bartender says "You're all idiots", and pours two beers.

--_000_4E1F6AAD24975D4BA5B1680429673943252CCB0CTK5EX14MBXC203r_-- From eran@hueniverse.com Tue Apr 5 15:50:15 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9739928C147 for ; Tue, 5 Apr 2011 15:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gat+CJoo0u8c for ; Tue, 5 Apr 2011 15:50:00 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 4A02E3A6811 for ; Tue, 5 Apr 2011 15:50:00 -0700 (PDT) Received: (qmail 27120 invoked from network); 5 Apr 2011 22:51:43 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 Apr 2011 22:51:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 5 Apr 2011 15:51:40 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Tue, 5 Apr 2011 15:51:33 -0700 Thread-Topic: Error registry proposal (round 3) Thread-Index: Acvz2lgK8+BMtZK8RZ2KEzyemyZs+Q== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DED6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664DED6P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Error registry proposal (round 3) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 22:50:15 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DED6P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following is my new proposal, based on Mike Jones' and my earlier propo= sals. It is basically a combination of the two. This proposal does not allow defining new error codes unless another extens= ion is involved (new grant type, request parameter, token type). The reason= for not defining an open ended error registry is that defining new error c= odes for existing implementations is bad for interoperability and can lead = to unexpected results (developers not taking into account receiving a new e= rror when talking to a compliant 2.0 server). We don't have any use cases f= or defining such new errors for the v2 specification. New errors only come = from extensions and must be defined in that context. I have applied to changes to the -14 draft and clearly marked them with [[P= ending Consensus]] so that there is no issue with removing them or changing= them later. --- Add to the error codes list in sections 4.1.2.1 and 4.2.2.1: a 4xx or 5xx HTTP status code (except for 400 and 401) The authorization server MAY set the "error" parameter value to a numerical HTTP status code from the 4xx or 5xx range, with the exception of the 400 (Bad Request) and 401 (Unauthorized) status codes. For example, if the service is temporarily unavailable, the authorization server MAY return an error response with "error" set to "503". Add a new section 8.4: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the token error response (Section 5.2), such error codes MAY be defined. Extension error codes MUST be registered (following the procedures in Section 10.3) if the extension they are used in conjunction with is registered. Additional error codes used with unregistered extensions MAY be registered. Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" should be named "example_invalid". error-code =3D ALPHA *error-char error-char =3D "-" / "." / "_" / DIGIT / ALPHA Add a new section 10.3: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app-ads@tools.ietf.org email address or directly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. 10.3.1. Registration Template Error name: The name requested (e.g., "example"). Error usage location: The location(s) where the error can be used. The possible locations are: authorization code grant error response (Section 4.1.2.1), implicit grant error response (Section 4.2.2.1), or token error response (Section 5.2). Related protocol extension: The name of the extension grant type, access token type, or extension parameter, the error code is used in conjunction with. Change controller: For standards-track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included. Specification document(s): Reference to document that specifies the error code, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required. --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DED6P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The following= is my new proposal, based on Mike Jones’ and my earlier proposals. I= t is basically a combination of the two.

 

This proposal does not all= ow defining new error codes unless another extension is involved (new grant= type, request parameter, token type). The reason for not defining an open = ended error registry is that defining new error codes for existing implemen= tations is bad for interoperability and can lead to unexpected results (dev= elopers not taking into account receiving a new error when talking to a com= pliant 2.0 server). We don't have any use cases for defining such new error= s for the v2 specification. New errors only come from extensions and must b= e defined in that context.

 = ;

I have applied to changes to the -14 dra= ft and clearly marked them with [[Pending Consensus]] so that there is no i= ssue with removing them or changing them later.

 

---

<= p class=3DMsoPlainText> 

Add to = the error codes list in sections 4.1.2.1 and 4.2.2.1:

 

   &n= bsp;     a 4xx or 5xx HTTP status code (except for 400 = and 401)

    &nbs= p;          The authorization = server MAY set the "error" parameter

           = ;    value to a numerical HTTP status code from the 4xx or 5= xx

     &nbs= p;         range, with the exceptio= n of the 400 (Bad Request) and

 =             &nb= sp; 401 (Unauthorized) status codes.  For example, if the

        &= nbsp;      service is temporarily unavailable, the= authorization

   &nbs= p;           server MAY r= eturn an error response with "error" set to

=

         &nbs= p;     "503".

 

 

Add a new section 8.4:

 

8.4.=
  Defining Additional Error Codes
 
   In cases where protocol extensions (i.e. access token =
types,
  =
 extension parameters, or extension grant types) require additional
   error codes t=
o be used with the authorization code grant error
   response (Section 4.1.2.1), the= implicit grant error response
   (Section 4.2.2.1), or the token error response (Se=
ction 5.2), such
&n=
bsp;  error codes MAY be defined.
 
   Extension error codes MUST be registered (following th=
e procedures in
&nb=
sp;  Section 10.3) if the extension they are used in conjunction with =
is
   reg=
istered.  Additional error codes used with unregistered extensions
   MAY be re=
gistered.
&nbs=
p;
   Error co=
des MUST conform to the error-code ABNF, and SHOULD be
   prefixed by an identifying=
 name when possible.  For example, an error
   identifying an invalid value set=
 to the extension parameter "example"
   should be named "example_inv= alid".
&n=
bsp;
 
     error-=
code   =3D ALPHA *error-char
     error-char   =3D &qu=
ot;-" / "." / "_" / DIGIT / ALPHA

 

 

Add a new section 10.3:<= /o:p>

 

10.3.  The OAuth Extensions Error Registry
 
   This specification establishes th= e OAuth extensions error registry.
 
   Additional error codes used together with other protocol =
extensions
 &n=
bsp; (i.e. extension grant types, access token types, or extension
   parameters) ar=
e registered on the advice of one or more Designated
   Experts (appointed by the IE=
SG or their delegate), with a
   Specification Required (using terminology from [RFC=
5226]).  However,
   to allow for the allocation of values prior to publication=
, the
   =
Designated Expert(s) may approve registration once they are satisfied<=
/o:p>
   that such a=
 specification will be published.
 
   Registration requests should be sent to the [TBD]@ietf.or=
g mailing
 &nb=
sp; list for review and comment, with an appropriate subject (e.g.,
   "Request=
 for error code: example"). [[ Note to RFC-EDITOR: The name=

   of the mailing l=
ist should be determined in consultation with the
   IESG and IANA.  Suggested =
name: oauth-ext-review. ]]
 
&nbs=
p;  Within at most 14 days of the request, the Designated Expert(s) wi=
ll
   eit=
her approve or deny the registration request, communicating this=

   decision to the =
review list and IANA.  Denials should include an
   explanation and, if applica=
ble, suggestions as to how to make the
   request successful.
 
   Decisions (or lack thereof) made by the =
Designated Expert can be
   first appealed to Application Area Directors (contactabl=
e using
  =
; app-ads@tools.ietf.org email address or directly by looking up their=

   email addr=
esses on http://www.iesg.org/ website) and, if the
<=
pre>   appellant is not satisfied wit=
h the response, to the full IESG (using
   the iesg@iesg.org mailing list).
 
   IANA should only accept re=
gistry updates from the Designated
   Expert(s), and should direct all requests for=
 registration to the
   review mailing list.
 
10.3.1.  Registration Template
 
   Error name:
      The name requested (e.g., &=
quot;example").
   Error usage location:
      The location(s) where the =
error can be used.  The possible
      locations are: authorizat=
ion code grant error response
      (Section 4.1.2.1), implicit grant=
 error response
&nb=
sp;     (Section 4.2.2.1), or token error response (Sec=
tion 5.2).
 &n=
bsp; Related protocol extension:
      The name of the extension gran=
t type, access token type, or
      extension parameter, the error co=
de is used in conjunction with.
   Change controller:
      For standards-trac=
k RFCs, state "IETF".  For others, give the name<=
/span>
     =
 of the responsible party.  Other details (e.g., postal address,<=
/o:p>
    =
  e-mail address, home page URI) may also be included.
   Specification documen=
t(s):
  &=
nbsp;   Reference to document that specifies the error code, pref=
erably
  =
    including a URI that can be used to retrieve a copy of t=
he
  &nbs=
p;   document.  An indication of the relevant sections may a=
lso be
  =
    included, but is not required.
 
&nb=
sp;
= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DED6P3PW5EX1MB01E_-- From eran@hueniverse.com Tue Apr 5 15:52:54 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA81C28C160 for ; Tue, 5 Apr 2011 15:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrpoJs1fiO2q for ; Tue, 5 Apr 2011 15:52:52 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 5AFFB3A6810 for ; Tue, 5 Apr 2011 15:52:52 -0700 (PDT) Received: (qmail 11812 invoked from network); 5 Apr 2011 22:54:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 5 Apr 2011 22:54:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 5 Apr 2011 15:54:21 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Tue, 5 Apr 2011 15:54:16 -0700 Thread-Topic: Proposed change to OAuth parameters registry Thread-Index: AcvuZWCSoakTm8gYS4ikjcIwP5PMZgFfvg5g Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DED8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723446564305DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723446564305DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664DED8P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed change to OAuth parameters registry X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 22:52:54 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DED8P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Didn't receive any objections to this change. Will apply to -14. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, March 29, 2011 4:14 PM To: OAuth WG Subject: [OAUTH-WG] Proposed change to OAuth parameters registry I would like to make the following change to section 8.2: New request or response parameters for use with the authorization endpoint or the token endpoint are defined and registered in the parameters registry following the procedure in Section 10.2. Parameter names MUST conform to the param-name ABNF and parameter values syntax MUST be well-defined (e.g., using ABNF, or a reference to the syntax of an existing parameter). Unregistered vendor-specific parameter extensions that are not commonly applicable, and are specific to the implementation details of the authorization server where they are used SHOULD utilize a vendor-specific prefix that is not likely to conflict with other registered values (e.g. begin with 'companyname_'). This is a more pragmatic (and less ugly) solution to vendor specific parame= ters. Instead of using the 'x_' prefix, vendors (have and) will use somethi= ng else that is unique to them. For example Facebook uses 'fb_' for many of= their parameters. Feedback requested by 4/1 for inclusion in -14. EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DED8P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Didn’t receive any objections to this change. Will appl= y to -14.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be= half Of Eran Hammer-Lahav
Sent: Tuesday, March 29, 2011 4:14 = PM
To: OAuth WG
Subject: [OAUTH-WG] Proposed change to = OAuth parameters registry

 

I would like to make the fol= lowing change to section 8.2:

 = ;

   New request or response parameters for us=
e with the authorization
   endp=
oint or the token endpoint are defined and registered in the
   parameters registry following the procedure=
 in Section 10.2.
 
   Parameter names MUST conform to the param-=
name ABNF and parameter
   value=
s syntax MUST be well-defined (e.g., using ABNF, or a reference<=
/span>
   to the syntax of an existing parameter).=

 
=
   Unregistered vendor-specific parameter extensions that are not=
 commonly
   applicable, and are=
 specific to the implementation details of the
   authorization server where they are used SHOULD utilize a=

   vendor-specific prefix that =
is not likely to conflict with other 
&nbs=
p;  registered values (e.g. begin with 'companyname_').

 

This is a more pragmatic (and less ugly) solution to vendor specific para= meters. Instead of using the ‘x_’ prefix, vendors (have and) wi= ll use something else that is unique to them. For example Facebook uses = 216;fb_’ for many of their parameters.

 

Feedback requested by 4/1 fo= r inclusion in -14.

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DED8P3PW5EX1MB01E_-- From Internet-Drafts@ietf.org Tue Apr 5 16:15:02 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475C93A699C; Tue, 5 Apr 2011 16:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqCR7GPnj6zk; Tue, 5 Apr 2011 16:15:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 975E13A681B; Tue, 5 Apr 2011 16:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110405231501.7200.64034.idtracker@localhost> Date: Tue, 05 Apr 2011 16:15:01 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 23:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-14.txt Pages : 47 Date : 2011-04-05 The OAuth 2.0 authorization protocol enables granting third-party applications limited access to HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-05160427.I-D@ietf.org> --NextPart-- From mscurtescu@google.com Tue Apr 5 16:27:49 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D833A695A for ; Tue, 5 Apr 2011 16:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.933 X-Spam-Level: X-Spam-Status: No, score=-105.933 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDgyA0giBjfR for ; Tue, 5 Apr 2011 16:27:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C5DD63A67A7 for ; Tue, 5 Apr 2011 16:27:46 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p35NTTpc005061 for ; Tue, 5 Apr 2011 16:29:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302046170; bh=59ioPqB8/e8rEGHqp50nBFepF4g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=wahr4Ah2UA0KxJnb0CAhAHIpA0vAzyM8MsrhzdJJcAZSUWjOdtpAhyDPrDoooTGWh 4YxKBYGah+jzb2A1oHNFw== Received: from gxk8 (gxk8.prod.google.com [10.202.11.8]) by kpbe19.cbf.corp.google.com with ESMTP id p35NTSOw015915 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 5 Apr 2011 16:29:28 -0700 Received: by gxk8 with SMTP id 8so355573gxk.9 for ; Tue, 05 Apr 2011 16:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=z9jvxPAA+tHczLmo0KfvHwl24JGDyvLW05DwfQbEPdc=; b=lRfU8Yw7V+wZRRCCiQXAyThrDCPux+g5beXKJrQ8Yx9n3u+CzaXXxknmAmad0fOwv5 9a8n98VVvkTLLgVkhlmw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=w+MC12pv644DF0u+ccaMIEVVutyhRZSt+Rt83IlnopIMpEmauEfNj53T0jVFiVY+lD XuhbuHc/OfFCWp2JyVUw== Received: by 10.100.15.4 with SMTP id 4mr211905ano.126.1302046168215; Tue, 05 Apr 2011 16:29:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.34.4 with HTTP; Tue, 5 Apr 2011 16:29:08 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664DED6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664DED6@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 5 Apr 2011 16:29:08 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Error registry proposal (round 3) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 23:27:49 -0000 On Tue, Apr 5, 2011 at 3:51 PM, Eran Hammer-Lahav wro= te: > The following is my new proposal, based on Mike Jones=92 and my earlier > proposals. It is basically a combination of the two. Looks good. > This proposal does not allow defining new error codes unless another > extension is involved (new grant type, request parameter, token type). Th= e > reason for not defining an open ended error registry is that defining new > error codes for existing implementations is bad for interoperability and = can > lead to unexpected results (developers not taking into account receiving = a > new error when talking to a compliant 2.0 server). We don't have any use > cases for defining such new errors for the v2 specification. New errors o= nly > come from extensions and must be defined in that context. Isn't this sentence "Additional error codes used with unregistered extensions MAY be registered." contradicting what you are saying above? It seems to open the door to register error codes not associated with a registered extension. Glad to see this issue solved :-) Marius From eran@hueniverse.com Tue Apr 5 16:28:43 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970C73A695A for ; Tue, 5 Apr 2011 16:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vwxHN5-ClMC for ; Tue, 5 Apr 2011 16:28:43 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 03EC93A67A7 for ; Tue, 5 Apr 2011 16:28:42 -0700 (PDT) Received: (qmail 24348 invoked from network); 5 Apr 2011 23:30:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 Apr 2011 23:30:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 5 Apr 2011 16:30:21 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Tue, 5 Apr 2011 16:30:15 -0700 Thread-Topic: Draft -15 Thread-Index: Acvz50bXQAfZXiXoRaWs9mG6D89F5Q== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DEE0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Draft -15 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 23:28:43 -0000 I submitted a new draft (well two, I forgot one change in -14). Open issues= are marked with [[ Pending Consensus ]] are considered unsafe to implement= . Changes: * Many minor editorial changes. * Expanded abstract. * Added note to intro about this being an HTTP-specific protocol. * Additional references to 2616. * Expanded introduction to authorization grant (1.4). * Clarified implicit grant name choice (1.4.2). * Added information about the required 'response_type' parameter in 2.1. * Added restriction not to repeat any request or response parameters. * Changed the authorization endpoint to always require TLS (-15). * Clarified the special case of unauthenticated client (3). * Explicitly defined scope values are case sensitive. * Added (pending consensus) the ability to put HTTP codes in error response= parameters. * Erased note about 'same origin policy' in introduction to Implicit grant = (4.2). * Removed editorial comment about the need for internationalization of user= name and password parameters. * Added error code extensibility and registry (pending consensus). * Adjusted registries process to match RFC5988. * Changed 'Contributors' section to 'Acknowledgements' and added full credi= t dating back to OAuth 1.0. * Added 'Editor's notes' section. Please review the draft and submit comments to the list. There is no curren= t deadline as we are pending the first draft of the security consideration = section before publishing another draft. EHL From Internet-Drafts@ietf.org Tue Apr 5 16:30:05 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA223A695A; Tue, 5 Apr 2011 16:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qcLIurURTev; Tue, 5 Apr 2011 16:30:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AE463A698E; Tue, 5 Apr 2011 16:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110405233002.10514.31011.idtracker@localhost> Date: Tue, 05 Apr 2011 16:30:02 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-15.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 23:30:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-15.txt Pages : 47 Date : 2011-04-05 The OAuth 2.0 authorization protocol enables granting third-party applications limited access to HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-05162115.I-D@ietf.org> --NextPart-- From cmortimore@salesforce.com Tue Apr 5 16:34:17 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199303A699F for ; Tue, 5 Apr 2011 16:34:17 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvrV9-yzvJIA for ; Tue, 5 Apr 2011 16:34:15 -0700 (PDT) Received: from exprod8og103.obsmtp.com (exprod8og103.obsmtp.com [64.18.3.86]) by core3.amsl.com (Postfix) with SMTP id 9780A3A698E for ; Tue, 5 Apr 2011 16:34:15 -0700 (PDT) Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob103.postini.com ([64.18.7.12]) with SMTP ID DSNKTZunXkgdgm4OeD5CsE5LZF4YaQ0Z18G2@postini.com; Tue, 05 Apr 2011 16:35:59 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Tue, 5 Apr 2011 16:35:58 -0700 From: Chuck Mortimore To: Brian Eaton , Phil Hunt Date: Tue, 5 Apr 2011 16:35:55 -0700 Thread-Topic: [OAUTH-WG] Authorization code security issue (reframed) Thread-Index: AcvzC1bWdo+AV86hQSunupx2s8iigwA3t5RG Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9C0F56B1770Ecmortimoresalesforcecom_" MIME-Version: 1.0 Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 23:34:17 -0000 --_000_C9C0F56B1770Ecmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have native clients using the first 3 as well with good success -cmort On 4/4/11 2:00 PM, "Brian Eaton" wrote: On Mon, Apr 4, 2011 at 1:06 PM, Phil Hunt wrote: > Very quickly here is the attack... > 1) Paul starts dance at good Client & good AS, App requests authorizatio= n. Note: outbound call is secure, but returned redirect is not. For the record, we haven't had particular problems with installed apps finding secure callback URLs. We've got mobile clients using the following approaches: - using custom URL schemes. I gather this is forbidden by spec, but it prevents the attack at least. - using https URLs hosted at Google, in a web view Mobile apps watch the URL (you can do this with embedded web views) and read the authorization code that way. - using https URLs hosted at third-party web sites, in a web view These are typically static or very simple web sites that are used just to transfer control back to the mobile app. - using https URLs hosted at Google, in the default browser rather than a web view There are various tricks that you can use to pick up the authorization code from the default browser. They are all ugly, but they work. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C9C0F56B1770Ecmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Authorization code security issue (reframed) We have native = clients using the first 3 as well with good success

-cmort


On 4/4/11 2:00 PM, "Brian Eaton" <beaton@google.com> wrote:

On Mon, Apr 4, 2011 at 1:06 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> Very quickly here is the attack...
> 1) Paul starts dance at good Client & =A0good AS, App requests aut= horization. Note: outbound call is secure, but returned redirect is not.
For the record, we haven't had particular problems with installed apps
finding secure callback URLs.  We've got mobile clients using the
following approaches:

- using custom URL schemes.
   I gather this is forbidden by spec, but it prevents the a= ttack at least.

- using https URLs hosted at Google, in a web view
   Mobile apps watch the URL (you can do this with embedded = web views)
and read the authorization code that way.

- using https URLs hosted at third-party web sites, in a web view
   These are typically static or very simple web sites that = are used
just to transfer control back to the mobile app.

- using https URLs hosted at Google, in the default browser rather
than a web view
    There are various tricks that you can use to pick u= p the
authorization code from the default browser.  They are all ugly, but they work.

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C9C0F56B1770Ecmortimoresalesforcecom_-- From eran@hueniverse.com Tue Apr 5 16:34:32 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9458B3A695A for ; Tue, 5 Apr 2011 16:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VP5f5GhZnXnl for ; Tue, 5 Apr 2011 16:34:32 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 0BEFA3A67A7 for ; Tue, 5 Apr 2011 16:34:32 -0700 (PDT) Received: (qmail 26827 invoked from network); 5 Apr 2011 23:36:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 5 Apr 2011 23:36:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 5 Apr 2011 16:36:01 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Tue, 5 Apr 2011 16:35:56 -0700 Thread-Topic: [OAUTH-WG] Error registry proposal (round 3) Thread-Index: Acvz6VKMvTGj2NduRH2RtRenLEtAYAAAMrKA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DEE1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664DED6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Error registry proposal (round 3) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 23:34:32 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, April 05, 2011 4:29 PM > Isn't this sentence "Additional error codes used with unregistered extens= ions > MAY be registered." contradicting what you are saying above? It seems to > open the door to register error codes not associated with a registered > extension. What are you, a lawyer? :-) I guess you can find a logical flaw in this. I'll make it more explicit lis= t of extension types... EHL From wmills@yahoo-inc.com Tue Apr 5 17:43:12 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F355F3A69A0 for ; Tue, 5 Apr 2011 17:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUt2nmy75hOd for ; Tue, 5 Apr 2011 17:43:11 -0700 (PDT) Received: from web32303.mail.mud.yahoo.com (web32303.mail.mud.yahoo.com [68.142.207.151]) by core3.amsl.com (Postfix) with SMTP id 039193A6824 for ; Tue, 5 Apr 2011 17:43:10 -0700 (PDT) Received: (qmail 53488 invoked by uid 60001); 6 Apr 2011 00:44:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302050689; bh=5DDveNk+0dEOiw3sWw5sDtNCc2oVTTpTkIj74u1aCGA=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=KJlwjZcRx6CS9QNI37s4zuTaqoMgnQCZJqfVmh4aKU4cW/DrLlUW9QpOlvv1LasHJym/zhBtwmmTlhKUn3brnBsB5hzZ4UnqTJnIp+qFEYu/CJdFyWvD2youyyHeDfQamJgDo/yG3AkFTS4hH3cvmKHpAfzf1kF4Z6xOqoJfwsY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=pAQwmhuoL2Mgwe29/wdG/KNc+v1HZmDNYUDpVZJPAEWxCLujnmHJw/jLz6+B5rQJEHiujNGP1XUSVPC1X/ey0i+XUutSpKEDimqDiWAdO8AIfxdDdwI9Rpx5zn06lKxhnbCnt3weI3qKuo8uPNgdKOgVKeqBNL1hdbpgz7kM4Mg=; Message-ID: <397758.49751.qm@web32303.mail.mud.yahoo.com> X-YMail-OSG: 6P8tOIsVM1mLDJG31PIqy8ENqPZfClVfM.sc6Uu4ch4GqFP _OZqy46cRpLHOyF5.fE3u0Vz738odFJQN6hxW1yUkBfDhUGPQ0MgKb9atoH6 72bzOP6IUP_eAQF2iHpfEn5vRaX2.s_usGIz6kiGUXJOQUZnPINCaGfIrFw0 qu..zJoBVfNFYDG_lhExe7HJ9nzpbP2y20rMX0HMu_8xUxrVbsFFHXwUA_d2 t_NJX60KMwm9vUluPDu01SvrLE0kEYfwSvmT_xTDZaUutbai_UTEMcmojX9Q PWbjn82dxk0f6NRYPEPllNuTseGPmuxk1HKJJp41B7O6nXYgtOWj1lN4TzW5 xu1FEThMaNI6MjGv2B3Vwzovqrx2cLC48rQ2ZS3J0uBlW0w-- Received: from [216.145.53.76] by web32303.mail.mud.yahoo.com via HTTP; Tue, 05 Apr 2011 17:44:49 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <90C41DD21FB7C64BB94121FBBC2E7234465664D9B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <612045.49458.qm@web55805.mail.re3.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234465664DCCA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 5 Apr 2011 17:44:49 -0700 (PDT) From: "William J. Mills" To: OAuth WG In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2058316514-1302050689=:49751" Subject: [OAUTH-WG] Channel binding and OAuth profiles X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 00:43:12 -0000 --0-2058316514-1302050689=:49751 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In working on the SASL mechanism spec for OAuth we have to deal with Channe= l Binding.=A0 Sparing you the gory details there I believe that the right t= hing to do is to add the channel binding information into the tunneled HTTP= /OAuth=A0 authentication.=A0 For those OAuth profiles like MAC and SAML tha= t have shared secrets and signatures the channel binding information should= be added into the signed payload.=A0 Should the deinition of this be in th= e SASL mechanism spec (updating the OAuth profile behavior) or is the right= place for this to have each OAuth profile define how channel binding is ca= rried individually?=0A=0AUsing MAC as a strawman, the only convenient place= ss to add this payload are the body and as an additional query parameter.= =A0 Both of these have drawbacks, of the two I nominally prefer defining a = new query parameter for this case.=A0 The usage in SASL is pretty limited a= t this time, so query parameter will work just fine.=0A=0AGiven OAuth is pr= imarily defined in an HTTP context I don't think I'm stepping on anything b= ecause I doubt anyone else is dealing with Channel Binding.=A0=A0 Mechanism= s that have a shared secret and signing could actually use CB to guarantee = no MITM in an SSL context, which some would argue has significant value.=0A= =0AIf anyone has strong opinions on this topic please let me know.=0A=0ATha= nks,=0A=0A-bill --0-2058316514-1302050689=:49751 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
In working on the SAS= L mechanism spec for OAuth we have to deal with Channel Binding.  Spar= ing you the gory details there I believe that the right thing to do is to a= dd the channel binding information into the tunneled HTTP/OAuth  authe= ntication.  For those OAuth profiles like MAC and SAML that have share= d secrets and signatures the channel binding information should be added in= to the signed payload.  Should the deinition of this be in the SASL me= chanism spec (updating the OAuth profile behavior) or is the right place fo= r this to have each OAuth profile define how channel binding is carried ind= ividually?

Using MAC as a strawman, the only convenient placess to a= dd this payload are the body and as an additional query parameter.  Bo= th of these have drawbacks, of the two I nominally prefer defining a new query parameter for this case.  The usage in SASL is pretty limit= ed at this time, so query parameter will work just fine.

Given OAuth= is primarily defined in an HTTP context I don't think I'm stepping on anyt= hing because I doubt anyone else is dealing with Channel Binding. &nbs= p; Mechanisms that have a shared secret and signing could actually use CB t= o guarantee no MITM in an SSL context, which some would argue has significa= nt value.

If anyone has strong opinions on this topic please let me = know.

Thanks,

-bill





--0-2058316514-1302050689=:49751-- From eran@hueniverse.com Tue Apr 5 17:47:42 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476C13A682A for ; Tue, 5 Apr 2011 17:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fABdSGiD9two for ; Tue, 5 Apr 2011 17:47:37 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 76FA23A6824 for ; Tue, 5 Apr 2011 17:47:37 -0700 (PDT) Received: (qmail 10702 invoked from network); 6 Apr 2011 00:49:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Apr 2011 00:49:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 5 Apr 2011 17:49:20 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , OAuth WG Date: Tue, 5 Apr 2011 17:49:14 -0700 Thread-Topic: [OAUTH-WG] Channel binding and OAuth profiles Thread-Index: Acvz895wvKZpbu6jS8yIpNxZpWF0qAAAG25g Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DEF1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664D9B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <612045.49458.qm@web55805.mail.re3.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234465664DCCA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <397758.49751.qm@web32303.mail.mud.yahoo.com> In-Reply-To: <397758.49751.qm@web32303.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664DEF1P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Channel binding and OAuth profiles X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 00:47:42 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DEF1P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My only uneducated view is that I do not want to deal with this in the MAC = draft (which is being transform into a completely generic HTTP authenticati= on scheme and will move out of this WG with the next draft). Other than tha= t, I don't have an opinion. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of W= illiam J. Mills Sent: Tuesday, April 05, 2011 5:45 PM To: OAuth WG Subject: [OAUTH-WG] Channel binding and OAuth profiles In working on the SASL mechanism spec for OAuth we have to deal with Channe= l Binding. Sparing you the gory details there I believe that the right thi= ng to do is to add the channel binding information into the tunneled HTTP/O= Auth authentication. For those OAuth profiles like MAC and SAML that have= shared secrets and signatures the channel binding information should be ad= ded into the signed payload. Should the deinition of this be in the SASL m= echanism spec (updating the OAuth profile behavior) or is the right place f= or this to have each OAuth profile define how channel binding is carried in= dividually? Using MAC as a strawman, the only convenient placess to add this payload ar= e the body and as an additional query parameter. Both of these have drawba= cks, of the two I nominally prefer defining a new query parameter for this = case. The usage in SASL is pretty limited at this time, so query parameter= will work just fine. Given OAuth is primarily defined in an HTTP context I don't think I'm stepp= ing on anything because I doubt anyone else is dealing with Channel Binding= . Mechanisms that have a shared secret and signing could actually use CB = to guarantee no MITM in an SSL context, which some would argue has signific= ant value. If anyone has strong opinions on this topic please let me know. Thanks, -bill --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DEF1P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My only u= neducated view is that I do not want to deal with this in the MAC draft (wh= ich is being transform into a completely generic HTTP authentication scheme= and will move out of this WG with the next draft). Other than that, I don&= #8217;t have an opinion.

<= o:p> 

EHL

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0= in 0in'>

From: oauth-bounces@ietf.org [mailto:oauth-bounc= es@ietf.org] On Behalf Of William J. Mills
Sent: Tuesday, = April 05, 2011 5:45 PM
To: OAuth WG
Subject: [OAUTH-WG]= Channel binding and OAuth profiles

 

In working o= n the SASL mechanism spec for OAuth we have to deal with Channel Binding.&n= bsp; Sparing you the gory details there I believe that the right thing to d= o is to add the channel binding information into the tunneled HTTP/OAuth&nb= sp; authentication.  For those OAuth profiles like MAC and SAML that h= ave shared secrets and signatures the channel binding information should be= added into the signed payload.  Should the deinition of this be in th= e SASL mechanism spec (updating the OAuth profile behavior) or is the right= place for this to have each OAuth profile define how channel binding is ca= rried individually?

Using MAC as a strawman, the only convenient pla= cess to add this payload are the body and as an additional query parameter.=   Both of these have drawbacks, of the two I nominally prefer defining= a new query parameter for this case.  The usage in SASL is pretty lim= ited at this time, so query parameter will work just fine.

Given OAu= th is primarily defined in an HTTP context I don't think I'm stepping on an= ything because I doubt anyone else is dealing with Channel Binding. &n= bsp; Mechanisms that have a shared secret and signing could actually use CB= to guarantee no MITM in an SSL context, which some would argue has signifi= cant value.

If anyone has strong opinions on this topic please let m= e know.

Thanks,

-bill




= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DEF1P3PW5EX1MB01E_-- From James.H.Manger@team.telstra.com Tue Apr 5 17:49:47 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8664B3A682B for ; Tue, 5 Apr 2011 17:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.831 X-Spam-Level: X-Spam-Status: No, score=-0.831 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDsmDHcAg1-B for ; Tue, 5 Apr 2011 17:49:43 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id BAF613A6824 for ; Tue, 5 Apr 2011 17:49:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,307,1299416400"; d="scan'208,217";a="29592981" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 06 Apr 2011 10:51:25 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6307"; a="23216053" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcdni.tcif.telstra.com.au with ESMTP; 06 Apr 2011 10:51:25 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Wed, 6 Apr 2011 10:51:25 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Wed, 6 Apr 2011 10:51:23 +1000 Thread-Topic: draft-15 editorials Thread-Index: Acvz9MB6KgutpDVYQ4S57m9IkdJP/g== Message-ID: <255B9BB34FB7D647A506DC292726F6E11281BA9188@WSMSG3153V.srv.dir.telstra.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_255B9BB34FB7D647A506DC292726F6E11281BA9188WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] draft-15 editorials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 00:49:47 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11281BA9188WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few, mainly editorial, points on the latest OAuth 2.0 core draft [draft-i= etf-oauth-v2-15]: Abstract: Currently it is: The OAuth 2.0 authorization protocol enables granting third-party applications limited access to HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. This sentence is confusing as to whom is doing the orchestrating. It is an = important OAuth feature that the 3rd-party app does this. Also add "an" bef= ore "HTTP service". The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. 2.1 Authorization Endpoints ...when sending requests to the token endpoints should be ...when sending requests to the authorization endpoint 7.1 Access Token Types I suggest adding the following sentence to the end of the 1st paragraph, ju= st to be sure a security value is not used in the wrong protocol. A client MUST NOT use an access token if it does not understand the toke= n type. 7.1 Access Token Types Use a different access token for the Bearer and MAC examples to avoid any i= mplication that a given token can be used with either method at the client'= s discretion. Perhaps make the example Bearer token a bit longer. The curre= nt example value has at most 72 bits of entropy that doesn't match the 128-= bits required in draft-lodderstedt-oauth-security-01#section-5.1.4.2.2. Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw 7.1 Access Token Types The timestamp value in the MAC example corresponds to a date in 1974! -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E11281BA9188WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A few, mainly editorial, points on the latest OAuth = 2.0 core draft [draft-ietf-oauth-v2-15]:

 

Abstract: Currently it is:

   The OAuth 2.0 authorization protocol enables = granting third-party

   applications limited access to HTTP service o= n behalf of an end-user

   by orchestrating an approval interaction betw= een the end-user and the

   HTTP service.

This sentence is confusing as to whom is doing the o= rchestrating. It is an important OAuth feature that the 3rd-party app does = this. Also add “an” before “HTTP service”.

   The OAuth 2.0 authorization protocol enables = a third-party application

   to obtain limited access to an HTTP service o= n behalf of an end-user

   by orchestrating an approval interaction betw= een the end-user and the

   HTTP service.

 

 

2.1 Authorization Endpoints

  …when sending requests to the token endpoints<=
/pre>

should be


  …when sending requests to the authorization endpoint=



 


 


7.1 Access Token Types


I suggest adding the following sentence to the end o=
f the 1st paragraph, just to be sure a security value is not use=
d in the wrong protocol.


   A client MUST NOT use an access token if it d=
oes not understand the token type.


 


 


7.1 Access Token Types


Use a different access token for the Bearer and MAC =
examples to avoid any implication that a given token can be used with eithe=
r method at the client’s discretion. Perhaps make the example Bearer =
token a bit longer. The current example
 value has at most 72 bits of entropy that doesn’t match the 128-bits=
 required in draft-lodderstedt-oauth-security-01#section-5.1.4.2.2.


   Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw<=
o:p>


 


 


7.1 Access Token Types


The timestamp value in the MAC example corresponds t=
o a date in 1974!


 


 


--


James Manger


 
--_000_255B9BB34FB7D647A506DC292726F6E11281BA9188WSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Tue Apr 5 17:55:21 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9463A682D for ; Tue, 5 Apr 2011 17:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.579 X-Spam-Level: X-Spam-Status: No, score=-10.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ9iKBKogrSu for ; Tue, 5 Apr 2011 17:55:18 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 9DBCC3A67F4 for ; Tue, 5 Apr 2011 17:55:18 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Apr 2011 17:57:01 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.38]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0270.002; Tue, 5 Apr 2011 17:57:01 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: draft-15 editorials Thread-Index: Acvz9MB6KgutpDVYQ4S57m9IkdJP/gAAJryw Date: Wed, 6 Apr 2011 00:57:00 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252CE4F8@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E11281BA9188@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11281BA9188@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252CE4F8TK5EX14MBXC203r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-15 editorials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 00:55:21 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252CE4F8TK5EX14MBXC203r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also, change "which in turns directs" to "which in turn directs". -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Tuesday, April 05, 2011 5:51 PM To: oauth@ietf.org Subject: [OAUTH-WG] draft-15 editorials A few, mainly editorial, points on the latest OAuth 2.0 core draft [draft-i= etf-oauth-v2-15]: Abstract: Currently it is: The OAuth 2.0 authorization protocol enables granting third-party applications limited access to HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. This sentence is confusing as to whom is doing the orchestrating. It is an = important OAuth feature that the 3rd-party app does this. Also add "an" bef= ore "HTTP service". The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. 2.1 Authorization Endpoints ...when sending requests to the token endpoints should be ...when sending requests to the authorization endpoint 7.1 Access Token Types I suggest adding the following sentence to the end of the 1st paragraph, ju= st to be sure a security value is not used in the wrong protocol. A client MUST NOT use an access token if it does not understand the toke= n type. 7.1 Access Token Types Use a different access token for the Bearer and MAC examples to avoid any i= mplication that a given token can be used with either method at the client'= s discretion. Perhaps make the example Bearer token a bit longer. The curre= nt example value has at most 72 bits of entropy that doesn't match the 128-= bits required in draft-lodderstedt-oauth-security-01#section-5.1.4.2.2. Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw 7.1 Access Token Types The timestamp value in the MAC example corresponds to a date in 1974! -- James Manger --_000_4E1F6AAD24975D4BA5B1680429673943252CE4F8TK5EX14MBXC203r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Also, change “wh= ich in turns directs” to “which in turn directs”.

 

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Tuesday, April 05, 2011 5:51 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-15 editorials

 

A few, mainly editorial, points= on the latest OAuth 2.0 core draft [draft-ietf-oauth-v2-15]:

 

Abstract: Currently it is:

   The OAuth 2.0 authorization pr= otocol enables granting third-party

   applications limited access to= HTTP service on behalf of an end-user

   by orchestrating an approval i= nteraction between the end-user and the

   HTTP service.

This sentence is confusing as t= o whom is doing the orchestrating. It is an important OAuth feature that th= e 3rd-party app does this. Also add “an” before “HTTP ser= vice”.

   The OAuth 2.0 authorization pr= otocol enables a third-party application

   to obtain limited access to an= HTTP service on behalf of an end-user

   by orchestrating an approval i= nteraction between the end-user and the

   HTTP service.

 

 

2.1 Authorization Endpoints<= /span>

  …when sending requests to the token =
endpoints

should be

  …when sending requests to the author=
ization endpoint

 

 

7.1 Access Token Types

I suggest adding the following = sentence to the end of the 1st paragraph, just to be sure a secu= rity value is not used in the wrong protocol.

   A client MUST NOT use an acces= s token if it does not understand the token type.

 

 

7.1 Access Token Types

Use a different access token fo= r the Bearer and MAC examples to avoid any implication that a given token c= an be used with either method at the client’s discretion. Perhaps mak= e the example Bearer token a bit longer. The current example value has at most 72 bits of entropy that doesn’t ma= tch the 128-bits required in draft-lodderstedt-oauth-security-01#section-5.= 1.4.2.2.

   Authorization: Bearer 7Fjfp0ZB= r1KtDRbnfVdmIw

 

 

7.1 Access Token Types

The timestamp value in the MAC = example corresponds to a date in 1974!

 

 

--

James Manger<= /p>

 

--_000_4E1F6AAD24975D4BA5B1680429673943252CE4F8TK5EX14MBXC203r_-- From eran@hueniverse.com Tue Apr 5 18:11:24 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205953A682B for ; Tue, 5 Apr 2011 18:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPpuX3aW-5k3 for ; Tue, 5 Apr 2011 18:11:23 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 501313A6828 for ; Tue, 5 Apr 2011 18:11:23 -0700 (PDT) Received: (qmail 12277 invoked from network); 6 Apr 2011 01:13:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Apr 2011 01:13:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 5 Apr 2011 18:13:01 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Tue, 5 Apr 2011 18:12:55 -0700 Thread-Topic: Clarifying my relationship with Yahoo! Thread-Index: Acvz90LsaD1IJc2mQSqB4OZPtDFYGQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DEF3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664DEF3P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Clarifying my relationship with Yahoo! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 01:11:24 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DEF3P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems that some are confused by my role here with respect to representin= g the views of my employer, Yahoo!. I have repeated this on many occasions but for the sake of clarity will do = so again. I am here representing myself alone. I do not speak for my employ= er, and my views do not necessarily match those of my employer. I am not pa= rt of the team at Yahoo! responsible for OAuth implementation, and I do not= set or influence security policy. Any views and objections I raise on this list are my personal views and hav= e absolutely no bearing on my employer. Thanks, EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DEF3P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It seems that so= me are confused by my role here with respect to representing the views of m= y employer, Yahoo!.

 

I have repeated this on many occasions but for the sa= ke of clarity will do so again. I am here representing myself alone. I do n= ot speak for my employer, and my views do not necessarily match those of my= employer. I am not part of the team at Yahoo! responsible for OAuth implem= entation, and I do not set or influence security policy.

 

Any views and ob= jections I raise on this list are my personal views and have absolutely no = bearing on my employer.

 

Thanks,

&= nbsp;

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DEF3P3PW5EX1MB01E_-- From progrium@twilio.com Tue Apr 5 20:41:22 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82CE13A685D for ; Tue, 5 Apr 2011 20:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYR-5U54hgno for ; Tue, 5 Apr 2011 20:41:22 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id AB2953A684F for ; Tue, 5 Apr 2011 20:41:21 -0700 (PDT) Received: by eye13 with SMTP id 13so369179eye.31 for ; Tue, 05 Apr 2011 20:43:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.13.143 with SMTP id b15mr165145eeb.46.1302061384646; Tue, 05 Apr 2011 20:43:04 -0700 (PDT) Received: by 10.14.45.66 with HTTP; Tue, 5 Apr 2011 20:43:04 -0700 (PDT) Date: Tue, 5 Apr 2011 20:43:04 -0700 Message-ID: From: Jeff Lindsay To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=0016365ee3d44ec21804a037cacf Subject: [OAUTH-WG] JWT CLI tool in PyJWT X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 03:41:22 -0000 --0016365ee3d44ec21804a037cacf Content-Type: text/plain; charset=ISO-8859-1 We use JWT a lot and end up needing it while using curl, or needing quick JWT generation... so I added a jwt command line utility in PyJWT. It doesn't support all crypto methods yet (since PyJWT doesn't either), but it has a pretty nice interface for encoding/decoding. You can install it with just "easy_install PyJWT". Here's the usage doc: Usage: jwt [options] input Encodes or decodes JSON Web Tokens based on input Decoding examples: jwt --key=secret json.web.token jwt --no-verify json.web.token Encoding requires the key option and takes space separated key/value pairs separated by equals (=) as input. Examples: jwt --key=secret iss=me exp=1302049071 jwt --key=secret foo=bar exp=+10 The exp key is special and can take an offset to current Unix time. Options: --version show program's version number and exit -h, --help show this help message and exit -n, --no-verify ignore signature verification on decode --key=KEY set the secret key to sign with --alg=ALG set crypto algorithm to sign with. default=HS256 --0016365ee3d44ec21804a037cacf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We use JWT a lot and end up needing it while using curl, or needing quick J= WT generation... so I added a jwt command line utility in PyJWT. It doesn&#= 39;t support all crypto methods yet (since PyJWT doesn't either), but i= t has a pretty nice interface for encoding/decoding.=A0

You can install it with just "easy_install PyJWT".= Here's the usage doc:

Usage: jwt [opt= ions] input

Encodes or decodes JSON Web Tokens bas= ed on input

Decoding examples:

=A0 jwt --k= ey=3Dsecret json.web.token
=A0 jwt --no-verify json.web.token

Encoding requires the key option and takes space sepa= rated key/value pairs
separated by equals (=3D) as input. Examples:

=A0 jwt --key=3Dsecret iss=3Dme exp=3D1302049071
=A0 jwt --key= =3Dsecret foo=3Dbar exp=3D+10

The exp key is speci= al and can take an offset to current Unix time.

Options:
=A0 --version =A0 =A0 =A0 =A0show pr= ogram's version number and exit
=A0 -h, --help =A0 =A0 =A0 sh= ow this help message and exit
=A0 -n, --no-verify =A0ignore signa= ture verification on decode
=A0 --key=3DKEY =A0 =A0 =A0 =A0set the secret key to sign with
=A0 --alg=3DALG =A0 =A0 =A0 =A0set crypto algorithm to sign with. defaul= t=3DHS256
--0016365ee3d44ec21804a037cacf-- From Michael.Jones@microsoft.com Tue Apr 5 21:09:02 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8053A6863; Tue, 5 Apr 2011 21:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3hoB3Xtkn4F; Tue, 5 Apr 2011 21:09:01 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 3DA633A685B; Tue, 5 Apr 2011 21:09:01 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Apr 2011 21:10:44 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.38]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0270.002; Tue, 5 Apr 2011 21:10:44 -0700 From: Mike Jones To: "woes@ietf.org" , "openid-specs-ab@lists.openid.net" Thread-Topic: [OAUTH-WG] JWT CLI tool in PyJWT Thread-Index: AQHL9AzB2shGLxuX70WAQ6bQp/fCHZRQOLWQ Date: Wed, 6 Apr 2011 04:10:44 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252CE74E@TK5EX14MBXC203.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.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252CE74ETK5EX14MBXC203r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: [OAUTH-WG] FW: JWT CLI tool in PyJWT X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 04:09:02 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252CE74ETK5EX14MBXC203r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Distributing to a wider audience) Thanks for letting us know about your implementation, Jeff! -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= eff Lindsay Sent: Tuesday, April 05, 2011 8:43 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] JWT CLI tool in PyJWT We use JWT a lot and end up needing it while using curl, or needing quick J= WT generation... so I added a jwt command line utility in PyJWT. It doesn't= support all crypto methods yet (since PyJWT doesn't either), but it has a = pretty nice interface for encoding/decoding. You can install it with just "easy_install PyJWT". Here's the usage doc: Usage: jwt [options] input Encodes or decodes JSON Web Tokens based on input Decoding examples: jwt --key=3Dsecret json.web.token jwt --no-verify json.web.token Encoding requires the key option and takes space separated key/value pairs separated by equals (=3D) as input. Examples: jwt --key=3Dsecret iss=3Dme exp=3D1302049071 jwt --key=3Dsecret foo=3Dbar exp=3D+10 The exp key is special and can take an offset to current Unix time. Options: --version show program's version number and exit -h, --help show this help message and exit -n, --no-verify ignore signature verification on decode --key=3DKEY set the secret key to sign with --alg=3DALG set crypto algorithm to sign with. default=3DHS256 --_000_4E1F6AAD24975D4BA5B1680429673943252CE74ETK5EX14MBXC203r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Distributing to a wider = audience)

 <= /p>

Thanks for letting us kno= w about your implementation, Jeff!

 <= /p>

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

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Jeff Lindsay
Sent: Tuesday, April 05, 2011 8:43 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] JWT CLI tool in PyJWT

 

We use JWT a lot and end up needing it while using c= url, or needing quick JWT generation... so I added a jwt command line utili= ty in PyJWT. It doesn't support all crypto methods yet (since PyJWT doesn't= either), but it has a pretty nice interface for encoding/decoding. 

 

You can install it with just "easy_install PyJW= T". Here's the usage doc:

 

Usage: jwt [options] input

 

Encodes or decodes JSON Web Tokens based on input

 

Decoding examples:

 

  jwt --key=3Dsecret json.web.token<= /p>

  jwt --no-verify json.web.token

 

Encoding requires the key option and takes space sep= arated key/value pairs

separated by equals (=3D) as input. Examples:

 

  jwt --key=3Dsecret iss=3Dme exp=3D1302049071<= o:p>

  jwt --key=3Dsecret foo=3Dbar exp=3D+10

 

The exp key is special and can take an offset to cur= rent Unix time.

 

Options:

  --version        show pro= gram's version number and exit

  -h, --help       show this hel= p message and exit

  -n, --no-verify  ignore signature verifi= cation on decode

  --key=3DKEY        set th= e secret key to sign with

  --alg=3DALG        set cr= ypto algorithm to sign with. default=3DHS256

--_000_4E1F6AAD24975D4BA5B1680429673943252CE74ETK5EX14MBXC203r_-- From lear@cisco.com Wed Apr 6 02:58:22 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE58528C0DF for ; Wed, 6 Apr 2011 02:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.585 X-Spam-Level: X-Spam-Status: No, score=-110.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mmPAZu0EUhn for ; Wed, 6 Apr 2011 02:58:21 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id B57493A68F1 for ; Wed, 6 Apr 2011 02:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=8001; q=dns/txt; s=iport; t=1302084005; x=1303293605; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=55VMpHwxlvitdIp/Di00psl1jNyKOJIIyKxTFyIEMEk=; b=OzL0d9b7zUckbKkFx6WeSCRURFAU2YIvRTzBJqW4m2UJqdTcWBHdS2vt RfYdqxhMX6omiEmvS91iICDfW8VtMBnsEKojfi2ATZJCuEfYGSNW8On/J yfijWF6MHvdiqOz6LQSnlKMZmhyKar1amTM1cKdfWaAnuswTcO9QKwYPI E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEEAPs4nE2Q/khMgWdsb2JhbACCYIFroSwUAQELCyYlpRyLUJBNhHR4BI06 X-IronPort-AV: E=Sophos;i="4.63,309,1299456000"; d="scan'208,217";a="24629102" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 06 Apr 2011 10:00:04 +0000 Received: from dhcp-10-55-84-129.cisco.com (dhcp-10-55-84-129.cisco.com [10.55.84.129]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p36A03dS030163; Wed, 6 Apr 2011 10:00:03 GMT Message-ID: <4D9C3980.2000609@cisco.com> Date: Wed, 06 Apr 2011 11:59:28 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723446564305DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723446564305DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------030709020808080301060000" Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposed change to OAuth parameters registry X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 09:58:22 -0000 This is a multi-part message in MIME format. --------------030709020808080301060000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sorry for the late comment on this, Eran. I like your idea, but would suggest that better than company name would be domain name or based on domain name (I don't recall if '.' is allowed in this context). Company names are by no means unique, and even within a large company one could envision clashes. Eliot On 3/30/11 1:13 AM, Eran Hammer-Lahav wrote: > > I would like to make the following change to section 8.2: > > > > New request or response parameters for use with the authorization > endpoint or the token endpoint are defined and registered in the > parameters registry following the procedure in Section 10.2 . > > Parameter names MUST conform to the param-name ABNF and parameter > values syntax MUST be well-defined (e.g., using ABNF, or a reference > to the syntax of an existing parameter). > > Unregistered vendor-specific parameter extensions that are not commonly > applicable, and are specific to the implementation details of the > authorization server where they are used SHOULD utilize a > vendor-specific prefix that is not likely to conflict with other > registered values (e.g. begin with 'companyname_'). > > > > This is a more pragmatic (and less ugly) solution to vendor specific > parameters. Instead of using the ‘x_’ prefix, vendors (have and) will > use something else that is unique to them. For example Facebook uses > ‘fb_’ for many of their parameters. > > > > Feedback requested by 4/1 for inclusion in -14. > > > > EHL > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030709020808080301060000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Sorry for the late comment on this, Eran.  I like your idea, but would suggest that better than company name would be domain name or based on domain name (I don't recall if '.' is allowed in this context).  Company names are by no means unique, and even within a large company one could envision clashes.

Eliot

On 3/30/11 1:13 AM, Eran Hammer-Lahav wrote:

I would like to make the following change to section 8.2:

 

   New request or response parameters for use with the authorization
   endpoint or the token endpoint are defined and registered in the
   parameters registry following the procedure in Section 10.2.
 
   Parameter names MUST conform to the param-name ABNF and parameter
   values syntax MUST be well-defined (e.g., using ABNF, or a reference
   to the syntax of an existing parameter).
 
   Unregistered vendor-specific parameter extensions that are not commonly
   applicable, and are specific to the implementation details of the
   authorization server where they are used SHOULD utilize a
   vendor-specific prefix that is not likely to conflict with other 
   registered values (e.g. begin with 'companyname_').

 

This is a more pragmatic (and less ugly) solution to vendor specific parameters. Instead of using the ‘x_’ prefix, vendors (have and) will use something else that is unique to them. For example Facebook uses ‘fb_’ for many of their parameters.

 

Feedback requested by 4/1 for inclusion in -14.

 

EHL


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------030709020808080301060000-- From paul.madsen@gmail.com Wed Apr 6 03:58:19 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1EE3A68FE for ; Wed, 6 Apr 2011 03:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hG01aTIm4gH for ; Wed, 6 Apr 2011 03:58:15 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id F13B73A68C8 for ; Wed, 6 Apr 2011 03:58:14 -0700 (PDT) Received: by gyf3 with SMTP id 3so635096gyf.31 for ; Wed, 06 Apr 2011 03:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=8QPdIE5OTAv+Bc7k7mGboQRMtd0TbnryBmr+rF6FqzM=; b=IMfF7OY7PbG2equi0lPeS9MIAbVI7LMkk8C5A2jRo1iwRpWHrkLYdRyUre04hG2Vah cdaAQj0dQmTBc1hXqJrKvpfe+XFlr6UkL6MWcI8OFoU3lD4qG8Vjf5KwMUCGpJZkcCkJ o15DrgRZG4Xdnv3pigGgDkGxz+IrR6kvP36WE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=G0WgukmSI1Z8mCOpvqNPuJ5k+7gqMruWhgzxqpeQGIQBVTLuc70cdbECvvPyBor9oS 4r9OzF1uMgVKoqN9AbKvoMaKqbjdFwRJrbj4AVXy3pbIC61PoAoivukLFWzvWAEL9ziU j6PkT8zuX4mEkHppeEHES4XvWHwjlx3bF0Og0= Received: by 10.100.16.17 with SMTP id 17mr617215anp.56.1302087597019; Wed, 06 Apr 2011 03:59:57 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id b3sm523200ana.50.2011.04.06.03.59.54 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 03:59:55 -0700 (PDT) Message-ID: <4D9C47A8.30605@gmail.com> Date: Wed, 06 Apr 2011 06:59:52 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: oauth@ietf.org References: <255B9BB34FB7D647A506DC292726F6E11281BA9188@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943252CE4F8@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252CE4F8@TK5EX14MBXC203.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------000104080901080303030004" Subject: Re: [OAUTH-WG] draft-15 editorials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 10:58:19 -0000 This is a multi-part message in MIME format. --------------000104080901080303030004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Can we not acknowledge in the abstract that there are other applications for OAuth beyond the delegated authz scenario? I tell people that OAuth 2 is more a framework than a specific protocol, but the current abstract belies this claim. paul On 4/5/11 8:57 PM, Mike Jones wrote: > > Also, change "which in turns directs" to "which in turn directs". > > -- Mike > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Manger, James H > *Sent:* Tuesday, April 05, 2011 5:51 PM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] draft-15 editorials > > A few, mainly editorial, points on the latest OAuth 2.0 core draft > [draft-ietf-oauth-v2-15]: > > *Abstract*: Currently it is: > > The OAuth 2.0 authorization protocol enables granting third-party > > applications limited access to HTTP service on behalf of an end-user > > by orchestrating an approval interaction between the end-user and the > > HTTP service. > > This sentence is confusing as to whom is doing the orchestrating. It > is an important OAuth feature that the 3rd-party app does this. Also > add "an" before "HTTP service". > > The OAuth 2.0 authorization protocol enables a third-party application > > to obtain limited access to an HTTP service on behalf of an end-user > > by orchestrating an approval interaction between the end-user and the > > HTTP service. > > *2.1 Authorization Endpoints* > > ...when sending requests to the token endpoints > > should be > > ...when sending requests to the authorization endpoint > > *7.1 Access Token Types* > > I suggest adding the following sentence to the end of the 1^st > paragraph, just to be sure a security value is not used in the wrong > protocol. > > A client MUST NOT use an access token if it does not understand the > token type. > > *7.1 Access Token Types* > > Use a different access token for the Bearer and MAC examples to avoid > any implication that a given token can be used with either method at > the client's discretion. Perhaps make the example Bearer token a bit > longer. The current example value has at most 72 bits of entropy that > doesn't match the 128-bits required in > draft-lodderstedt-oauth-security-01#section-5.1.4.2.2. > > Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw > > *7.1 Access Token Types* > > The timestamp value in the MAC example corresponds to a date in 1974! > > -- > > James Manger > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000104080901080303030004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Can we not acknowledge in the abstract that there are other applications for OAuth beyond the delegated authz scenario?

I tell people that OAuth 2 is more a framework than a specific protocol, but the current abstract belies this claim.

paul

On 4/5/11 8:57 PM, Mike Jones wrote:

Also, change “which in turns directs” to “which in turn directs”.

 

                                                                -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Tuesday, April 05, 2011 5:51 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-15 editorials

 

A few, mainly editorial, points on the latest OAuth 2.0 core draft [draft-ietf-oauth-v2-15]:

 

Abstract: Currently it is:

   The OAuth 2.0 authorization protocol enables granting third-party

   applications limited access to HTTP service on behalf of an end-user

   by orchestrating an approval interaction between the end-user and the

   HTTP service.

This sentence is confusing as to whom is doing the orchestrating. It is an important OAuth feature that the 3rd-party app does this. Also add “an” before “HTTP service”.

   The OAuth 2.0 authorization protocol enables a third-party application

   to obtain limited access to an HTTP service on behalf of an end-user

   by orchestrating an approval interaction between the end-user and the

   HTTP service.

 

 

2.1 Authorization Endpoints

  …when sending requests to the token endpoints

should be

  …when sending requests to the authorization endpoint

 

 

7.1 Access Token Types

I suggest adding the following sentence to the end of the 1st paragraph, just to be sure a security value is not used in the wrong protocol.

   A client MUST NOT use an access token if it does not understand the token type.

 

 

7.1 Access Token Types

Use a different access token for the Bearer and MAC examples to avoid any implication that a given token can be used with either method at the client’s discretion. Perhaps make the example Bearer token a bit longer. The current example value has at most 72 bits of entropy that doesn’t match the 128-bits required in draft-lodderstedt-oauth-security-01#section-5.1.4.2.2.

   Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw

 

 

7.1 Access Token Types

The timestamp value in the MAC example corresponds to a date in 1974!

 

 

--

James Manger

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------000104080901080303030004-- From eran@hueniverse.com Wed Apr 6 07:17:43 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1094528C0DB for ; Wed, 6 Apr 2011 07:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ov+u65axgnf for ; Wed, 6 Apr 2011 07:17:42 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id F387828C0E4 for ; Wed, 6 Apr 2011 07:17:41 -0700 (PDT) Received: (qmail 13636 invoked from network); 6 Apr 2011 14:19:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2011 14:19:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 6 Apr 2011 07:19:23 -0700 From: Eran Hammer-Lahav To: Eliot Lear Date: Wed, 6 Apr 2011 07:19:16 -0700 Thread-Topic: [OAUTH-WG] Proposed change to OAuth parameters registry Thread-Index: Acv0QWfxW9I+WavsRdCmzb44rAf9cwAI9SFA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DF8A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723446564305DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D9C3980.2000609@cisco.com> In-Reply-To: <4D9C3980.2000609@cisco.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_90C41DD21FB7C64BB94121FBBC2E7234465664DF8AP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposed change to OAuth parameters registry X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:17:43 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DF8AP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWxpb3QsDQoNClByZWZpeGluZyBxdWVyeSBwYXJhbWV0ZXIgbmFtZXMgd2l0aCBhIGZ1bGwg ZG9tYWluIGlzIG5vdCBsaWtlbHkgdG8gYmUgYW4gYWNjZXB0YWJsZSBzdHlsZS4gRm9yIGV4YW1w bGUsIEZhY2Vib29rIHVzZXMgZmJfIGFzIHRoZWlyIHByZWZpeCAobW9zdCBvZiB0aGUgdGltZSkg YnV0IG15IGd1ZXNzIGlzIG5vdCBsaWtlbHkgdG8gZ28gd2l0aCBmYi5jb20ucGFyYW0gb3IgZmIu Y29tX3BhcmFtLCBub3QgdG8gbWVudGlvbiBmYWNlYm9vay5jb20ucGFyYW0uDQoNCkkgdGhpbmsg dGhlIGNvbnNlbnN1cyBoZXJlIGlzIHRoYXQgc29tZSBjb2xsaXNpb25zIGJldHdlZW4gdmVuZG9y cyBhcmUgZ29pbmcgdG8gaGFwcGVuIGFuZCB0aGF04oCZcyBpdCBvay4gV2hlbiBuZXcgcmVnaXN0 ZXJlZCBleHRlbnNpb24gYXJlIGludHJvZHVjZWQsIHZlbmRvcnMgd2lsbCBuZWVkIHRvIGZpZ3Vy ZSBvdXQgaG93IHRvIHdvcmsgYWxvbmdzaWRlLg0KDQpFSEwNCg0KRnJvbTogRWxpb3QgTGVhciBb bWFpbHRvOmxlYXJAY2lzY28uY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwNiwgMjAxMSAy OjU5IEFNDQpUbzogRXJhbiBIYW1tZXItTGFoYXYNCkNjOiBPQXV0aCBXRw0KU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gUHJvcG9zZWQgY2hhbmdlIHRvIE9BdXRoIHBhcmFtZXRlcnMgcmVnaXN0cnkN Cg0KU29ycnkgZm9yIHRoZSBsYXRlIGNvbW1lbnQgb24gdGhpcywgRXJhbi4gIEkgbGlrZSB5b3Vy IGlkZWEsIGJ1dCB3b3VsZCBzdWdnZXN0IHRoYXQgYmV0dGVyIHRoYW4gY29tcGFueSBuYW1lIHdv dWxkIGJlIGRvbWFpbiBuYW1lIG9yIGJhc2VkIG9uIGRvbWFpbiBuYW1lIChJIGRvbid0IHJlY2Fs bCBpZiAnLicgaXMgYWxsb3dlZCBpbiB0aGlzIGNvbnRleHQpLiAgQ29tcGFueSBuYW1lcyBhcmUg Ynkgbm8gbWVhbnMgdW5pcXVlLCBhbmQgZXZlbiB3aXRoaW4gYSBsYXJnZSBjb21wYW55IG9uZSBj b3VsZCBlbnZpc2lvbiBjbGFzaGVzLg0KDQpFbGlvdA0KDQpPbiAzLzMwLzExIDE6MTMgQU0sIEVy YW4gSGFtbWVyLUxhaGF2IHdyb3RlOg0KSSB3b3VsZCBsaWtlIHRvIG1ha2UgdGhlIGZvbGxvd2lu ZyBjaGFuZ2UgdG8gc2VjdGlvbiA4LjI6DQoNCg0KICAgTmV3IHJlcXVlc3Qgb3IgcmVzcG9uc2Ug cGFyYW1ldGVycyBmb3IgdXNlIHdpdGggdGhlIGF1dGhvcml6YXRpb24NCg0KICAgZW5kcG9pbnQg b3IgdGhlIHRva2VuIGVuZHBvaW50IGFyZSBkZWZpbmVkIGFuZCByZWdpc3RlcmVkIGluIHRoZQ0K DQogICBwYXJhbWV0ZXJzIHJlZ2lzdHJ5IGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlIGluIFNlY3Rp b24gMTAuMjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLTEz I3NlY3Rpb24tMTAuMj4uDQoNCg0KDQogICBQYXJhbWV0ZXIgbmFtZXMgTVVTVCBjb25mb3JtIHRv IHRoZSBwYXJhbS1uYW1lIEFCTkYgYW5kIHBhcmFtZXRlcg0KDQogICB2YWx1ZXMgc3ludGF4IE1V U1QgYmUgd2VsbC1kZWZpbmVkIChlLmcuLCB1c2luZyBBQk5GLCBvciBhIHJlZmVyZW5jZQ0KDQog ICB0byB0aGUgc3ludGF4IG9mIGFuIGV4aXN0aW5nIHBhcmFtZXRlcikuDQoNCg0KDQogICBVbnJl Z2lzdGVyZWQgdmVuZG9yLXNwZWNpZmljIHBhcmFtZXRlciBleHRlbnNpb25zIHRoYXQgYXJlIG5v dCBjb21tb25seQ0KDQogICBhcHBsaWNhYmxlLCBhbmQgYXJlIHNwZWNpZmljIHRvIHRoZSBpbXBs ZW1lbnRhdGlvbiBkZXRhaWxzIG9mIHRoZQ0KDQogICBhdXRob3JpemF0aW9uIHNlcnZlciB3aGVy ZSB0aGV5IGFyZSB1c2VkIFNIT1VMRCB1dGlsaXplIGENCg0KICAgdmVuZG9yLXNwZWNpZmljIHBy ZWZpeCB0aGF0IGlzIG5vdCBsaWtlbHkgdG8gY29uZmxpY3Qgd2l0aCBvdGhlcg0KDQogICByZWdp c3RlcmVkIHZhbHVlcyAoZS5nLiBiZWdpbiB3aXRoICdjb21wYW55bmFtZV8nKS4NCg0KVGhpcyBp cyBhIG1vcmUgcHJhZ21hdGljIChhbmQgbGVzcyB1Z2x5KSBzb2x1dGlvbiB0byB2ZW5kb3Igc3Bl Y2lmaWMgcGFyYW1ldGVycy4gSW5zdGVhZCBvZiB1c2luZyB0aGUg4oCYeF/igJkgcHJlZml4LCB2 ZW5kb3JzIChoYXZlIGFuZCkgd2lsbCB1c2Ugc29tZXRoaW5nIGVsc2UgdGhhdCBpcyB1bmlxdWUg dG8gdGhlbS4gRm9yIGV4YW1wbGUgRmFjZWJvb2sgdXNlcyDigJhmYl/igJkgZm9yIG1hbnkgb2Yg dGhlaXIgcGFyYW1ldGVycy4NCg0KRmVlZGJhY2sgcmVxdWVzdGVkIGJ5IDQvMSBmb3IgaW5jbHVz aW9uIGluIC0xNC4NCg0KRUhMDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0K --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DF8AP3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGJnY29sb3I9 d2hpdGUgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SGkg RWxpb3QsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+UHJlZml4aW5nIHF1ZXJ5IHBhcmFt ZXRlciBuYW1lcyB3aXRoIGEgZnVsbCBkb21haW4gaXMgbm90IGxpa2VseSB0byBiZSBhbiBhY2Nl cHRhYmxlIHN0eWxlLiBGb3IgZXhhbXBsZSwgRmFjZWJvb2sgdXNlcyBmYl8gYXMgdGhlaXIgcHJl Zml4IChtb3N0IG9mIHRoZSB0aW1lKSBidXQgbXkgZ3Vlc3MgaXMgbm90IGxpa2VseSB0byBnbyB3 aXRoIGZiLmNvbS5wYXJhbSBvciBmYi5jb21fcGFyYW0sIG5vdCB0byBtZW50aW9uIGZhY2Vib29r LmNvbS5wYXJhbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5JIHRoaW5rIHRoZSBjb25z ZW5zdXMgaGVyZSBpcyB0aGF0IHNvbWUgY29sbGlzaW9ucyBiZXR3ZWVuIHZlbmRvcnMgYXJlIGdv aW5nIHRvIGhhcHBlbiBhbmQgdGhhdOKAmXMgaXQgb2suIFdoZW4gbmV3IHJlZ2lzdGVyZWQgZXh0 ZW5zaW9uIGFyZSBpbnRyb2R1Y2VkLCB2ZW5kb3JzIHdpbGwgbmVlZCB0byBmaWd1cmUgb3V0IGhv dyB0byB3b3JrIGFsb25nc2lkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5FSEw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO2NvbG9yOndpbmRvd3RleHQnPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93 dGV4dCc+IEVsaW90IExlYXIgW21haWx0bzpsZWFyQGNpc2NvLmNvbV0gPGJyPjxiPlNlbnQ6PC9i PiBXZWRuZXNkYXksIEFwcmlsIDA2LCAyMDExIDI6NTkgQU08YnI+PGI+VG86PC9iPiBFcmFuIEhh bW1lci1MYWhhdjxicj48Yj5DYzo8L2I+IE9BdXRoIFdHPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTog W09BVVRILVdHXSBQcm9wb3NlZCBjaGFuZ2UgdG8gT0F1dGggcGFyYW1ldGVycyByZWdpc3RyeTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlNvcnJ5IGZvciB0aGUgbGF0ZSBjb21t ZW50IG9uIHRoaXMsIEVyYW4uJm5ic3A7IEkgbGlrZSB5b3VyIGlkZWEsIGJ1dCB3b3VsZCBzdWdn ZXN0IHRoYXQgYmV0dGVyIHRoYW4gY29tcGFueSBuYW1lIHdvdWxkIGJlIGRvbWFpbiBuYW1lIG9y IGJhc2VkIG9uIGRvbWFpbiBuYW1lIChJIGRvbid0IHJlY2FsbCBpZiAnLicgaXMgYWxsb3dlZCBp biB0aGlzIGNvbnRleHQpLiZuYnNwOyBDb21wYW55IG5hbWVzIGFyZSBieSBubyBtZWFucyB1bmlx dWUsIGFuZCBldmVuIHdpdGhpbiBhIGxhcmdlIGNvbXBhbnkgb25lIGNvdWxkIGVudmlzaW9uIGNs YXNoZXMuIDxicj48YnI+RWxpb3Q8YnI+PGJyPk9uIDMvMzAvMTEgMToxMyBBTSwgRXJhbiBIYW1t ZXItTGFoYXYgd3JvdGU6IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5JIHdvdWxk IGxpa2UgdG8gbWFrZSB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byBzZWN0aW9uIDguMjo8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PHByZSBzdHls ZT0ncGFnZS1icmVhay1iZWZvcmU6YWx3YXlzJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBw dCc+Jm5ic3A7Jm5ic3A7IE5ldyByZXF1ZXN0IG9yIHJlc3BvbnNlIHBhcmFtZXRlcnMgZm9yIHVz ZSB3aXRoIHRoZSBhdXRob3JpemF0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHls ZT0ncGFnZS1icmVhay1iZWZvcmU6YWx3YXlzJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBw dCc+Jm5ic3A7Jm5ic3A7IGVuZHBvaW50IG9yIHRoZSB0b2tlbiBlbmRwb2ludCBhcmUgZGVmaW5l ZCBhbmQgcmVnaXN0ZXJlZCBpbiB0aGU8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxl PSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0 Jz4mbmJzcDsmbmJzcDsgcGFyYW1ldGVycyByZWdpc3RyeSBmb2xsb3dpbmcgdGhlIHByb2NlZHVy ZSBpbiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo LXYyLTEzI3NlY3Rpb24tMTAuMiI+U2VjdGlvbiAxMC4yPC9hPi48L3NwYW4+PG86cD48L286cD48 L3ByZT48cHJlIHN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTIuMHB0Jz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxl PSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0 Jz4mbmJzcDsmbmJzcDsgUGFyYW1ldGVyIG5hbWVzIE1VU1QgY29uZm9ybSB0byB0aGUgcGFyYW0t bmFtZSBBQk5GIGFuZCBwYXJhbWV0ZXI8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxl PSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0 Jz4mbmJzcDsgJm5ic3A7dmFsdWVzIHN5bnRheCBNVVNUIGJlIHdlbGwtZGVmaW5lZCAoZS5nLiwg dXNpbmcgQUJORiwgb3IgYSByZWZlcmVuY2U8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0 eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIu MHB0Jz4mbmJzcDsgJm5ic3A7dG8gdGhlIHN5bnRheCBvZiBhbiBleGlzdGluZyBwYXJhbWV0ZXIp Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPjxwcmUgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOyZuYnNwOyBVbnJlZ2lzdGVyZWQgdmVuZG9yLXNw ZWNpZmljIHBhcmFtZXRlciBleHRlbnNpb25zIHRoYXQgYXJlIG5vdCBjb21tb25seTwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOyZuYnNwOyBhcHBsaWNhYmxlLCBhbmQg YXJlIHNwZWNpZmljIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIG9mIHRoZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOyZuYnNwOyBhdXRob3JpemF0aW9uIHNl cnZlciB3aGVyZSB0aGV5IGFyZSB1c2VkIFNIT1VMRCB1dGlsaXplIGE8L3NwYW4+PG86cD48L286 cD48L3ByZT48cHJlIHN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTIuMHB0Jz4mbmJzcDsmbmJzcDsgdmVuZG9yLXNwZWNpZmljIHByZWZpeCB0 aGF0IGlzIG5vdCBsaWtlbHkgdG8gY29uZmxpY3Qgd2l0aCBvdGhlciA8L3NwYW4+PG86cD48L286 cD48L3ByZT48cHJlIHN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTIuMHB0Jz4mbmJzcDsmbmJzcDsmbmJzcDtyZWdpc3RlcmVkIHZhbHVlcyAo ZS5nLiBiZWdpbiB3aXRoICdjb21wYW55bmFtZV8nKS48L3NwYW4+PG86cD48L286cD48L3ByZT48 cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PlRoaXMgaXMgYSBtb3JlIHByYWdtYXRpYyAoYW5kIGxlc3MgdWdseSkgc29sdXRpb24gdG8gdmVu ZG9yIHNwZWNpZmljIHBhcmFtZXRlcnMuIEluc3RlYWQgb2YgdXNpbmcgdGhlIOKAmHhf4oCZIHBy ZWZpeCwgdmVuZG9ycyAoaGF2ZSBhbmQpIHdpbGwgdXNlIHNvbWV0aGluZyBlbHNlIHRoYXQgaXMg dW5pcXVlIHRvIHRoZW0uIEZvciBleGFtcGxlIEZhY2Vib29rIHVzZXMg4oCYZmJf4oCZIGZvciBt YW55IG9mIHRoZWlyIHBhcmFtZXRlcnMuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5GZWVkYmFjayByZXF1ZXN0 ZWQgYnkgNC8xIGZvciBpbmNsdXNpb24gaW4gLTE0LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+RUhMPG86cD48 L286cD48L3A+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT48cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPG86cD48L286cD48L3ByZT48cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9w cmU+PHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9h PjxvOnA+PC9vOnA+PC9wcmU+PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DF8AP3PW5EX1MB01E_-- From eran@hueniverse.com Wed Apr 6 07:35:26 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3476F28C0DB for ; Wed, 6 Apr 2011 07:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLs6cdlRPYeG for ; Wed, 6 Apr 2011 07:35:02 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id AD1573A6905 for ; Wed, 6 Apr 2011 07:35:02 -0700 (PDT) Received: (qmail 8929 invoked from network); 6 Apr 2011 14:36:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2011 14:36:46 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 6 Apr 2011 07:36:41 -0700 From: Eran Hammer-Lahav To: Paul Madsen , "oauth@ietf.org" Date: Wed, 6 Apr 2011 07:36:34 -0700 Thread-Topic: [OAUTH-WG] draft-15 editorials Thread-Index: Acv0ScrOEbXoYwtOTweePD7+91suygAHje/Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11281BA9188@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943252CE4F8@TK5EX14MBXC203.redmond.corp.microsoft.com> <4D9C47A8.30605@gmail.com> In-Reply-To: <4D9C47A8.30605@gmail.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_90C41DD21FB7C64BB94121FBBC2E7234465664DF8FP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-15 editorials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:35:26 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DF8FP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can you propose text? EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= aul Madsen Sent: Wednesday, April 06, 2011 4:00 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-15 editorials Can we not acknowledge in the abstract that there are other applications fo= r OAuth beyond the delegated authz scenario? I tell people that OAuth 2 is more a framework than a specific protocol, bu= t the current abstract belies this claim. paul On 4/5/11 8:57 PM, Mike Jones wrote: Also, change "which in turns directs" to "which in turn directs". -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Manger, James H Sent: Tuesday, April 05, 2011 5:51 PM To: oauth@ietf.org Subject: [OAUTH-WG] draft-15 editorials A few, mainly editorial, points on the latest OAuth 2.0 core draft [draft-i= etf-oauth-v2-15]: Abstract: Currently it is: The OAuth 2.0 authorization protocol enables granting third-party applications limited access to HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. This sentence is confusing as to whom is doing the orchestrating. It is an = important OAuth feature that the 3rd-party app does this. Also add "an" bef= ore "HTTP service". The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. 2.1 Authorization Endpoints ...when sending requests to the token endpoints should be ...when sending requests to the authorization endpoint 7.1 Access Token Types I suggest adding the following sentence to the end of the 1st paragraph, ju= st to be sure a security value is not used in the wrong protocol. A client MUST NOT use an access token if it does not understand the toke= n type. 7.1 Access Token Types Use a different access token for the Bearer and MAC examples to avoid any i= mplication that a given token can be used with either method at the client'= s discretion. Perhaps make the example Bearer token a bit longer. The curre= nt example value has at most 72 bits of entropy that doesn't match the 128-= bits required in draft-lodderstedt-oauth-security-01#section-5.1.4.2.2. Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw 7.1 Access Token Types The timestamp value in the MAC example corresponds to a date in 1974! -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DF8FP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Can you propose text?

 

EHL<= /p>

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be= half Of Paul Madsen
Sent: Wednesday, April 06, 2011 4:00 AMTo: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-15 edit= orials

 

Can we not acknowledge in the abstract that the= re are other applications for OAuth beyond the delegated authz scenario?
I tell people that OAuth 2 is more a framework than a specific protoc= ol, but the current abstract belies this claim.

paul

On 4/5/= 11 8:57 PM, Mike Jones wrote:

Also, change “which in turns directs” to &= #8220;which in turn directs”.

 

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

 

<= div>

From: oauth-bounces@= ietf.org [mailto:oauth-bounce= s@ietf.org] On Behalf Of Manger, James H
Sent: Tuesday= , April 05, 2011 5:51 PM
To: oa= uth@ietf.org
Subject: [OAUTH-WG] draft-15 editorials

 

A few, mainly editorial, points on the late= st OAuth 2.0 core draft [draft-ietf-oauth-v2-15]:

 

Abstract: Cur= rently it is:

   The OAuth= 2.0 authorization protocol enables granting third-party<= /p>

   applications limited access to HTTP servi= ce on behalf of an end-user

 &n= bsp; by orchestrating an approval interaction between the end-user and the<= /span>

   HTTP service.

This sentence is confus= ing as to whom is doing the orchestrating. It is an important OAuth feature= that the 3rd-party app does this. Also add “an” before “= HTTP service”.

   = The OAuth 2.0 authorization protocol enables a third-party application

   to obtain limited access to= an HTTP service on behalf of an end-user

   by orchestrating an approval interaction between the end= -user and the

   HTTP serv= ice.

 

 

2.1 Authorization En= dpoints

  …when=
 sending requests to the token endpoints

should be

  …when sending requests to the authorization endpoint<=
/span>

 

 <= /o:p>

7.1 Access Token Types<= /span>

I suggest = adding the following sentence to the end of the 1st paragraph, j= ust to be sure a security value is not used in the wrong protocol.

   A client MUST NOT use an access= token if it does not understand the token type.

 

 

7.1 Access Token Types

Use a different access token for the B= earer and MAC examples to avoid any implication that a given token can be u= sed with either method at the client’s discretion. Perhaps make the e= xample Bearer token a bit longer. The current example value has at most 72 = bits of entropy that doesn’t match the 128-bits required in draft-lod= derstedt-oauth-security-01#section-5.1.4.2.2.

   Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw<= o:p>

 

 

=

7.1 Access Token Types

The timestamp value= in the MAC example corresponds to a date in 1974!

 

 

--

James Manger

 

 
<=
o:p> 
_______________________________________________<=
o:p>
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi=
nfo/oauth
= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DF8FP3PW5EX1MB01E_-- From eran@hueniverse.com Wed Apr 6 07:39:25 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65EC328C0DB for ; Wed, 6 Apr 2011 07:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBlI8-pwCbAr for ; Wed, 6 Apr 2011 07:39:22 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 755DB3A6905 for ; Wed, 6 Apr 2011 07:39:22 -0700 (PDT) Received: (qmail 16460 invoked from network); 6 Apr 2011 14:41:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2011 14:41:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 6 Apr 2011 07:40:49 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Wed, 6 Apr 2011 07:40:44 -0700 Thread-Topic: draft-15 editorials Thread-Index: Acvz9MB6KgutpDVYQ4S57m9IkdJP/gAc9PkQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DF92@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11281BA9188@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11281BA9188@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664DF92P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-15 editorials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:39:25 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DF92P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Done. EHL Ps. I like 1974. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Tuesday, April 05, 2011 5:51 PM To: oauth@ietf.org Subject: [OAUTH-WG] draft-15 editorials A few, mainly editorial, points on the latest OAuth 2.0 core draft [draft-i= etf-oauth-v2-15]: Abstract: Currently it is: The OAuth 2.0 authorization protocol enables granting third-party applications limited access to HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. This sentence is confusing as to whom is doing the orchestrating. It is an = important OAuth feature that the 3rd-party app does this. Also add "an" bef= ore "HTTP service". The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. 2.1 Authorization Endpoints ...when sending requests to the token endpoints should be ...when sending requests to the authorization endpoint 7.1 Access Token Types I suggest adding the following sentence to the end of the 1st paragraph, ju= st to be sure a security value is not used in the wrong protocol. A client MUST NOT use an access token if it does not understand the toke= n type. 7.1 Access Token Types Use a different access token for the Bearer and MAC examples to avoid any i= mplication that a given token can be used with either method at the client'= s discretion. Perhaps make the example Bearer token a bit longer. The curre= nt example value has at most 72 bits of entropy that doesn't match the 128-= bits required in draft-lodderstedt-oauth-security-01#section-5.1.4.2.2. Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw 7.1 Access Token Types The timestamp value in the MAC example corresponds to a date in 1974! -- James Manger --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DF92P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Done.

 

EHL

 

Ps. I like 1974.

 

From: oauth-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: T= uesday, April 05, 2011 5:51 PM
To: oauth@ietf.org
Subject:<= /b> [OAUTH-WG] draft-15 editorials

 

= A few, mainly editorial, points on the latest OAuth 2.0 core draft [draft-i= etf-oauth-v2-15]:

 

= Abstract: Currently it is:<= /p>

   The OAuth 2.0 authorization protocol enab= les granting third-party

  = ; applications limited access to HTTP service on behalf of an end-user=

   by orchestrating an approva= l interaction between the end-user and the

   HTTP service.

This sentence is confusing as to whom is doing the orch= estrating. It is an important OAuth feature that the 3rd-party app does thi= s. Also add “an” before “HTTP service”.<= /span>

   The OAuth 2.0 authorization protoc= ol enables a third-party application

   to obtain limited access to an HTTP service on behalf of an e= nd-user

   by orchestrati= ng an approval interaction between the end-user and the

   HTTP service.

 

 

= 2.1 Authorization Endpoints

  …when sendin=
g requests to the token endpoints

should be

  …when sending requests to the authorization endpoint

 

 

7.1 Access Token Types<= /b>

I suggest adding the following sentence to the end of the 1st= paragraph, just to be sure a security value is not used in the wrong= protocol.

   A client MUS= T NOT use an access token if it does not understand the token type.

 

 

=

7.1 Access Token Types

Use a different access token for the Bearer and MAC examples to av= oid any implication that a given token can be used with either method at th= e client’s discretion. Perhaps make the example Bearer token a bit lo= nger. The current example value has at most 72 bits of entropy that doesn&#= 8217;t match the 128-bits required in draft-lodderstedt-oauth-security-01#s= ection-5.1.4.2.2.

   Autho= rization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw

 

=  

7.1 Access Token Types

The timestamp value i= n the MAC example corresponds to a date in 1974!

 

 

--

James Manger

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664DF92P3PW5EX1MB01E_-- From eran@hueniverse.com Wed Apr 6 07:43:54 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42FE28C10F for ; Wed, 6 Apr 2011 07:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UhEQnyYdnVT for ; Wed, 6 Apr 2011 07:43:53 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id CCF1028C0D8 for ; Wed, 6 Apr 2011 07:43:53 -0700 (PDT) Received: (qmail 25128 invoked from network); 6 Apr 2011 14:45:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2011 14:45:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 6 Apr 2011 07:45:34 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , Marius Scurtescu Date: Wed, 6 Apr 2011 07:45:27 -0700 Thread-Topic: [OAUTH-WG] Error registry proposal (round 3) Thread-Index: Acvz6VKMvTGj2NduRH2RtRenLEtAYAAAMrKAAB/GXUA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DF95@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664DED6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234465664DEE1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664DEE1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Error registry proposal (round 3) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:43:55 -0000 New text: Extension error codes MUST be registered (following the procedure= s in ) if the extension they are use= d in conjunction with is a registered access token type, a registered endpoint parameter, = or an extension grant type. Error codes used with unregistered extensions MAY be regist= ered. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Tuesday, April 05, 2011 4:36 PM > To: Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Error registry proposal (round 3) >=20 >=20 >=20 > > -----Original Message----- > > From: Marius Scurtescu [mailto:mscurtescu@google.com] > > Sent: Tuesday, April 05, 2011 4:29 PM >=20 > > Isn't this sentence "Additional error codes used with unregistered > > extensions MAY be registered." contradicting what you are saying > > above? It seems to open the door to register error codes not > > associated with a registered extension. >=20 > What are you, a lawyer? :-) >=20 > I guess you can find a logical flaw in this. I'll make it more explicit l= ist of > extension types... >=20 > EHL >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From paul.madsen@gmail.com Wed Apr 6 08:13:22 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206E828C122 for ; Wed, 6 Apr 2011 08:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2vBxWYQWfxa for ; Wed, 6 Apr 2011 08:13:13 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id AE54228C0DB for ; Wed, 6 Apr 2011 08:13:12 -0700 (PDT) Received: by yxk30 with SMTP id 30so724631yxk.31 for ; Wed, 06 Apr 2011 08:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=oNCJ602ngx955X1/SzOm9zfNfawK6l48nQO/GyWwapY=; b=bQav8z5VmGfmvildp4c541qPm0rMywIVQSl7OiE8xQ/dNZroRANDDa1hg/GKDfAbKj EVYv1sThlxXRO/9zU0KijH48fQ0boTkAcoGe0+zrpxSX+vgnCpqJnr2HZO+54ms8DiPw ppDcTRhgxJ+2KmAotkgrE/4wxRv2/3rggup10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=Uo2aiwxf6lV2pI67f/bp0Swn2tVgCqy5PaSZjE6acjC6xAJuIvjo5OcWussdR4sMky pyKM26bBa/R9Zjqoc8BiRlwYAianEk59mzeAVLtAYXYMKIZr4f422TpPj+dCFj7/rGTu oG30d1xWmhIcNv33h4EPfWsguXW8yjHq6ZS9s= Received: by 10.91.102.5 with SMTP id e5mr1993198agm.157.1302102896219; Wed, 06 Apr 2011 08:14:56 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id 23sm766209ano.7.2011.04.06.08.14.53 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 08:14:54 -0700 (PDT) Message-ID: <4D9C836C.9080704@gmail.com> Date: Wed, 06 Apr 2011 11:14:52 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <255B9BB34FB7D647A506DC292726F6E11281BA9188@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943252CE4F8@TK5EX14MBXC203.redmond.corp.microsoft.com> <4D9C47A8.30605@gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234465664DF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664DF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------030706080602090104010304" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-15 editorials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:13:22 -0000 This is a multi-part message in MIME format. --------------030706080602090104010304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Proposed text The OAuth 2.0 authorization protocol enables a third-party applicationto obtain limited access to an HTTP service, either on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service, or by allowing the third-party application to directly 'negotiate', on its own behalf,such access with the HTTP service. And I acknowledge the concerns that 'negotiate' might create, thus the air quotes .... paul On 4/6/11 10:36 AM, Eran Hammer-Lahav wrote: > > Can you propose text? > > EHL > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Paul Madsen > *Sent:* Wednesday, April 06, 2011 4:00 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] draft-15 editorials > > Can we not acknowledge in the abstract that there are other > applications for OAuth beyond the delegated authz scenario? > > I tell people that OAuth 2 is more a framework than a specific > protocol, but the current abstract belies this claim. > > paul > > On 4/5/11 8:57 PM, Mike Jones wrote: > > Also, change "which in turns directs" to "which in turn directs". > > -- Mike > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Manger, James H > *Sent:* Tuesday, April 05, 2011 5:51 PM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] draft-15 editorials > > A few, mainly editorial, points on the latest OAuth 2.0 core draft > [draft-ietf-oauth-v2-15]: > > *Abstract*: Currently it is: > > The OAuth 2.0 authorization protocol enables granting third-party > > applications limited access to HTTP service on behalf of an end-user > > by orchestrating an approval interaction between the end-user and the > > HTTP service. > > This sentence is confusing as to whom is doing the orchestrating. It > is an important OAuth feature that the 3rd-party app does this. Also > add "an" before "HTTP service". > > The OAuth 2.0 authorization protocol enables a third-party application > > to obtain limited access to an HTTP service on behalf of an end-user > > by orchestrating an approval interaction between the end-user and the > > HTTP service. > > *2.1 Authorization Endpoints* > > ...when sending requests to the token endpoints > > should be > > ...when sending requests to the authorization endpoint > > *7.1 Access Token Types* > > I suggest adding the following sentence to the end of the 1^st > paragraph, just to be sure a security value is not used in the wrong > protocol. > > A client MUST NOT use an access token if it does not understand the > token type. > > *7.1 Access Token Types* > > Use a different access token for the Bearer and MAC examples to avoid > any implication that a given token can be used with either method at > the client's discretion. Perhaps make the example Bearer token a bit > longer. The current example value has at most 72 bits of entropy that > doesn't match the 128-bits required in > draft-lodderstedt-oauth-security-01#section-5.1.4.2.2. > > Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw > > *7.1 Access Token Types* > > The timestamp value in the MAC example corresponds to a date in 1974! > > -- > > James Manger > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030706080602090104010304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Proposed text

The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service, or by allowing the third-party application to directly 'negotiate', on its own behalf, such access with the HTTP service.

And I acknowledge the concerns that 'negotiate' might create, thus the air quotes ....

paul

On 4/6/11 10:36 AM, Eran Hammer-Lahav wrote:

Can you propose text?

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Paul Madsen
Sent: Wednesday, April 06, 2011 4:00 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-15 editorials

 

Can we not acknowledge in the abstract that there are other applications for OAuth beyond the delegated authz scenario?

I tell people that OAuth 2 is more a framework than a specific protocol, but the current abstract belies this claim.

paul

On 4/5/11 8:57 PM, Mike Jones wrote:

Also, change “which in turns directs” to “which in turn directs”.

 

                                                                -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Tuesday, April 05, 2011 5:51 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-15 editorials

 

A few, mainly editorial, points on the latest OAuth 2.0 core draft [draft-ietf-oauth-v2-15]:

 

Abstract: Currently it is:

   The OAuth 2.0 authorization protocol enables granting third-party

   applications limited access to HTTP service on behalf of an end-user

   by orchestrating an approval interaction between the end-user and the

   HTTP service.

This sentence is confusing as to whom is doing the orchestrating. It is an important OAuth feature that the 3rd-party app does this. Also add “an” before “HTTP service”.

   The OAuth 2.0 authorization protocol enables a third-party application

   to obtain limited access to an HTTP service on behalf of an end-user

   by orchestrating an approval interaction between the end-user and the

   HTTP service.

 

 

2.1 Authorization Endpoints

  …when sending requests to the token endpoints

should be

  …when sending requests to the authorization endpoint

 

 

7.1 Access Token Types

I suggest adding the following sentence to the end of the 1st paragraph, just to be sure a security value is not used in the wrong protocol.

   A client MUST NOT use an access token if it does not understand the token type.

 

 

7.1 Access Token Types

Use a different access token for the Bearer and MAC examples to avoid any implication that a given token can be used with either method at the client’s discretion. Perhaps make the example Bearer token a bit longer. The current example value has at most 72 bits of entropy that doesn’t match the 128-bits required in draft-lodderstedt-oauth-security-01#section-5.1.4.2.2.

   Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw

 

 

7.1 Access Token Types

The timestamp value in the MAC example corresponds to a date in 1974!

 

 

--

James Manger

 

 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------030706080602090104010304-- From skylar@kiva.org Wed Apr 6 09:00:55 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1972C3A6874 for ; Wed, 6 Apr 2011 09:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvq3GgaOv2lr for ; Wed, 6 Apr 2011 09:00:53 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by core3.amsl.com (Postfix) with SMTP id 9E5C53A694F for ; Wed, 6 Apr 2011 09:00:53 -0700 (PDT) Received: from mail-iy0-f170.google.com ([209.85.210.170]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKTZyOnJg769FH3qR6RDq5JIs/c5/PPROC@postini.com; Wed, 06 Apr 2011 09:02:38 PDT Received: by mail-iy0-f170.google.com with SMTP id 12so1906531iyb.29 for ; Wed, 06 Apr 2011 09:02:36 -0700 (PDT) Received: by 10.231.66.69 with SMTP id m5mr1189301ibi.55.1302105756467; Wed, 06 Apr 2011 09:02:36 -0700 (PDT) Received: from [10.0.1.4] (c-24-5-80-5.hsd1.ca.comcast.net [24.5.80.5]) by mx.google.com with ESMTPS id f28sm355845ibh.16.2011.04.06.09.02.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 09:02:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Skylar Woodward X-Priority: Normal In-Reply-To: <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> Date: Wed, 6 Apr 2011 09:02:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> To: torsten@lodderstedt.net X-Mailer: Apple Mail (2.1084) Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:00:55 -0000 Well, I should elaborate. The method of authorization is open to the = client, and in this case (Kiva), MAC tokens are being used. The client = authenticates on the access_token request by presenting a MAC = authentication header. Creating the MAC signature requires a secret. In = the native client case, since there is no secret, it signs with the = empty string. So, how would you interpret this mechanism? Are we using = an empty string secret or signing without a secret? In terms of = communicating to the developers, they are told they don't have a secret. = For purposes of signing, they are instructed to sign with them empty = string when they have no secret. Alternatively, one could use Bearer token for client authentication in = this case where the token is just the client ID. To me this is more = confusing because they must authenticate with different token types for = secret vs. non-secret. Other opinions? As to the question of interoperability, the fact that OAuth allows = freedom of choice to the AS for method of authentication makes this = point moot. Would you agree? (short of various providers could pooling = together to standardize on an auth method outside of the spec). On Apr 4, 2011, at 10:15 PM, torsten@lodderstedt.net wrote: > Hi Skylar, >=20 > Thank you for sharing this information with us. Some thougts: >=20 > The empty string makes your implementation syntactically compliant but = does obviously not comply with its semantics and the security = considerations/expectations associated with a secret. Moreover, what = about interoperability?=20 >=20 > I think not using secrets for such clients is the honest solution. We = can just change the spec's text to express what we think is the right = way. >=20 > regards, > Torsten. > Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland =20 >=20 > -----Original Message----- > From: Skylar Woodward > Date: Mon, 4 Apr 2011 19:14:53=20 > To: Torsten Lodderstedt > Cc: Zeltsan, Zachary (Zachary); = Kris Selden; oauth@ietf.org > Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >=20 > In our implementation (not yet public) we accept the empty string ("") = as the value for clients not issued secrets. While this was done to = simplify the interface and implementation, it would make it compliant in = my view. In this case, the authorization server is validating the = credentials, which are the client ID and the empty string, which is = equivalent security-wise to any other length of "secret" issued to a = native client. >=20 > Besides, for many providers, the client credentials will only be a = client ID. They would plan to secure all exchanges over TLS and = credentials serve just as a tracking device or at best, a weak form of = identification. >=20 > skylar >=20 > On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote: >=20 >> Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): >>> According to section "6 Refreshing an Access Token" (-13.txt), = client when making a request for exchanging a refresh token for an = access token has to include its authentication credentials, and the = "authorization server MUST validate the client credentials". >>> How can this be done if a client is an application that can't have a = client secret? >>> The authorization code grant does require client authentication (per = section 4.1): >>>=20 >>> (D) The client requests an access token from the authorization >>> server's token endpoint by authenticating using its client >>> credentials, and includes the authorization code received in = the >>> previous step. >>>=20 >>> It appears that the clients that cannot keep its secret cannot use = (be issued) the refresh tokens. >>=20 >> In my opinion, this part of the spec is misleading. Authorization = code MUST be possible without client authentication. Otherwise, OAuth is = useless for native apps. >>=20 >> = http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-= 01#section-2.10 describes how the flow can be protected in such cases. >>=20 >> regards, >> Torsten. >>> Zachary >>>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Marius Scurtescu >>> Sent: Monday, April 04, 2011 2:30 PM >>> To: Kris Selden >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>=20 >>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden = wrote: >>>> A typical iPhone app cannot be shipped with a client secret and = rightly or wrongly users expect to only have to enter their credentials = once. >>>>=20 >>>> What is the best profile to use for an app that can't have a client = secret and needs a refresh token or a long lived access token? >>> The authorization code grant, aka web server flow. >>>=20 >>> The spec is misleading in this respect IMO. >>>=20 >>> Marius >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From Michael.Jones@microsoft.com Wed Apr 6 14:23:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9C83A6956 for ; Wed, 6 Apr 2011 14:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.568 X-Spam-Level: X-Spam-Status: No, score=-10.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTvYF35DliuB for ; Wed, 6 Apr 2011 14:23:04 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 476DD3A67D3 for ; Wed, 6 Apr 2011 14:23:04 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 14:24:47 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.38]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0270.002; Wed, 6 Apr 2011 14:24:47 -0700 From: Mike Jones To: Eran Hammer-Lahav , OAuth WG Thread-Topic: Error registry proposal (round 3) Thread-Index: Acvz2lgK8+BMtZK8RZ2KEzyemyZs+QAxcVzg Date: Wed, 6 Apr 2011 21:24:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252CF7A0@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465664DED6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664DED6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252CF7A0TK5EX14MBXC203r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Error registry proposal (round 3) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:23:13 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252CF7A0TK5EX14MBXC203r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for writing this up, Eran. I believe that this is a step in the rig= ht direction. Wearing my Bearer Token spec editor hat, I just tried to go through the exe= rcise of editing my document to use the registry in draft 15 to register th= e errors defined in the bearer token spec and I hit a roadblock. Specifica= lly, while the errors defined by my spec are returned by resource servers (= flow F in Figure 1), the registry defined by draft 15 does not include "res= ource server error response" in the "error usage location" list. Can you p= lease add this additional error usage location so that the registry can be = used by the bearer token specification? At that point, I believe we'll be able to close the open issue about the ne= ed for an error registry, and I'll update my draft accordingly. Thank you, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, April 05, 2011 3:52 PM To: OAuth WG Subject: [OAUTH-WG] Error registry proposal (round 3) The following is my new proposal, based on Mike Jones' and my earlier propo= sals. It is basically a combination of the two. This proposal does not allow defining new error codes unless another extens= ion is involved (new grant type, request parameter, token type). The reason= for not defining an open ended error registry is that defining new error c= odes for existing implementations is bad for interoperability and can lead = to unexpected results (developers not taking into account receiving a new e= rror when talking to a compliant 2.0 server). We don't have any use cases f= or defining such new errors for the v2 specification. New errors only come = from extensions and must be defined in that context. I have applied to changes to the -14 draft and clearly marked them with [[P= ending Consensus]] so that there is no issue with removing them or changing= them later. --- Add to the error codes list in sections 4.1.2.1 and 4.2.2.1: a 4xx or 5xx HTTP status code (except for 400 and 401) The authorization server MAY set the "error" parameter value to a numerical HTTP status code from the 4xx or 5xx range, with the exception of the 400 (Bad Request) and 401 (Unauthorized) status codes. For example, if the service is temporarily unavailable, the authorization server MAY return an error response with "error" set to "503". Add a new section 8.4: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the token error response (Section 5.2), such error codes MAY be defined. Extension error codes MUST be registered (following the procedures in Section 10.3) if the extension they are used in conjunction with is registered. Additional error codes used with unregistered extensions MAY be registered. Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" should be named "example_invalid". error-code =3D ALPHA *error-char error-char =3D "-" / "." / "_" / DIGIT / ALPHA Add a new section 10.3: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app-ads@tools.ietf.org email address or d= irectly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. 10.3.1. Registration Template Error name: The name requested (e.g., "example"). Error usage location: The location(s) where the error can be used. The possible locations are: authorization code grant error response (Section 4.1.2.1), implicit grant error response (Section 4.2.2.1), or token error response (Section 5.2). Related protocol extension: The name of the extension grant type, access token type, or extension parameter, the error code is used in conjunction with. Change controller: For standards-track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included. Specification document(s): Reference to document that specifies the error code, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required. --_000_4E1F6AAD24975D4BA5B1680429673943252CF7A0TK5EX14MBXC203r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for writing thi= s up, Eran.  I believe that this is a step in the right direction.

 

Wearing my Bearer Toke= n spec editor hat, I just tried to go through the exercise of editing my do= cument to use the registry in draft 15 to register the errors defined in th= e bearer token spec and I hit a roadblock.  Specifically, while the errors defined by my spec are returned by resource= servers (flow F in Figure 1), the registry defined by draft 15 does not in= clude “resource server error response” in the “error usag= e location” list.  Can you please add this additional error usage location so that the registry can be used by the bearer token = specification?

 

At that point, I belie= ve we’ll be able to close the open issue about the need for an error = registry, and I’ll update my draft accordingly.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Thank you,

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, April 05, 2011 3:52 PM
To: OAuth WG
Subject: [OAUTH-WG] Error registry proposal (round 3)

 

The following is my new proposal, based on Mike J= ones’ and my earlier proposals. It is basically a combination of the = two.

 

This proposal does not allow defining new error c= odes unless another extension is involved (new grant type, request paramete= r, token type). The reason for not defining an open ended error registry is= that defining new error codes for existing implementations is bad for interoperability and can lead to unexp= ected results (developers not taking into account receiving a new error whe= n talking to a compliant 2.0 server). We don't have any use cases for defin= ing such new errors for the v2 specification. New errors only come from extensions and must be defined in that context.<= o:p>

 

I have applied to changes to the -14 draft and cl= early marked them with [[Pending Consensus]] so that there is no issue with= removing them or changing them later.

 

---

 

Add to the error codes list in sections 4.1.2.1 a= nd 4.2.2.1:

 

       &nbs= p; a 4xx or 5xx HTTP status code (except for 400 and 401)=

       &nbs= p;       The authorization server MAY set the= "error" parameter

       &nbs= p;       value to a numerical HTTP status cod= e from the 4xx or 5xx

       &nbs= p;       range, with the exception of the 400= (Bad Request) and

       &nbs= p;       401 (Unauthorized) status codes.&nbs= p; For example, if the

       &nbs= p;       service is temporarily unavailable, = the authorization

       &nbs= p;       server MAY return an error response = with "error" set to

       &nbs= p;       "503".

 

 

Add a new section 8.4:

 

8.4.  Defining Additional Error Codes=

 
   In cases where protocol exten=
sions (i.e. access token types,
   extension parameters, or exte=
nsion grant types) require additional
   error codes to be used with t=
he authorization code grant error
   response (Section 4.1.2.1), t=
he implicit grant error response
   (Section 4.2.2.1), or the tok=
en error response (Section 5.2), such
   error codes MAY be defined.
 
   Extension error codes MUST be=
 registered (following the procedures in
   Section 10.3) if the extensio=
n they are used in conjunction with is
   registered.  Additional =
error codes used with unregistered extensions
   MAY be registered.=

 
   Error codes MUST conform to t=
he error-code ABNF, and SHOULD be
   prefixed by an identifying na=
me when possible.  For example, an error
   identifying an invalid value =
set to the extension parameter "example"
   should be named "example=
_invalid".
 
 
     error-code &=
nbsp; =3D ALPHA *error-char
     error-char &=
nbsp; =3D "-" / "." / "_" / DIGIT / ALPHA

 

 

Add a new section 10.3:

 

10.3.  The OAuth Extensions Error Reg=
istry
 
   This specification establishe=
s the OAuth extensions error registry.
 
   Additional error codes used t=
ogether with other protocol extensions
   (i.e. extension grant types, =
access token types, or extension
   parameters) are registered on=
 the advice of one or more Designated
   Experts (appointed by the IES=
G or their delegate), with a
   Specification Required (using=
 terminology from [RFC5226]).  However,
   to allow for the allocation o=
f values prior to publication, the
   Designated Expert(s) may appr=
ove registration once they are satisfied
   that such a specification wil=
l be published.
 
   Registration requests should =
be sent to the [TBD]@ietf.org mailing
   list for review and comment, =
with an appropriate subject (e.g.,
   "Request for error code:=
 example"). [[ Note to RFC-EDITOR: The name
   of the mailing list should be=
 determined in consultation with the
   IESG and IANA.  Suggeste=
d name: oauth-ext-review. ]]
 
   Within at most 14 days of the=
 request, the Designated Expert(s) will
   either approve or deny the re=
gistration request, communicating this
   decision to the review list a=
nd IANA.  Denials should include an
   explanation and, if applicabl=
e, suggestions as to how to make the
   request successful.
 
   Decisions (or lack thereof) m=
ade by the Designated Expert can be
   first appealed to Application=
 Area Directors (contactable using
   app-ads@tools.ietf.org email address or directly by lookin=
g up their
   email addresses on http://www.iesg.org/ website) and, if the
   appellant is not satisfied wi=
th the response, to the full IESG (using
   the iesg@iesg.org mailing list).
 
   IANA should only accept regis=
try updates from the Designated
   Expert(s), and should direct =
all requests for registration to the
   review mailing list.
 
10.3.1.  Registration Template
 
   Error name:=

      The name re=
quested (e.g., "example").
   Error usage location:
      The locatio=
n(s) where the error can be used.  The possible

      locations a=
re: authorization code grant error response


      (Section 4.=
1.2.1), implicit grant error response


      (Section 4.=
2.2.1), or token error response (Section 5.2).


   Related protocol extension:


      The name of=
 the extension grant type, access token type, or


      extension p=
arameter, the error code is used in conjunction with.

   Change controller:=



      For standar=
ds-track RFCs, state "IETF".  For others, give the name=



      of the resp=
onsible party.  Other details (e.g., postal address,=



      e-mail addr=
ess, home page URI) may also be included.


   Specification document(s):


      Reference t=
o document that specifies the error code, preferably

      including a=
 URI that can be used to retrieve a copy of the


      document.&n=
bsp; An indication of the relevant sections may also be

      included, b=
ut is not required.


 


 
--_000_4E1F6AAD24975D4BA5B1680429673943252CF7A0TK5EX14MBXC203r_-- From eran@hueniverse.com Wed Apr 6 14:56:22 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C239C3A67D9 for ; Wed, 6 Apr 2011 14:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORwQXxq6yp4R for ; Wed, 6 Apr 2011 14:56:12 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5C4843A67A8 for ; Wed, 6 Apr 2011 14:56:12 -0700 (PDT) Received: (qmail 3200 invoked from network); 6 Apr 2011 21:57:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Apr 2011 21:57:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 6 Apr 2011 14:57:52 -0700 From: Eran Hammer-Lahav To: Mike Jones , OAuth WG Date: Wed, 6 Apr 2011 14:57:46 -0700 Thread-Topic: Error registry proposal (round 3) Thread-Index: Acvz2lgK8+BMtZK8RZ2KEzyemyZs+QAxcVzgAAD7cQA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E0FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664DED6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943252CF7A0@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252CF7A0@TK5EX14MBXC203.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_90C41DD21FB7C64BB94121FBBC2E7234465664E0FCP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Error registry proposal (round 3) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:56:22 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E0FCP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, This is intentional. The error registry defined in v2 is not designed to re= cord errors for the protected resource endpoint response or the WWW-Authent= icate response header when used with the Bearer token scheme (or any other = scheme). The only purpose of the registry is to avoid name collisions between two er= rors used differently with the v2 specification. Since errors used with the= Bearer token scheme will never appear in the same place as the v2 endpoint= s, there is no need for combining these two registries. If the bearer token specification requires error extensibility, you should = retain the registry there and limit it to just the protected resource respo= nse space. Ideally, you would limit it to just the WWW-Authenticate header = 'error' parameter when used with the Bearer scheme. The MAC scheme does not= use error codes, but instead, relies fully on HTTP status code since no ad= ditional error conditions were identified. Also, since your ABNF permits adding additional Authorization header parame= ters, you might want to consider defining a process for doing that, if you = are going to define an error registry. Currently, to add additional paramet= ers, one has to update the Bearer token RFC, in contrast to simply register= ing a new error code (which is likely to come out of a new parameter). EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 2:25 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) Thanks for writing this up, Eran. I believe that this is a step in the rig= ht direction. Wearing my Bearer Token spec editor hat, I just tried to go through the exe= rcise of editing my document to use the registry in draft 15 to register th= e errors defined in the bearer token spec and I hit a roadblock. Specifica= lly, while the errors defined by my spec are returned by resource servers (= flow F in Figure 1), the registry defined by draft 15 does not include "res= ource server error response" in the "error usage location" list. Can you p= lease add this additional error usage location so that the registry can be = used by the bearer token specification? At that point, I believe we'll be able to close the open issue about the ne= ed for an error registry, and I'll update my draft accordingly. Thank you, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, April 05, 2011 3:52 PM To: OAuth WG Subject: [OAUTH-WG] Error registry proposal (round 3) The following is my new proposal, based on Mike Jones' and my earlier propo= sals. It is basically a combination of the two. This proposal does not allow defining new error codes unless another extens= ion is involved (new grant type, request parameter, token type). The reason= for not defining an open ended error registry is that defining new error c= odes for existing implementations is bad for interoperability and can lead = to unexpected results (developers not taking into account receiving a new e= rror when talking to a compliant 2.0 server). We don't have any use cases f= or defining such new errors for the v2 specification. New errors only come = from extensions and must be defined in that context. I have applied to changes to the -14 draft and clearly marked them with [[P= ending Consensus]] so that there is no issue with removing them or changing= them later. --- Add to the error codes list in sections 4.1.2.1 and 4.2.2.1: a 4xx or 5xx HTTP status code (except for 400 and 401) The authorization server MAY set the "error" parameter value to a numerical HTTP status code from the 4xx or 5xx range, with the exception of the 400 (Bad Request) and 401 (Unauthorized) status codes. For example, if the service is temporarily unavailable, the authorization server MAY return an error response with "error" set to "503". Add a new section 8.4: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the token error response (Section 5.2), such error codes MAY be defined. Extension error codes MUST be registered (following the procedures in Section 10.3) if the extension they are used in conjunction with is registered. Additional error codes used with unregistered extensions MAY be registered. Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" should be named "example_invalid". error-code =3D ALPHA *error-char error-char =3D "-" / "." / "_" / DIGIT / ALPHA Add a new section 10.3: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app-ads@tools.ietf.org email address or d= irectly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. 10.3.1. Registration Template Error name: The name requested (e.g., "example"). Error usage location: The location(s) where the error can be used. The possible locations are: authorization code grant error response (Section 4.1.2.1), implicit grant error response (Section 4.2.2.1), or token error response (Section 5.2). Related protocol extension: The name of the extension grant type, access token type, or extension parameter, the error code is used in conjunction with. Change controller: For standards-track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included. Specification document(s): Reference to document that specifies the error code, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required. --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E0FCP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mike,

 

This is intentional. The error registry defined in = v2 is not designed to record errors for the protected resource endpoint res= ponse or the WWW-Authenticate response header when used with the Bearer tok= en scheme (or any other scheme).

=  

The only purpose of the registry is to av= oid name collisions between two errors used differently with the v2 specifi= cation. Since errors used with the Bearer token scheme will never appear in= the same place as the v2 endpoints, there is no need for combining these t= wo registries.

 

If the bearer token specification requires error extensibil= ity, you should retain the registry there and limit it to just the protecte= d resource response space. Ideally, you would limit it to just the WWW-Auth= enticate header ‘error’ parameter when used with the Bearer sch= eme. The MAC scheme does not use error codes, but instead, relies fully on = HTTP status code since no additional error conditions were identified.=

&n= bsp;

Als= o, since your ABNF permits adding additional Authorization header parameter= s, you might want to consider defining a process for doing that, if you are= going to define an error registry. Currently, to add additional parameters= , one has to update the Bearer token RFC, in contrast to simply registering= a new error code (which is likely to come out of a new parameter).

 = ;

EHL

=  

<= o:p> 

From: Mi= ke Jones [mailto:Michael.Jones@microsoft.com]
Sent: Wednesday, A= pril 06, 2011 2:25 PM
To: Eran Hammer-Lahav; OAuth WG
Subje= ct: RE: Error registry proposal (round 3)

 

Thanks for writing this up, Eran.  I believe tha= t this is a step in the right direction.

 

Wearing my Bearer Token spec edi= tor hat, I just tried to go through the exercise of editing my document to = use the registry in draft 15 to register the errors defined in the bearer t= oken spec and I hit a roadblock.  Specifically, while the errors defin= ed by my spec are returned by resource servers (flow F in Figure 1), the re= gistry defined by draft 15 does not include “resource server error re= sponse” in the “error usage location” list.  Can you= please add this additional error usage location so that the registry can b= e used by the bearer token specification?

 

At that point, I believe we̵= 7;ll be able to close the open issue about the need for an error registry, = and I’ll update my draft accordingly.

 

    &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;         Thank you,

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

&n= bsp;

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lah= av
Sent: Tuesday, April 05, 2011 3:52 PM
To: OAuth WGSubject: [OAUTH-WG] Error registry proposal (round 3)

 

The following is my new proposal, based on Mike Jones’ an= d my earlier proposals. It is basically a combination of the two.

 

T= his proposal does not allow defining new error codes unless another extensi= on is involved (new grant type, request parameter, token type). The reason = for not defining an open ended error registry is that defining new error co= des for existing implementations is bad for interoperability and can lead t= o unexpected results (developers not taking into account receiving a new er= ror when talking to a compliant 2.0 server). We don't have any use cases fo= r defining such new errors for the v2 specification. New errors only come f= rom extensions and must be defined in that context.

 

I have applied= to changes to the -14 draft and clearly marked them with [[Pending Consens= us]] so that there is no issue with removing them or changing them later.

 

---

 

Add to the error codes list in sections 4.1.2.1 and 4.2.= 2.1:

 

         a 4xx or 5xx HTTP st= atus code (except for 400 and 401)

&n= bsp;            = ;  The authorization server MAY set the "error" parameter

      &nb= sp;        value to a numerical HTTP sta= tus code from the 4xx or 5xx

 &n= bsp;            = ; range, with the exception of the 400 (Bad Request) and<= /p>

         &= nbsp;     401 (Unauthorized) status codes.  For ex= ample, if the

    = ;           service is te= mporarily unavailable, the authorization

            = ;   server MAY return an error response with "error" se= t to

     &n= bsp;         "503".<= /o:p>

 

 

Add a new section 8.= 4:

 

8.4.  Defining Additional Error Codes
 
<= pre>   In cases where protocol extens= ions (i.e. access token types,
   extension parameters, or extension grant types) re=
quire additional
&n=
bsp;  error codes to be used with the authorization code grant error
   respons=
e (Section 4.1.2.1), the implicit grant error response
   (Section 4.2.2.1), or the =
token error response (Section 5.2), such
   error codes MAY be defined.
 
<=
pre>   Extension error codes MUST be =
registered (following the procedures in
   Section 10.3) if the extension they are u=
sed in conjunction with is
   registered.  Additional error codes used with unr=
egistered extensions
   MAY be registered.
 
   Error codes MUST conform to the error-code ABNF, and SHOU=
LD be
   =
prefixed by an identifying name when possible.  For example, an error<=
o:p>
   identi=
fying an invalid value set to the extension parameter "example"
   should =
be named "example_invalid".
 
 
 =
;    error-code   =3D ALPHA *error-char=

     erro=
r-char   =3D "-" / "." / "_" / DIGI=
T / ALPHA

 <= /p>

 

Add= a new section 10.3:

 

10.3.  The OAuth Extensions Erro=
r Registry
&nb=
sp;
   This sp=
ecification establishes the OAuth extensions error registry.
 
   Additional error codes used toge= ther with other protocol extensions
   (i.e. extension grant types, access token typ=
es, or extension
&n=
bsp;  parameters) are registered on the advice of one or more Designat=
ed
   Exp=
erts (appointed by the IESG or their delegate), with a
   Specification Required (us=
ing terminology from [RFC5226]).  However,
   to allow for the allocation of va=
lues prior to publication, the
   Designated Expert(s) may approve registration once=
 they are satisfied
   that such a specification will be published.
 
=
   Registration requests should be se=
nt to the [TBD]@ietf.org mailing
   list for review and comment, with an appropriate=
 subject (e.g.,
&nb=
sp;  "Request for error code: example"). [[ Note to RFC-EDIT=
OR: The name
 =
  of the mailing list should be determined in consultation with the
   IESG and=
 IANA.  Suggested name: oauth-ext-review. ]]
 
   Within at most 14 days of the request, the =
Designated Expert(s) will
   either approve or deny the registration request, commun=
icating this
 =
  decision to the review list and IANA.  Denials should include a=
n
   expl=
anation and, if applicable, suggestions as to how to make the
   request successful.=

 <=
/span>
   Decisions (or lac=
k thereof) made by the Designated Expert can be
   first appealed to Application Are= a Directors (contactable using
   app-ads@=
tools.ietf.org email address or directly by looking up their=

   email addresses =
on http://www.iesg.org/ website) and, =
if the
  =
 appellant is not satisfied with the response, to the full IESG (using=

   the iesg@iesg.org mailing list).
 
   IANA should only accept registry = updates from the Designated
   Expert(s), and should direct all requests for registr=
ation to the
 =
  review mailing list.
 
10.=
3.1.  Registration Template
 
   Error name:
      The name requested (e.g., "exam=
ple").
 &=
nbsp; Error usage location:
      The location(s) where the error can=
 be used.  The possible
      locations are: authorization code =
grant error response
      (Section 4.1.2.1), implicit grant error re=
sponse
  =
    (Section 4.2.2.1), or token error response (Section 5.2)=
.
   Rela=
ted protocol extension:
      The name of the extension grant type, a=
ccess token type, or
      extension parameter, the error code is use=
d in conjunction with.
   Change controller:
      For standards-track RFCs, s=
tate "IETF".  For others, give the name
      of the r=
esponsible party.  Other details (e.g., postal address,
      e-=
mail address, home page URI) may also be included.
<=
pre>   Specification document(s):
   &nbs=
p;  Reference to document that specifies the error code, preferably
   &nb=
sp;  including a URI that can be used to retrieve a copy of the
    &=
nbsp; document.  An indication of the relevant sections may also be
   &nb=
sp;  included, but is not required.

 

 =

= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E0FCP3PW5EX1MB01E_-- From Michael.Jones@microsoft.com Wed Apr 6 15:37:23 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803C63A68B9 for ; Wed, 6 Apr 2011 15:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wP4Pd36Tb-1 for ; Wed, 6 Apr 2011 15:37:14 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id A93093A6801 for ; Wed, 6 Apr 2011 15:37:14 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 15:38:58 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.38]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0270.002; Wed, 6 Apr 2011 15:38:58 -0700 From: Mike Jones To: Eran Hammer-Lahav , OAuth WG Thread-Topic: Error registry proposal (round 3) Thread-Index: Acvz2lgK8+BMtZK8RZ2KEzyemyZs+QAxcVzgAAD7cQAAAcACEA== Date: Wed, 6 Apr 2011 22:38:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252CFA37@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465664DED6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943252CF7A0@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E0FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664E0FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252CFA37TK5EX14MBXC203r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Error registry proposal (round 3) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 22:37:23 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252CFA37TK5EX14MBXC203r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The problem with that situation is that it doesn't provide a central regist= ry for resource server error responses across specs, unlike the other kinds= of OAuth error responses. I could define that registry in the bearer toke= n spec, but it would be less confusing to unify it with the proposed regist= ry in the framework spec. I suspect developers would thank us for doing th= at. What do you say? -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 06, 2011 2:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Hi Mike, This is intentional. The error registry defined in v2 is not designed to re= cord errors for the protected resource endpoint response or the WWW-Authent= icate response header when used with the Bearer token scheme (or any other = scheme). The only purpose of the registry is to avoid name collisions between two er= rors used differently with the v2 specification. Since errors used with the= Bearer token scheme will never appear in the same place as the v2 endpoint= s, there is no need for combining these two registries. If the bearer token specification requires error extensibility, you should = retain the registry there and limit it to just the protected resource respo= nse space. Ideally, you would limit it to just the WWW-Authenticate header = 'error' parameter when used with the Bearer scheme. The MAC scheme does not= use error codes, but instead, relies fully on HTTP status code since no ad= ditional error conditions were identified. Also, since your ABNF permits adding additional Authorization header parame= ters, you might want to consider defining a process for doing that, if you = are going to define an error registry. Currently, to add additional paramet= ers, one has to update the Bearer token RFC, in contrast to simply register= ing a new error code (which is likely to come out of a new parameter). EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 2:25 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) Thanks for writing this up, Eran. I believe that this is a step in the rig= ht direction. Wearing my Bearer Token spec editor hat, I just tried to go through the exe= rcise of editing my document to use the registry in draft 15 to register th= e errors defined in the bearer token spec and I hit a roadblock. Specifica= lly, while the errors defined by my spec are returned by resource servers (= flow F in Figure 1), the registry defined by draft 15 does not include "res= ource server error response" in the "error usage location" list. Can you p= lease add this additional error usage location so that the registry can be = used by the bearer token specification? At that point, I believe we'll be able to close the open issue about the ne= ed for an error registry, and I'll update my draft accordingly. Thank you, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, April 05, 2011 3:52 PM To: OAuth WG Subject: [OAUTH-WG] Error registry proposal (round 3) The following is my new proposal, based on Mike Jones' and my earlier propo= sals. It is basically a combination of the two. This proposal does not allow defining new error codes unless another extens= ion is involved (new grant type, request parameter, token type). The reason= for not defining an open ended error registry is that defining new error c= odes for existing implementations is bad for interoperability and can lead = to unexpected results (developers not taking into account receiving a new e= rror when talking to a compliant 2.0 server). We don't have any use cases f= or defining such new errors for the v2 specification. New errors only come = from extensions and must be defined in that context. I have applied to changes to the -14 draft and clearly marked them with [[P= ending Consensus]] so that there is no issue with removing them or changing= them later. --- Add to the error codes list in sections 4.1.2.1 and 4.2.2.1: a 4xx or 5xx HTTP status code (except for 400 and 401) The authorization server MAY set the "error" parameter value to a numerical HTTP status code from the 4xx or 5xx range, with the exception of the 400 (Bad Request) and 401 (Unauthorized) status codes. For example, if the service is temporarily unavailable, the authorization server MAY return an error response with "error" set to "503". Add a new section 8.4: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the token error response (Section 5.2), such error codes MAY be defined. Extension error codes MUST be registered (following the procedures in Section 10.3) if the extension they are used in conjunction with is registered. Additional error codes used with unregistered extensions MAY be registered. Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" should be named "example_invalid". error-code =3D ALPHA *error-char error-char =3D "-" / "." / "_" / DIGIT / ALPHA Add a new section 10.3: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app-ads@tools.ietf.org email address or d= irectly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. 10.3.1. Registration Template Error name: The name requested (e.g., "example"). Error usage location: The location(s) where the error can be used. The possible locations are: authorization code grant error response (Section 4.1.2.1), implicit grant error response (Section 4.2.2.1), or token error response (Section 5.2). Related protocol extension: The name of the extension grant type, access token type, or extension parameter, the error code is used in conjunction with. Change controller: For standards-track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included. Specification document(s): Reference to document that specifies the error code, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required. --_000_4E1F6AAD24975D4BA5B1680429673943252CFA37TK5EX14MBXC203r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The problem with that = situation is that it doesn’t provide a central registry for resource = server error responses across specs, unlike the other kinds of OAuth error = responses.  I could define that registry in the bearer token spec, but it would be less confusing to unify it with the= proposed registry in the framework spec.  I suspect developers would = thank us for doing that.

 

What do you say?<= /o:p>

 

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

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, April 06, 2011 2:58 PM
To: Mike Jones; OAuth WG
Subject: RE: Error registry proposal (round 3)

 

Hi Mike,

 

This is intentional. T= he error registry defined in v2 is not designed to record errors for the pr= otected resource endpoint response or the WWW-Authenticate response header = when used with the Bearer token scheme (or any other scheme).

 

The only purpose of th= e registry is to avoid name collisions between two errors used differently = with the v2 specification. Since errors used with the Bearer token scheme w= ill never appear in the same place as the v2 endpoints, there is no need for combining these two registries.

 

If the bearer token sp= ecification requires error extensibility, you should retain the registry th= ere and limit it to just the protected resource response space. Ideally, yo= u would limit it to just the WWW-Authenticate header ‘error’ parameter when used with the Bearer scheme. The= MAC scheme does not use error codes, but instead, relies fully on HTTP sta= tus code since no additional error conditions were identified.

 

Also, since your ABNF = permits adding additional Authorization header parameters, you might want t= o consider defining a process for doing that, if you are going to define an= error registry. Currently, to add additional parameters, one has to update the Bearer token RFC, in contrast to simply = registering a new error code (which is likely to come out of a new paramete= r).

 

EHL<= /p>

 

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Wednesday, April 06, 2011 2:25 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error registry proposal (round 3)

 

Thanks for writing thi= s up, Eran.  I believe that this is a step in the right direction.

 

Wearing my Bearer Toke= n spec editor hat, I just tried to go through the exercise of editing my do= cument to use the registry in draft 15 to register the errors defined in th= e bearer token spec and I hit a roadblock.  Specifically, while the errors defined by my spec are returned by resource= servers (flow F in Figure 1), the registry defined by draft 15 does not in= clude “resource server error response” in the “error usag= e location” list.  Can you please add this additional error usage location so that the registry can be used by the bearer token = specification?

 

At that point, I belie= ve we’ll be able to close the open issue about the need for an error = registry, and I’ll update my draft accordingly.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Thank you,

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, April 05, 2011 3:52 PM
To: OAuth WG
Subject: [OAUTH-WG] Error registry proposal (round 3)

 

The following is my new proposal, based on Mike J= ones’ and my earlier proposals. It is basically a combination of the = two.

 

This proposal does not allow defining new error c= odes unless another extension is involved (new grant type, request paramete= r, token type). The reason for not defining an open ended error registry is= that defining new error codes for existing implementations is bad for interoperability and can lead to unexp= ected results (developers not taking into account receiving a new error whe= n talking to a compliant 2.0 server). We don't have any use cases for defin= ing such new errors for the v2 specification. New errors only come from extensions and must be defined in that context.<= o:p>

 

I have applied to changes to the -14 draft and cl= early marked them with [[Pending Consensus]] so that there is no issue with= removing them or changing them later.

 

---

 

Add to the error codes list in sections 4.1.2.1 a= nd 4.2.2.1:

 

       &nbs= p; a 4xx or 5xx HTTP status code (except for 400 and 401)=

       &nbs= p;       The authorization server MAY set the= "error" parameter

       &nbs= p;       value to a numerical HTTP status cod= e from the 4xx or 5xx

       &nbs= p;       range, with the exception of the 400= (Bad Request) and

       &nbs= p;       401 (Unauthorized) status codes.&nbs= p; For example, if the

       &nbs= p;       service is temporarily unavailable, = the authorization

       &nbs= p;       server MAY return an error response = with "error" set to

       &nbs= p;       "503".

 

 

Add a new section 8.4:

 

8.4.  Defining Additional Error Codes=

 
   In cases where protocol exten=
sions (i.e. access token types,
   extension parameters, or exte=
nsion grant types) require additional
   error codes to be used with t=
he authorization code grant error
   response (Section 4.1.2.1), t=
he implicit grant error response
   (Section 4.2.2.1), or the tok=
en error response (Section 5.2), such
   error codes MAY be defined.
 
   Extension error codes MUST be=
 registered (following the procedures in
   Section 10.3) if the extensio=
n they are used in conjunction with is
   registered.  Additional =
error codes used with unregistered extensions
   MAY be registered.=

 
   Error codes MUST conform to t=
he error-code ABNF, and SHOULD be
   prefixed by an identifying na=
me when possible.  For example, an error
   identifying an invalid value =
set to the extension parameter "example"
   should be named "example=
_invalid".
 
 
     error-code &=
nbsp; =3D ALPHA *error-char
     error-char &=
nbsp; =3D "-" / "." / "_" / DIGIT / ALPHA

 

 

Add a new section 10.3:

 

10.3.  The OAuth Extensions Error Reg=
istry
 
   This specification establishe=
s the OAuth extensions error registry.
 
   Additional error codes used t=
ogether with other protocol extensions
   (i.e. extension grant types, =
access token types, or extension
   parameters) are registered on=
 the advice of one or more Designated
   Experts (appointed by the IES=
G or their delegate), with a
   Specification Required (using=
 terminology from [RFC5226]).  However,
   to allow for the allocation o=
f values prior to publication, the
   Designated Expert(s) may appr=
ove registration once they are satisfied
   that such a specification wil=
l be published.
 
   Registration requests should =
be sent to the [TBD]@ietf.org mailing
   list for review and comment, =
with an appropriate subject (e.g.,
   "Request for error code:=
 example"). [[ Note to RFC-EDITOR: The name
   of the mailing list should be=
 determined in consultation with the
   IESG and IANA.  Suggeste=
d name: oauth-ext-review. ]]
 
   Within at most 14 days of the=
 request, the Designated Expert(s) will
   either approve or deny the re=
gistration request, communicating this
   decision to the review list a=
nd IANA.  Denials should include an
   explanation and, if applicabl=
e, suggestions as to how to make the
   request successful.
 
   Decisions (or lack thereof) m=
ade by the Designated Expert can be
   first appealed to Application=
 Area Directors (contactable using
   app-ads@tools.ietf.org email address or directly by lookin=
g up their
   email addresses on http://www.iesg.org/ website) and, if the
   appellant is not satisfied wi=
th the response, to the full IESG (using
   the iesg@iesg.org mailing list).
 
   IANA should only accept regis=
try updates from the Designated
   Expert(s), and should direct =
all requests for registration to the
   review mailing list.
 
10.3.1.  Registration Template
 
   Error name:=

      The name re=
quested (e.g., "example").
   Error usage location:
      The locatio=
n(s) where the error can be used.  The possible

      locations a=
re: authorization code grant error response


      (Section 4.=
1.2.1), implicit grant error response


      (Section 4.=
2.2.1), or token error response (Section 5.2).


   Related protocol extension:


      The name of=
 the extension grant type, access token type, or


      extension p=
arameter, the error code is used in conjunction with.

   Change controller:=



      For standar=
ds-track RFCs, state "IETF".  For others, give the name=



      of the resp=
onsible party.  Other details (e.g., postal address,=



      e-mail addr=
ess, home page URI) may also be included.


   Specification document(s):


      Reference t=
o document that specifies the error code, preferably

      including a=
 URI that can be used to retrieve a copy of the


      document.&n=
bsp; An indication of the relevant sections may also be

      included, b=
ut is not required.


 


 
--_000_4E1F6AAD24975D4BA5B1680429673943252CFA37TK5EX14MBXC203r_-- From eran@hueniverse.com Wed Apr 6 15:56:49 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04CAA3A67EF for ; Wed, 6 Apr 2011 15:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AVDcvElP7KG for ; Wed, 6 Apr 2011 15:56:38 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id DC8973A67EB for ; Wed, 6 Apr 2011 15:56:37 -0700 (PDT) Received: (qmail 4358 invoked from network); 6 Apr 2011 22:58:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2011 22:58:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 6 Apr 2011 15:58:16 -0700 From: Eran Hammer-Lahav To: Mike Jones , OAuth WG Date: Wed, 6 Apr 2011 15:58:09 -0700 Thread-Topic: Error registry proposal (round 3) Thread-Index: Acvz2lgK8+BMtZK8RZ2KEzyemyZs+QAxcVzgAAD7cQAAAcACEAAAJh8Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E10E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664DED6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943252CF7A0@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E0FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943252CFA37@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252CFA37@TK5EX14MBXC203.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_90C41DD21FB7C64BB94121FBBC2E7234465664E10EP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Error registry proposal (round 3) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 22:56:49 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E10EP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Putting aside my view that a registry for resource server error responses a= cross HTTP authentication schemes isn't very useful or interesting, I don't= have an objection to the bearer token specification defining such general = purpose registry. In a way, it is similar to the error response headers def= ined by Digest, only never made generally applicable. The difference in our approaches is that I don't consider the bearer token = or mac token specs to be extensions of the v2 spec, but fully specified HTT= P authentication schemes with OAuth 2.0 binding (i.e. the access token type= registration). Because of that, I don't think the v2 spec is the right pla= ce for such a registry, which is really about HTTP authentication schemes a= nd not OAuth. Therefore, I think it will be more confusing to put such a re= gistry in v2. I'll give you an example. Suppose someone will define a Digest access token= type. When issuing one, the server will send an access token (to be used a= s username) and a secret (to be used as password). To use such a token, the= client will use the HTTP Digest scheme (as is). Digest defines its own set= and method or specifying error code. Would you expect those to be register= ed in your proposed registry? I would assume not. For such a registry to be useful, you also need to standardize the authenti= cation header across all schemes and define a standard parameter used to de= liver such error codes. However, we already moved away from that design by = defining separate HTTP authentication schemes for each token type. But again, I don't have an objection to such a registry defined in the bear= er token spec. I have no intentions of using it for any HTTP authentication= scheme I plan to author. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 3:39 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) The problem with that situation is that it doesn't provide a central regist= ry for resource server error responses across specs, unlike the other kinds= of OAuth error responses. I could define that registry in the bearer toke= n spec, but it would be less confusing to unify it with the proposed regist= ry in the framework spec. I suspect developers would thank us for doing th= at. What do you say? -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 06, 2011 2:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Hi Mike, This is intentional. The error registry defined in v2 is not designed to re= cord errors for the protected resource endpoint response or the WWW-Authent= icate response header when used with the Bearer token scheme (or any other = scheme). The only purpose of the registry is to avoid name collisions between two er= rors used differently with the v2 specification. Since errors used with the= Bearer token scheme will never appear in the same place as the v2 endpoint= s, there is no need for combining these two registries. If the bearer token specification requires error extensibility, you should = retain the registry there and limit it to just the protected resource respo= nse space. Ideally, you would limit it to just the WWW-Authenticate header = 'error' parameter when used with the Bearer scheme. The MAC scheme does not= use error codes, but instead, relies fully on HTTP status code since no ad= ditional error conditions were identified. Also, since your ABNF permits adding additional Authorization header parame= ters, you might want to consider defining a process for doing that, if you = are going to define an error registry. Currently, to add additional paramet= ers, one has to update the Bearer token RFC, in contrast to simply register= ing a new error code (which is likely to come out of a new parameter). EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 2:25 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) Thanks for writing this up, Eran. I believe that this is a step in the rig= ht direction. Wearing my Bearer Token spec editor hat, I just tried to go through the exe= rcise of editing my document to use the registry in draft 15 to register th= e errors defined in the bearer token spec and I hit a roadblock. Specifica= lly, while the errors defined by my spec are returned by resource servers (= flow F in Figure 1), the registry defined by draft 15 does not include "res= ource server error response" in the "error usage location" list. Can you p= lease add this additional error usage location so that the registry can be = used by the bearer token specification? At that point, I believe we'll be able to close the open issue about the ne= ed for an error registry, and I'll update my draft accordingly. Thank you, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, April 05, 2011 3:52 PM To: OAuth WG Subject: [OAUTH-WG] Error registry proposal (round 3) The following is my new proposal, based on Mike Jones' and my earlier propo= sals. It is basically a combination of the two. This proposal does not allow defining new error codes unless another extens= ion is involved (new grant type, request parameter, token type). The reason= for not defining an open ended error registry is that defining new error c= odes for existing implementations is bad for interoperability and can lead = to unexpected results (developers not taking into account receiving a new e= rror when talking to a compliant 2.0 server). We don't have any use cases f= or defining such new errors for the v2 specification. New errors only come = from extensions and must be defined in that context. I have applied to changes to the -14 draft and clearly marked them with [[P= ending Consensus]] so that there is no issue with removing them or changing= them later. --- Add to the error codes list in sections 4.1.2.1 and 4.2.2.1: a 4xx or 5xx HTTP status code (except for 400 and 401) The authorization server MAY set the "error" parameter value to a numerical HTTP status code from the 4xx or 5xx range, with the exception of the 400 (Bad Request) and 401 (Unauthorized) status codes. For example, if the service is temporarily unavailable, the authorization server MAY return an error response with "error" set to "503". Add a new section 8.4: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the token error response (Section 5.2), such error codes MAY be defined. Extension error codes MUST be registered (following the procedures in Section 10.3) if the extension they are used in conjunction with is registered. Additional error codes used with unregistered extensions MAY be registered. Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" should be named "example_invalid". error-code =3D ALPHA *error-char error-char =3D "-" / "." / "_" / DIGIT / ALPHA Add a new section 10.3: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app-ads@tools.ietf.org email address or d= irectly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. 10.3.1. Registration Template Error name: The name requested (e.g., "example"). Error usage location: The location(s) where the error can be used. The possible locations are: authorization code grant error response (Section 4.1.2.1), implicit grant error response (Section 4.2.2.1), or token error response (Section 5.2). Related protocol extension: The name of the extension grant type, access token type, or extension parameter, the error code is used in conjunction with. Change controller: For standards-track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included. Specification document(s): Reference to document that specifies the error code, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required. --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E10EP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Putting aside my view that a registry for resource server err= or responses across HTTP authentication schemes isn’t very useful or = interesting, I don’t have an objection to the bearer token specificat= ion defining such general purpose registry. In a way, it is similar to the = error response headers defined by Digest, only never made generally applica= ble.

 

The difference in our approaches is that I don’t consider the b= earer token or mac token specs to be extensions of the v2 spec, but fully s= pecified HTTP authentication schemes with OAuth 2.0 binding (i.e. the acces= s token type registration). Because of that, I don’t think the v2 spe= c is the right place for such a registry, which is really about HTTP authen= tication schemes and not OAuth. Therefore, I think it will be more confusin= g to put such a registry in v2.

<= span style=3D'color:#1F497D'> 

I’ll give you an example. Suppose so= meone will define a Digest access token type. When issuing one, the server = will send an access token (to be used as username) and a secret (to be used= as password). To use such a token, the client will use the HTTP Digest sch= eme (as is). Digest defines its own set and method or specifying error code= . Would you expect those to be registered in your proposed registry? I woul= d assume not.

 

For such a registry to be useful, you also need to standardi= ze the authentication header across all schemes and define a standard param= eter used to deliver such error codes. However, we already moved away from = that design by defining separate HTTP authentication schemes for each token= type.

 

But again, I don’t have an objection to such a registry defin= ed in the bearer token spec. I have no intentions of using it for any HTTP = authentication scheme I plan to author.

 

EHL

 

 

 

 

 

From: Mike Jones [mail= to:Michael.Jones@microsoft.com]
Sent: Wednesday, April 06, 2011 = 3:39 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Er= ror registry proposal (round 3)

 

The problem with that situation is that it doesn’t provide = a central registry for resource server error responses across specs, unlike= the other kinds of OAuth error responses.  I could define that regist= ry in the bearer token spec, but it would be less confusing to unify it wit= h the proposed registry in the framework spec.  I suspect developers w= ould thank us for doing that.

 

What do you say?

 

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

 =

From: Eran Hammer-Lahav [mailto= :eran@hueniverse.com]
Sent: Wednesday, April 06, 2011 2:58 PMTo: Mike Jones; OAuth WG
Subject: RE: Error registry prop= osal (round 3)

&= nbsp;

Hi Mike,<= o:p>

 

This is intentional. The error registry defined in v2 is not designed to r= ecord errors for the protected resource endpoint response or the WWW-Authen= ticate response header when used with the Bearer token scheme (or any other= scheme).

 

The only purpose of the registry is to avoid name collisions bet= ween two errors used differently with the v2 specification. Since errors us= ed with the Bearer token scheme will never appear in the same place as the = v2 endpoints, there is no need for combining these two registries.

 =

If the = bearer token specification requires error extensibility, you should retain = the registry there and limit it to just the protected resource response spa= ce. Ideally, you would limit it to just the WWW-Authenticate header ‘= error’ parameter when used with the Bearer scheme. The MAC scheme doe= s not use error codes, but instead, relies fully on HTTP status code since = no additional error conditions were identified.

 

Also, since your ABNF perm= its adding additional Authorization header parameters, you might want to co= nsider defining a process for doing that, if you are going to define an err= or registry. Currently, to add additional parameters, one has to update the= Bearer token RFC, in contrast to simply registering a new error code (whic= h is likely to come out of a new parameter).

 

EHL

 

 

From: Mike Jones [mailto:Micha= el.Jones@microsoft.com]
Sent: Wednesday, April 06, 2011 2:25 PM<= br>To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error regi= stry proposal (round 3)

 

= Thanks for writing this up, Eran.  I believe that this is a step in th= e right direction.

 

Wearing my Bearer Token spec editor hat, I just tried t= o go through the exercise of editing my document to use the registry in dra= ft 15 to register the errors defined in the bearer token spec and I hit a r= oadblock.  Specifically, while the errors defined by my spec are retur= ned by resource servers (flow F in Figure 1), the registry defined by draft= 15 does not include “resource server error response” in the &#= 8220;error usage location” list.  Can you please add this additi= onal error usage location so that the registry can be used by the bearer to= ken specification?

 

At that point, I believe we’ll be able to close t= he open issue about the need for an error registry, and I’ll update m= y draft accordingly.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Thank you,

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

 

From: oauth-bounces@ietf.org [mailto:oauth-bo= unces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Tuesd= ay, April 05, 2011 3:52 PM
To: OAuth WG
Subject: [OAUTH= -WG] Error registry proposal (round 3)

 

The followin= g is my new proposal, based on Mike Jones’ and my earlier proposals. = It is basically a combination of the two.

 

This proposal does not al= low defining new error codes unless another extension is involved (new gran= t type, request parameter, token type). The reason for not defining an open= ended error registry is that defining new error codes for existing impleme= ntations is bad for interoperability and can lead to unexpected results (de= velopers not taking into account receiving a new error when talking to a co= mpliant 2.0 server). We don't have any use cases for defining such new erro= rs for the v2 specification. New errors only come from extensions and must = be defined in that context.

&nbs= p;

I have applied to changes to the -14 dr= aft and clearly marked them with [[Pending Consensus]] so that there is no = issue with removing them or changing them later.

 

---

=

 

Add to= the error codes list in sections 4.1.2.1 and 4.2.2.1:

 

   &= nbsp;     a 4xx or 5xx HTTP status code (except for 400= and 401)

    &nb= sp;          The authorization= server MAY set the "error" parameter

          &nbs= p;    value to a numerical HTTP status code from the 4xx or = 5xx

     &nb= sp;         range, with the excepti= on of the 400 (Bad Request) and

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'> = ;            &n= bsp; 401 (Unauthorized) status codes.  For example, if the<= /span>

        =        service is temporarily unavailable, th= e authorization

   &nb= sp;           server MAY = return an error response with "error" set to

         &nb= sp;     "503".

 

 

Add a new section 8.4:

 

8.4.=
  Defining Additional Error Codes
 
   In cases where protocol extensions (i.e. access token =
types,
  =
 extension parameters, or extension grant types) require additional
   error codes t=
o be used with the authorization code grant error
   response (Section 4.1.2.1), the= implicit grant error response
   (Section 4.2.2.1), or the token error response (Se=
ction 5.2), such
&n=
bsp;  error codes MAY be defined.
 
   Extension error codes MUST be registered (following th=
e procedures in
&nb=
sp;  Section 10.3) if the extension they are used in conjunction with =
is
   reg=
istered.  Additional error codes used with unregistered extensions
   MAY be re=
gistered.
&nbs=
p;
   Error co=
des MUST conform to the error-code ABNF, and SHOULD be
   prefixed by an identifying=
 name when possible.  For example, an error
   identifying an invalid value set=
 to the extension parameter "example"
   should be named "example_inv= alid".
&n=
bsp;
 
     error-=
code   =3D ALPHA *error-char
     error-char   =3D &qu=
ot;-" / "." / "_" / DIGIT / ALPHA

 

 

Add a new section 10.3:<= /o:p>

 

10.3.  The OAuth Extensions Error Registry
 
   This specification establishes th= e OAuth extensions error registry.
 
   Additional error codes used together with other protocol =
extensions
 &n=
bsp; (i.e. extension grant types, access token types, or extension
   parameters) ar=
e registered on the advice of one or more Designated
   Experts (appointed by the IE=
SG or their delegate), with a
   Specification Required (using terminology from [RFC=
5226]).  However,
   to allow for the allocation of values prior to publication=
, the
   =
Designated Expert(s) may approve registration once they are satisfied<=
/o:p>
   that such a=
 specification will be published.
 
   Registration requests should be sent to the [TBD]@ietf.or=
g mailing
 &nb=
sp; list for review and comment, with an appropriate subject (e.g.,
   "Request=
 for error code: example"). [[ Note to RFC-EDITOR: The name=

   of the mailing l=
ist should be determined in consultation with the
   IESG and IANA.  Suggested =
name: oauth-ext-review. ]]
 
&nbs=
p;  Within at most 14 days of the request, the Designated Expert(s) wi=
ll
   eit=
her approve or deny the registration request, communicating this=

   decision to the =
review list and IANA.  Denials should include an
   explanation and, if applica=
ble, suggestions as to how to make the
   request successful.
 
   Decisions (or lack thereof) made by the =
Designated Expert can be
   first appealed to Application Area Directors (contactabl=
e using
  =
; app-ads@tools.ietf.org emai=
l address or directly by looking up their
   email addresses on http://www.iesg.org/ website) and, if the
   appellant is not satis=
fied with the response, to the full IESG (using
   the iesg@iesg.org mailing list).
 
   IANA should only accept registry updates from the Design=
ated
   E=
xpert(s), and should direct all requests for registration to the=

   review mailing l=
ist.
 
10.3.1.  Registration=
 Template
&nbs=
p;
   Error na=
me:
  &nb=
sp;   The name requested (e.g., "example").<=
/span>
   Error usage locat=
ion:
  &n=
bsp;   The location(s) where the error can be used.  The pos=
sible
  &=
nbsp;   locations are: authorization code grant error response
    &n=
bsp; (Section 4.1.2.1), implicit grant error response
      (Sec=
tion 4.2.2.1), or token error response (Section 5.2).
   Related protocol extension:=

   =
   The name of the extension grant type, access token type, or
   &nb=
sp;  extension parameter, the error code is used in conjunction with.<=
o:p>
   Change=
 controller:
 =
     For standards-track RFCs, state "IETF".&=
nbsp; For others, give the name
      of the responsible party. =
 Other details (e.g., postal address,
      e-mail address, home page=
 URI) may also be included.
   Specification document(s):
      Reference to d=
ocument that specifies the error code, preferably
      including a U=
RI that can be used to retrieve a copy of the
<=
span style=3D'color:black'>      document.  A=
n indication of the relevant sections may also be
      included, but= is not required.

 = ;

 

<= /body>= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E10EP3PW5EX1MB01E_-- From Michael.Jones@microsoft.com Wed Apr 6 16:11:27 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4744C3A67FC for ; Wed, 6 Apr 2011 16:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2+zHL8YGfhp for ; Wed, 6 Apr 2011 16:11:12 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 908153A6804 for ; Wed, 6 Apr 2011 16:11:09 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 16:12:53 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.38]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0270.002; Wed, 6 Apr 2011 16:12:54 -0700 From: Mike Jones To: Eran Hammer-Lahav , OAuth WG Thread-Topic: Error registry proposal (round 3) Thread-Index: Acvz2lgK8+BMtZK8RZ2KEzyemyZs+QAxcVzgAAD7cQAAAcACEAAAJh8QAADiaFA= Date: Wed, 6 Apr 2011 23:12:53 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252CFB54@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465664DED6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943252CF7A0@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E0FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943252CFA37@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E10E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664E10E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252CFB54TK5EX14MBXC203r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Error registry proposal (round 3) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 23:11:27 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252CFB54TK5EX14MBXC203r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, you correctly point out (indirectly), that this is related to one= of the open issues that needs to be resolved to complete the specs when yo= u wrote "For such a registry to be useful, you also need to standardize the= authentication header across all schemes and define a standard parameter u= sed to deliver such error codes". This open issue (which there wasn't time to discuss during last week's meet= ing) was the removal of the WWW-Authenticate Response Header. This feature= was present in WRAP and earlier OAuth drafts but was removed without a cle= ar consensus to do so. And indeed, during our private discussions on how t= he draft should be split, at that time, you took the position that the WWW-= Authenticate response should remain in the framework spec. The result has been that there is different and incompatible WWW-Authentica= te response functionality in multiple related drafts - specifically draft-h= ammer-oauth-v2-mac-token-02 and draft-ietf-oauth-v2-bearer-04. Interoperab= ility and developers would both be better served by moving this functionali= ty back into the core. I don't believe that each related OAuth specificatio= n should have to separately specify this functionality. As this was not di= scussed during last week's meeting, a consensus call from the chairs may be= necessary to resolve this issue. -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 06, 2011 3:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Putting aside my view that a registry for resource server error responses a= cross HTTP authentication schemes isn't very useful or interesting, I don't= have an objection to the bearer token specification defining such general = purpose registry. In a way, it is similar to the error response headers def= ined by Digest, only never made generally applicable. The difference in our approaches is that I don't consider the bearer token = or mac token specs to be extensions of the v2 spec, but fully specified HTT= P authentication schemes with OAuth 2.0 binding (i.e. the access token type= registration). Because of that, I don't think the v2 spec is the right pla= ce for such a registry, which is really about HTTP authentication schemes a= nd not OAuth. Therefore, I think it will be more confusing to put such a re= gistry in v2. I'll give you an example. Suppose someone will define a Digest access token= type. When issuing one, the server will send an access token (to be used a= s username) and a secret (to be used as password). To use such a token, the= client will use the HTTP Digest scheme (as is). Digest defines its own set= and method or specifying error code. Would you expect those to be register= ed in your proposed registry? I would assume not. For such a registry to be useful, you also need to standardize the authenti= cation header across all schemes and define a standard parameter used to de= liver such error codes. However, we already moved away from that design by = defining separate HTTP authentication schemes for each token type. But again, I don't have an objection to such a registry defined in the bear= er token spec. I have no intentions of using it for any HTTP authentication= scheme I plan to author. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 3:39 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) The problem with that situation is that it doesn't provide a central regist= ry for resource server error responses across specs, unlike the other kinds= of OAuth error responses. I could define that registry in the bearer toke= n spec, but it would be less confusing to unify it with the proposed regist= ry in the framework spec. I suspect developers would thank us for doing th= at. What do you say? -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 06, 2011 2:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Hi Mike, This is intentional. The error registry defined in v2 is not designed to re= cord errors for the protected resource endpoint response or the WWW-Authent= icate response header when used with the Bearer token scheme (or any other = scheme). The only purpose of the registry is to avoid name collisions between two er= rors used differently with the v2 specification. Since errors used with the= Bearer token scheme will never appear in the same place as the v2 endpoint= s, there is no need for combining these two registries. If the bearer token specification requires error extensibility, you should = retain the registry there and limit it to just the protected resource respo= nse space. Ideally, you would limit it to just the WWW-Authenticate header = 'error' parameter when used with the Bearer scheme. The MAC scheme does not= use error codes, but instead, relies fully on HTTP status code since no ad= ditional error conditions were identified. Also, since your ABNF permits adding additional Authorization header parame= ters, you might want to consider defining a process for doing that, if you = are going to define an error registry. Currently, to add additional paramet= ers, one has to update the Bearer token RFC, in contrast to simply register= ing a new error code (which is likely to come out of a new parameter). EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 2:25 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) Thanks for writing this up, Eran. I believe that this is a step in the rig= ht direction. Wearing my Bearer Token spec editor hat, I just tried to go through the exe= rcise of editing my document to use the registry in draft 15 to register th= e errors defined in the bearer token spec and I hit a roadblock. Specifica= lly, while the errors defined by my spec are returned by resource servers (= flow F in Figure 1), the registry defined by draft 15 does not include "res= ource server error response" in the "error usage location" list. Can you p= lease add this additional error usage location so that the registry can be = used by the bearer token specification? At that point, I believe we'll be able to close the open issue about the ne= ed for an error registry, and I'll update my draft accordingly. Thank you, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, April 05, 2011 3:52 PM To: OAuth WG Subject: [OAUTH-WG] Error registry proposal (round 3) The following is my new proposal, based on Mike Jones' and my earlier propo= sals. It is basically a combination of the two. This proposal does not allow defining new error codes unless another extens= ion is involved (new grant type, request parameter, token type). The reason= for not defining an open ended error registry is that defining new error c= odes for existing implementations is bad for interoperability and can lead = to unexpected results (developers not taking into account receiving a new e= rror when talking to a compliant 2.0 server). We don't have any use cases f= or defining such new errors for the v2 specification. New errors only come = from extensions and must be defined in that context. I have applied to changes to the -14 draft and clearly marked them with [[P= ending Consensus]] so that there is no issue with removing them or changing= them later. --- Add to the error codes list in sections 4.1.2.1 and 4.2.2.1: a 4xx or 5xx HTTP status code (except for 400 and 401) The authorization server MAY set the "error" parameter value to a numerical HTTP status code from the 4xx or 5xx range, with the exception of the 400 (Bad Request) and 401 (Unauthorized) status codes. For example, if the service is temporarily unavailable, the authorization server MAY return an error response with "error" set to "503". Add a new section 8.4: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the token error response (Section 5.2), such error codes MAY be defined. Extension error codes MUST be registered (following the procedures in Section 10.3) if the extension they are used in conjunction with is registered. Additional error codes used with unregistered extensions MAY be registered. Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" should be named "example_invalid". error-code =3D ALPHA *error-char error-char =3D "-" / "." / "_" / DIGIT / ALPHA Add a new section 10.3: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app-ads@tools.ietf.org email address or d= irectly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. 10.3.1. Registration Template Error name: The name requested (e.g., "example"). Error usage location: The location(s) where the error can be used. The possible locations are: authorization code grant error response (Section 4.1.2.1), implicit grant error response (Section 4.2.2.1), or token error response (Section 5.2). Related protocol extension: The name of the extension grant type, access token type, or extension parameter, the error code is used in conjunction with. Change controller: For standards-track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included. Specification document(s): Reference to document that specifies the error code, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required. --_000_4E1F6AAD24975D4BA5B1680429673943252CFB54TK5EX14MBXC203r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, you correctl= y point out (indirectly), that this is related to one of the open issues th= at needs to be resolved to complete the specs when you wrote “= For such a registry to be useful, you also need to standardize the authentication header acros= s all schemes and define a standard parameter used to deliver such error co= des”.

 

This open issue (which= there wasn’t time to discuss during last week’s meeting) was t= he removal of the WWW-Authenticate Response Header.  This feature was = present in WRAP and earlier OAuth drafts but was removed without a clear consensus to do so.  And indeed, during our private d= iscussions on how the draft should be split, at that time, you took the pos= ition that the WWW-Authenticate response should remain in the framework spe= c.

 

The result has been th= at there is different and incompatible WWW-Authenticate response functional= ity in multiple related drafts – specifically draft-hammer-oauth-v2-m= ac-token-02 and draft-ietf-oauth-v2-bearer-04.  Interoperability and developers would both be better served by moving this= functionality back into the core. I don’t believe that each related = OAuth specification should have to separately specify this functionality.&n= bsp; As this was not discussed during last week’s meeting, a consensus call from the chairs may be necessary to= resolve this issue.

 

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

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, April 06, 2011 3:58 PM
To: Mike Jones; OAuth WG
Subject: RE: Error registry proposal (round 3)

 

Putting aside my view = that a registry for resource server error responses across HTTP authenticat= ion schemes isn’t very useful or interesting, I don’t have an o= bjection to the bearer token specification defining such general purpose registry. In a way, it is similar to the error respon= se headers defined by Digest, only never made generally applicable.

 

The difference in our = approaches is that I don’t consider the bearer token or mac token spe= cs to be extensions of the v2 spec, but fully specified HTTP authentication= schemes with OAuth 2.0 binding (i.e. the access token type registration). Because of that, I don’t think the = v2 spec is the right place for such a registry, which is really about HTTP = authentication schemes and not OAuth. Therefore, I think it will be more co= nfusing to put such a registry in v2.

 

I’ll give you an= example. Suppose someone will define a Digest access token type. When issu= ing one, the server will send an access token (to be used as username) and = a secret (to be used as password). To use such a token, the client will use the HTTP Digest scheme (as is). Digest d= efines its own set and method or specifying error code. Would you expect th= ose to be registered in your proposed registry? I would assume not.

 

For such a registry to= be useful, you also need to standardize the authentication header across a= ll schemes and define a standard parameter used to deliver such error codes= . However, we already moved away from that design by defining separate HTTP authentication schemes for each toke= n type.

 

But again, I don’= ;t have an objection to such a registry defined in the bearer token spec. I= have no intentions of using it for any HTTP authentication scheme I plan t= o author.

 

EHL<= /p>

 

 

 

 

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Wednesday, April 06, 2011 3:39 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error registry proposal (round 3)

 

The problem with that = situation is that it doesn’t provide a central registry for resource = server error responses across specs, unlike the other kinds of OAuth error = responses.  I could define that registry in the bearer token spec, but it would be less confusing to unify it with the= proposed registry in the framework spec.  I suspect developers would = thank us for doing that.

 

What do you say?<= /o:p>

 

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

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, April 06, 2011 2:58 PM
To: Mike Jones; OAuth WG
Subject: RE: Error registry proposal (round 3)

 

Hi Mike,

 

This is intentional. T= he error registry defined in v2 is not designed to record errors for the pr= otected resource endpoint response or the WWW-Authenticate response header = when used with the Bearer token scheme (or any other scheme).

 

The only purpose of th= e registry is to avoid name collisions between two errors used differently = with the v2 specification. Since errors used with the Bearer token scheme w= ill never appear in the same place as the v2 endpoints, there is no need for combining these two registries.

 

If the bearer token sp= ecification requires error extensibility, you should retain the registry th= ere and limit it to just the protected resource response space. Ideally, yo= u would limit it to just the WWW-Authenticate header ‘error’ parameter when used with the Bearer scheme. The= MAC scheme does not use error codes, but instead, relies fully on HTTP sta= tus code since no additional error conditions were identified.

 

Also, since your ABNF = permits adding additional Authorization header parameters, you might want t= o consider defining a process for doing that, if you are going to define an= error registry. Currently, to add additional parameters, one has to update the Bearer token RFC, in contrast to simply = registering a new error code (which is likely to come out of a new paramete= r).

 

EHL<= /p>

 

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Wednesday, April 06, 2011 2:25 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error registry proposal (round 3)

 

Thanks for writing thi= s up, Eran.  I believe that this is a step in the right direction.

 

Wearing my Bearer Toke= n spec editor hat, I just tried to go through the exercise of editing my do= cument to use the registry in draft 15 to register the errors defined in th= e bearer token spec and I hit a roadblock.  Specifically, while the errors defined by my spec are returned by resource= servers (flow F in Figure 1), the registry defined by draft 15 does not in= clude “resource server error response” in the “error usag= e location” list.  Can you please add this additional error usage location so that the registry can be used by the bearer token = specification?

 

At that point, I belie= ve we’ll be able to close the open issue about the need for an error = registry, and I’ll update my draft accordingly.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Thank you,

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, April 05, 2011 3:52 PM
To: OAuth WG
Subject: [OAUTH-WG] Error registry proposal (round 3)

 

The following is my new proposal, based on Mike J= ones’ and my earlier proposals. It is basically a combination of the = two.

 

This proposal does not allow defining new error c= odes unless another extension is involved (new grant type, request paramete= r, token type). The reason for not defining an open ended error registry is= that defining new error codes for existing implementations is bad for interoperability and can lead to unexp= ected results (developers not taking into account receiving a new error whe= n talking to a compliant 2.0 server). We don't have any use cases for defin= ing such new errors for the v2 specification. New errors only come from extensions and must be defined in that context.<= o:p>

 

I have applied to changes to the -14 draft and cl= early marked them with [[Pending Consensus]] so that there is no issue with= removing them or changing them later.

 

---

 

Add to the error codes list in sections 4.1.2.1 a= nd 4.2.2.1:

 

       &nbs= p; a 4xx or 5xx HTTP status code (except for 400 and 401)=

       &nbs= p;       The authorization server MAY set the= "error" parameter

       &nbs= p;       value to a numerical HTTP status cod= e from the 4xx or 5xx

       &nbs= p;       range, with the exception of the 400= (Bad Request) and

       &nbs= p;       401 (Unauthorized) status codes.&nbs= p; For example, if the

       &nbs= p;       service is temporarily unavailable, = the authorization

       &nbs= p;       server MAY return an error response = with "error" set to

       &nbs= p;       "503".

 

 

Add a new section 8.4:

 

8.4.  Defining Additional Error Codes=

 
   In cases where protocol exten=
sions (i.e. access token types,
   extension parameters, or exte=
nsion grant types) require additional
   error codes to be used with t=
he authorization code grant error
   response (Section 4.1.2.1), t=
he implicit grant error response
   (Section 4.2.2.1), or the tok=
en error response (Section 5.2), such
   error codes MAY be defined.
 
   Extension error codes MUST be=
 registered (following the procedures in
   Section 10.3) if the extensio=
n they are used in conjunction with is
   registered.  Additional =
error codes used with unregistered extensions
   MAY be registered.=

 
   Error codes MUST conform to t=
he error-code ABNF, and SHOULD be
   prefixed by an identifying na=
me when possible.  For example, an error
   identifying an invalid value =
set to the extension parameter "example"
   should be named "example=
_invalid".
 
 
     error-code &=
nbsp; =3D ALPHA *error-char
     error-char &=
nbsp; =3D "-" / "." / "_" / DIGIT / ALPHA

 

 

Add a new section 10.3:

 

10.3.  The OAuth Extensions Error Reg=
istry
 
   This specification establishe=
s the OAuth extensions error registry.
 
   Additional error codes used t=
ogether with other protocol extensions
   (i.e. extension grant types, =
access token types, or extension
   parameters) are registered on=
 the advice of one or more Designated
   Experts (appointed by the IES=
G or their delegate), with a
   Specification Required (using=
 terminology from [RFC5226]).  However,
   to allow for the allocation o=
f values prior to publication, the
   Designated Expert(s) may appr=
ove registration once they are satisfied
   that such a specification wil=
l be published.
 
   Registration requests should =
be sent to the [TBD]@ietf.org mailing
   list for review and comment, =
with an appropriate subject (e.g.,
   "Request for error code:=
 example"). [[ Note to RFC-EDITOR: The name
   of the mailing list should be=
 determined in consultation with the
   IESG and IANA.  Suggeste=
d name: oauth-ext-review. ]]
 
   Within at most 14 days of the=
 request, the Designated Expert(s) will
   either approve or deny the re=
gistration request, communicating this
   decision to the review list a=
nd IANA.  Denials should include an
   explanation and, if applicabl=
e, suggestions as to how to make the
   request successful.
 
   Decisions (or lack thereof) m=
ade by the Designated Expert can be
   first appealed to Application=
 Area Directors (contactable using
   app-ads@tools.ietf.org email address or directly by lookin=
g up their
   email addresses on http://www.iesg.org/ website) and, if the
   appellant is not satisfied wi=
th the response, to the full IESG (using
   the iesg@iesg.org mailing list).
 
   IANA should only accept regis=
try updates from the Designated
   Expert(s), and should direct =
all requests for registration to the
   review mailing list.
 
10.3.1.  Registration Template
 
   Error name:=

      The name re=
quested (e.g., "example").
   Error usage location:
      The locatio=
n(s) where the error can be used.  The possible

      locations a=
re: authorization code grant error response


      (Section 4.=
1.2.1), implicit grant error response


      (Section 4.=
2.2.1), or token error response (Section 5.2).


   Related protocol extension:


      The name of=
 the extension grant type, access token type, or


      extension p=
arameter, the error code is used in conjunction with.

   Change controller:=



      For standar=
ds-track RFCs, state "IETF".  For others, give the name=



      of the resp=
onsible party.  Other details (e.g., postal address,=



      e-mail addr=
ess, home page URI) may also be included.


   Specification document(s):


      Reference t=
o document that specifies the error code, preferably

      including a=
 URI that can be used to retrieve a copy of the


      document.&n=
bsp; An indication of the relevant sections may also be

      included, b=
ut is not required.


 


 
--_000_4E1F6AAD24975D4BA5B1680429673943252CFB54TK5EX14MBXC203r_-- From eran@hueniverse.com Wed Apr 6 16:33:59 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B476D3A6973 for ; Wed, 6 Apr 2011 16:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ad90URQpeJg for ; Wed, 6 Apr 2011 16:33:42 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 4501F3A6804 for ; Wed, 6 Apr 2011 16:33:42 -0700 (PDT) Received: (qmail 22778 invoked from network); 6 Apr 2011 23:35:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Apr 2011 23:35:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 6 Apr 2011 16:35:16 -0700 From: Eran Hammer-Lahav To: Mike Jones , OAuth WG Date: Wed, 6 Apr 2011 16:35:09 -0700 Thread-Topic: OAuth2 scheme (was Error registry proposal (round 3)) Thread-Index: Acv0szxJR54h3FRORpezZ9L8nUeh+g== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E11D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664E11DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth2 scheme (was Error registry proposal (round 3)) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 23:33:59 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E11DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well... Can't say I didn't see this coming :) The issue is not simply about putting a section back, but about the overall= protocol architecture and how it complies with HTTP. For example, taking the MAC draft, how do you envision the resource server = responding to a failed authentication attempt? A 401 response and what head= er(s)? WWW-Authenticate with 'OAuth2' scheme? 'MAC' scheme? Both? Also see: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/78 You might think you are asking for a simple feature, but this is moving the= protocol from a purely authorization protocol to an authentication protoco= l which is what the split of the token types was designed to accomplish. What I am asking for is to provide full examples of how you envision the OA= uth2 scheme to work in practice, especially considering the MAC draft. Assu= me that the MAC draft, since it is defined as a general purpose scheme, is = not going to change (for the sake of argument only), do you envision it bei= ng used differently when combines with an OAuth access token? That would be= bad. I removed the WWW-Authenticate header and the OAuth2 scheme because it serv= ed no purpose and no one demonstrated how it will be actually used. WRAP is= not a good example because WRAP is a closed protocol (just like OAuth 1.0)= . There is no way to add new authentication schemes to WRAP and in that con= text, it makes sense to define a scheme. But here it will mean moving backw= ards to a protocol where only OAuth-specific authentication schemes can be = used, and they all must be defined as extensions of this master OAuth2 sche= me. There was pretty good consensus not to define a master scheme with sub sche= mes. That is well documented on the list. This thread included the discussi= on about using a common prefix for scheme names, etc. Hope we don't have to= repeat that. So if OAuth2 is not a master scheme for all other scheme to be defined as s= ub-schemes, what is it? I don't have an answer and we kinda need one to put= such a scheme back in the document. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 4:13 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) Actually, you correctly point out (indirectly), that this is related to one= of the open issues that needs to be resolved to complete the specs when yo= u wrote "For such a registry to be useful, you also need to standardize the= authentication header across all schemes and define a standard parameter u= sed to deliver such error codes". This open issue (which there wasn't time to discuss during last week's meet= ing) was the removal of the WWW-Authenticate Response Header. This feature= was present in WRAP and earlier OAuth drafts but was removed without a cle= ar consensus to do so. And indeed, during our private discussions on how t= he draft should be split, at that time, you took the position that the WWW-= Authenticate response should remain in the framework spec. The result has been that there is different and incompatible WWW-Authentica= te response functionality in multiple related drafts - specifically draft-h= ammer-oauth-v2-mac-token-02 and draft-ietf-oauth-v2-bearer-04. Interoperab= ility and developers would both be better served by moving this functionali= ty back into the core. I don't believe that each related OAuth specificatio= n should have to separately specify this functionality. As this was not di= scussed during last week's meeting, a consensus call from the chairs may be= necessary to resolve this issue. -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 06, 2011 3:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Putting aside my view that a registry for resource server error responses a= cross HTTP authentication schemes isn't very useful or interesting, I don't= have an objection to the bearer token specification defining such general = purpose registry. In a way, it is similar to the error response headers def= ined by Digest, only never made generally applicable. The difference in our approaches is that I don't consider the bearer token = or mac token specs to be extensions of the v2 spec, but fully specified HTT= P authentication schemes with OAuth 2.0 binding (i.e. the access token type= registration). Because of that, I don't think the v2 spec is the right pla= ce for such a registry, which is really about HTTP authentication schemes a= nd not OAuth. Therefore, I think it will be more confusing to put such a re= gistry in v2. I'll give you an example. Suppose someone will define a Digest access token= type. When issuing one, the server will send an access token (to be used a= s username) and a secret (to be used as password). To use such a token, the= client will use the HTTP Digest scheme (as is). Digest defines its own set= and method or specifying error code. Would you expect those to be register= ed in your proposed registry? I would assume not. For such a registry to be useful, you also need to standardize the authenti= cation header across all schemes and define a standard parameter used to de= liver such error codes. However, we already moved away from that design by = defining separate HTTP authentication schemes for each token type. But again, I don't have an objection to such a registry defined in the bear= er token spec. I have no intentions of using it for any HTTP authentication= scheme I plan to author. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 3:39 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) The problem with that situation is that it doesn't provide a central regist= ry for resource server error responses across specs, unlike the other kinds= of OAuth error responses. I could define that registry in the bearer toke= n spec, but it would be less confusing to unify it with the proposed regist= ry in the framework spec. I suspect developers would thank us for doing th= at. What do you say? -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 06, 2011 2:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Hi Mike, This is intentional. The error registry defined in v2 is not designed to re= cord errors for the protected resource endpoint response or the WWW-Authent= icate response header when used with the Bearer token scheme (or any other = scheme). The only purpose of the registry is to avoid name collisions between two er= rors used differently with the v2 specification. Since errors used with the= Bearer token scheme will never appear in the same place as the v2 endpoint= s, there is no need for combining these two registries. If the bearer token specification requires error extensibility, you should = retain the registry there and limit it to just the protected resource respo= nse space. Ideally, you would limit it to just the WWW-Authenticate header = 'error' parameter when used with the Bearer scheme. The MAC scheme does not= use error codes, but instead, relies fully on HTTP status code since no ad= ditional error conditions were identified. Also, since your ABNF permits adding additional Authorization header parame= ters, you might want to consider defining a process for doing that, if you = are going to define an error registry. Currently, to add additional paramet= ers, one has to update the Bearer token RFC, in contrast to simply register= ing a new error code (which is likely to come out of a new parameter). EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 2:25 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) Thanks for writing this up, Eran. I believe that this is a step in the rig= ht direction. Wearing my Bearer Token spec editor hat, I just tried to go through the exe= rcise of editing my document to use the registry in draft 15 to register th= e errors defined in the bearer token spec and I hit a roadblock. Specifica= lly, while the errors defined by my spec are returned by resource servers (= flow F in Figure 1), the registry defined by draft 15 does not include "res= ource server error response" in the "error usage location" list. Can you p= lease add this additional error usage location so that the registry can be = used by the bearer token specification? At that point, I believe we'll be able to close the open issue about the ne= ed for an error registry, and I'll update my draft accordingly. Thank you, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, April 05, 2011 3:52 PM To: OAuth WG Subject: [OAUTH-WG] Error registry proposal (round 3) The following is my new proposal, based on Mike Jones' and my earlier propo= sals. It is basically a combination of the two. This proposal does not allow defining new error codes unless another extens= ion is involved (new grant type, request parameter, token type). The reason= for not defining an open ended error registry is that defining new error c= odes for existing implementations is bad for interoperability and can lead = to unexpected results (developers not taking into account receiving a new e= rror when talking to a compliant 2.0 server). We don't have any use cases f= or defining such new errors for the v2 specification. New errors only come = from extensions and must be defined in that context. I have applied to changes to the -14 draft and clearly marked them with [[P= ending Consensus]] so that there is no issue with removing them or changing= them later. --- Add to the error codes list in sections 4.1.2.1 and 4.2.2.1: a 4xx or 5xx HTTP status code (except for 400 and 401) The authorization server MAY set the "error" parameter value to a numerical HTTP status code from the 4xx or 5xx range, with the exception of the 400 (Bad Request) and 401 (Unauthorized) status codes. For example, if the service is temporarily unavailable, the authorization server MAY return an error response with "error" set to "503". Add a new section 8.4: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the token error response (Section 5.2), such error codes MAY be defined. Extension error codes MUST be registered (following the procedures in Section 10.3) if the extension they are used in conjunction with is registered. Additional error codes used with unregistered extensions MAY be registered. Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" should be named "example_invalid". error-code =3D ALPHA *error-char error-char =3D "-" / "." / "_" / DIGIT / ALPHA Add a new section 10.3: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app-ads@tools.ietf.org email address or d= irectly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. 10.3.1. Registration Template Error name: The name requested (e.g., "example"). Error usage location: The location(s) where the error can be used. The possible locations are: authorization code grant error response (Section 4.1.2.1), implicit grant error response (Section 4.2.2.1), or token error response (Section 5.2). Related protocol extension: The name of the extension grant type, access token type, or extension parameter, the error code is used in conjunction with. Change controller: For standards-track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included. Specification document(s): Reference to document that specifies the error code, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required. --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E11DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well… Can’t say I didn’t see this coming J

 

The issue is not simply about putting a section back= , but about the overall protocol architecture and how it complies with HTTP= .

<= o:p> 

For example, taking the MAC draft, how do you envision the resource serv= er responding to a failed authentication attempt? A 401 response and what h= eader(s)? WWW-Authenticate with ‘OAuth2’ scheme? ‘MACR= 17; scheme? Both?

 

Also see: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/78=

 

You might think you are asking for a simple feature, but this is moving t= he protocol from a purely authorization protocol to an authentication proto= col which is what the split of the token types was designed to accomplish.<= o:p>

 

What I am asking for is to provide full examples of how you envision the O= Auth2 scheme to work in practice, especially considering the MAC draft. Ass= ume that the MAC draft, since it is defined as a general purpose scheme, is= not going to change (for the sake of argument only), do you envision it be= ing used differently when combines with an OAuth access token? That would b= e bad.

 

I removed the WWW-Authenticate header and the OAuth2 scheme because= it served no purpose and no one demonstrated how it will be actually used.= WRAP is not a good example because WRAP is a closed protocol (just like OA= uth 1.0). There is no way to add new authentication schemes to WRAP and in = that context, it makes sense to define a scheme. But here it will mean movi= ng backwards to a protocol where only OAuth-specific authentication schemes= can be used, and they all must be defined as extensions of this master OAu= th2 scheme.

 

There was pretty good consensus not to define a master scheme = with sub schemes. That is well documented on the list. This thread included= the discussion about using a common prefix for scheme names, etc. Hope we = don’t have to repeat that.

=  

So if OAuth2 is not a master scheme for a= ll other scheme to be defined as sub-schemes, what is it? I don’t hav= e an answer and we kinda need one to put such a scheme back in the document= .

<= o:p> 

EHL

 

<= b>From:<= /span> Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Wednesd= ay, April 06, 2011 4:13 PM
To: Eran Hammer-Lahav; OAuth WG
= Subject: RE: Error registry proposal (round 3)

 

Actually, you correctly point out (indirectly), = that this is related to one of the open issues that needs to be resolved to= complete the specs when you wrote “For such a registry to be useful, you also need to standardize the auth= entication header across all schemes and define a standard parameter used t= o deliver such error codes”.

&= nbsp;

Th= is open issue (which there wasn’t time to discuss during last week= 217;s meeting) was the removal of the WWW-Authenticate Response Header. &nb= sp;This feature was present in WRAP and earlier OAuth drafts but was remove= d without a clear consensus to do so.  And indeed, during our private = discussions on how the draft should be split, at that time, you took the po= sition that the WWW-Authenticate response should remain in the framework sp= ec.

 

The result has been that there is different and incompatible WWW-Authe= nticate response functionality in multiple related drafts – specifica= lly draft-hammer-oauth-v2-mac-token-02 and draft-ietf-oauth-v2-bearer-04.&n= bsp; Interoperability and developers would both be better served by moving = this functionality back into the core. I don’t believe that each rela= ted OAuth specification should have to separately specify this functionalit= y.  As this was not discussed during last week’s meeting, a cons= ensus call from the chairs may be necessary to resolve this issue.

 =

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

 

From: Eran H= ammer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, April = 06, 2011 3:58 PM
To: Mike Jones; OAuth WG
Subject: RE: = Error registry proposal (round 3)

 

Putting aside my view that a registry for resource server error r= esponses across HTTP authentication schemes isn’t very useful or inte= resting, I don’t have an objection to the bearer token specification = defining such general purpose registry. In a way, it is similar to the erro= r response headers defined by Digest, only never made generally applicable.=

 

The difference in our approaches is that I don’t consider the beare= r token or mac token specs to be extensions of the v2 spec, but fully speci= fied HTTP authentication schemes with OAuth 2.0 binding (i.e. the access to= ken type registration). Because of that, I don’t think the v2 spec is= the right place for such a registry, which is really about HTTP authentica= tion schemes and not OAuth. Therefore, I think it will be more confusing to= put such a registry in v2.

 

<= span style=3D'color:#1F497D'>I’ll give you an example. Suppose someon= e will define a Digest access token type. When issuing one, the server will= send an access token (to be used as username) and a secret (to be used as = password). To use such a token, the client will use the HTTP Digest scheme = (as is). Digest defines its own set and method or specifying error code. Wo= uld you expect those to be registered in your proposed registry? I would as= sume not.

 

For such a registry to be useful, you also need to standardize t= he authentication header across all schemes and define a standard parameter= used to deliver such error codes. However, we already moved away from that= design by defining separate HTTP authentication schemes for each token typ= e.

=  

But again, I don’t have an objection to such a registry defined i= n the bearer token spec. I have no intentions of using it for any HTTP auth= entication scheme I plan to author.

 

EHL

 

 

 

=

 =

 

From: Mike Jones [mailto:Mi= chael.Jones@microsoft.com]
Sent: Wednesday, April 06, 2011 3:39 = PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error r= egistry proposal (round 3)

 

The problem with that situation is that it doesn’t provide a centr= al registry for resource server error responses across specs, unlike the ot= her kinds of OAuth error responses.  I could define that registry in t= he bearer token spec, but it would be less confusing to unify it with the p= roposed registry in the framework spec.  I suspect developers would th= ank us for doing that.

 

What do you say?

 

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

 

From: Eran Hammer-Lahav [mailto:eran@= hueniverse.com]
Sent: Wednesday, April 06, 2011 2:58 PM
To= : Mike Jones; OAuth WG
Subject: RE: Error registry proposal (= round 3)

 <= /o:p>

Hi Mike,

&nbs= p;

This = is intentional. The error registry defined in v2 is not designed to record = errors for the protected resource endpoint response or the WWW-Authenticate= response header when used with the Bearer token scheme (or any other schem= e).

 

The only purpose of the registry is to avoid name collisions between t= wo errors used differently with the v2 specification. Since errors used wit= h the Bearer token scheme will never appear in the same place as the v2 end= points, there is no need for combining these two registries.

 =

If the bearer= token specification requires error extensibility, you should retain the re= gistry there and limit it to just the protected resource response space. Id= eally, you would limit it to just the WWW-Authenticate header ‘error&= #8217; parameter when used with the Bearer scheme. The MAC scheme does not = use error codes, but instead, relies fully on HTTP status code since no add= itional error conditions were identified.

 

Also, since your ABNF permits ad= ding additional Authorization header parameters, you might want to consider= defining a process for doing that, if you are going to define an error reg= istry. Currently, to add additional parameters, one has to update the Beare= r token RFC, in contrast to simply registering a new error code (which is l= ikely to come out of a new parameter).

 

EHL

 

 

=

From: Mike Jones [mailto:Michael.Jo= nes@microsoft.com]
Sent: Wednesday, April 06, 2011 2:25 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error registry = proposal (round 3)

 

Thank= s for writing this up, Eran.  I believe that this is a step in the rig= ht direction.

 

Wearing my Bearer Token spec editor hat, I just tried to go = through the exercise of editing my document to use the registry in draft 15= to register the errors defined in the bearer token spec and I hit a roadbl= ock.  Specifically, while the errors defined by my spec are returned b= y resource servers (flow F in Figure 1), the registry defined by draft 15 d= oes not include “resource server error response” in the “= error usage location” list.  Can you please add this additional = error usage location so that the registry can be used by the bearer token s= pecification?

 

At that point, I believe we’ll be able to close the op= en issue about the need for an error registry, and I’ll update my dra= ft accordingly.

 

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;    Thank you,

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

 

From: oauth-bounces@ietf.org [mailto:oauth-bounce= s@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, = April 05, 2011 3:52 PM
To: OAuth WG
Subject: [OAUTH-WG]= Error registry proposal (round 3)

 

The following is= my new proposal, based on Mike Jones’ and my earlier proposals. It i= s basically a combination of the two.

 

This proposal does not allow = defining new error codes unless another extension is involved (new grant ty= pe, request parameter, token type). The reason for not defining an open end= ed error registry is that defining new error codes for existing implementat= ions is bad for interoperability and can lead to unexpected results (develo= pers not taking into account receiving a new error when talking to a compli= ant 2.0 server). We don't have any use cases for defining such new errors f= or the v2 specification. New errors only come from extensions and must be d= efined in that context.

 

I have applied to changes to the -14 draft = and clearly marked them with [[Pending Consensus]] so that there is no issu= e with removing them or changing them later.

 

---

 

Add to the= error codes list in sections 4.1.2.1 and 4.2.2.1:

 

   &nb= sp;     a 4xx or 5xx HTTP status code (except for 400 a= nd 401)

     = ;          The authorization s= erver MAY set the "error" parameter

           =     value to a numerical HTTP status code from the 4xx or 5x= x

      = ;         range, with the exception= of the 400 (Bad Request) and

 &= nbsp;           &nbs= p; 401 (Unauthorized) status codes.  For example, if the

        &n= bsp;      service is temporarily unavailable, the = authorization

    = ;           server MAY re= turn an error response with "error" set to

<= p class=3DMsoNormal>          = ;     "503".

 

 =

Add a new section 8.4:

 

8.4.&=
nbsp; Defining Additional Error Codes
 
   In cases where protocol extensions (i.e. access token t=
ypes,
   =
extension parameters, or extension grant types) require additional
   error codes to=
 be used with the authorization code grant error
   response (Section 4.1.2.1), the = implicit grant error response
   (Section 4.2.2.1), or the token error response (Sec=
tion 5.2), such
&nb=
sp;  error codes MAY be defined.
 
   Extension error codes MUST be registered (following the=
 procedures in
&nbs=
p;  Section 10.3) if the extension they are used in conjunction with i=
s
   regi=
stered.  Additional error codes used with unregistered extensions=

   MAY be reg=
istered.
 =
;
   Error cod=
es MUST conform to the error-code ABNF, and SHOULD be
   prefixed by an identifying =
name when possible.  For example, an error
   identifying an invalid value set =
to the extension parameter "example"
=
   should be named "example_inva=
lid".
&nb=
sp;
 
     error-c=
ode   =3D ALPHA *error-char
     error-char   =3D &quo=
t;-" / "." / "_" / DIGIT / ALPHA=

 

=  

Add a new section 10.3:

 

10.3.  The OAuth Extensions Error Registry
 
=
   This specification establishes the=
 OAuth extensions error registry.
 
   Additional error codes used together with other protocol =
extensions
 &n=
bsp; (i.e. extension grant types, access token types, or extension
   parameters) ar=
e registered on the advice of one or more Designated
   Experts (appointed by the IE=
SG or their delegate), with a
   Specification Required (using terminology from [RFC=
5226]).  However,
   to allow for the allocation of values prior to publication=
, the
   =
Designated Expert(s) may approve registration once they are satisfied<=
/o:p>
   that such a=
 specification will be published.
 
   Registration requests should be sent to the [TBD]@ietf.or=
g mailing
 &nb=
sp; list for review and comment, with an appropriate subject (e.g.,
   "Request=
 for error code: example"). [[ Note to RFC-EDITOR: The name=

   of the mailing l=
ist should be determined in consultation with the
   IESG and IANA.  Suggested =
name: oauth-ext-review. ]]
 
&nbs=
p;  Within at most 14 days of the request, the Designated Expert(s) wi=
ll
   eit=
her approve or deny the registration request, communicating this=

   decision to the =
review list and IANA.  Denials should include an
   explanation and, if applica=
ble, suggestions as to how to make the
   request successful.
 
   Decisions (or lack thereof) made by the =
Designated Expert can be
   first appealed to Application Area Directors (contactabl=
e using
  =
; app-ads@tools.ietf.org emai=
l address or directly by looking up their
   email addresses on http://www.iesg.org/ website) and, if the
   appellant is not satis=
fied with the response, to the full IESG (using
   the iesg@iesg.org mailing list).
 
   IANA should only accept registry updates from the Design=
ated
   E=
xpert(s), and should direct all requests for registration to the=

   review mailing l=
ist.
 
10.3.1.  Registration=
 Template
&nbs=
p;
   Error na=
me:
  &nb=
sp;   The name requested (e.g., "example").<=
/span>
   Error usage locat=
ion:
  &n=
bsp;   The location(s) where the error can be used.  The pos=
sible
  &=
nbsp;   locations are: authorization code grant error response
    &n=
bsp; (Section 4.1.2.1), implicit grant error response
      (Sec=
tion 4.2.2.1), or token error response (Section 5.2).
   Related protocol extension:=

   =
   The name of the extension grant type, access token type, or
   &nb=
sp;  extension parameter, the error code is used in conjunction with.<=
o:p>
   Change=
 controller:
 =
     For standards-track RFCs, state "IETF".&=
nbsp; For others, give the name
      of the responsible party. =
 Other details (e.g., postal address,
      e-mail address, home page=
 URI) may also be included.
   Specification document(s):
      Reference to d=
ocument that specifies the error code, preferably
      including a U=
RI that can be used to retrieve a copy of the
<=
span style=3D'color:black'>      document.  A=
n indication of the relevant sections may also be
      included, but= is not required.

 = ;

 

<= /div>= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E11DP3PW5EX1MB01E_-- From James.H.Manger@team.telstra.com Wed Apr 6 20:13:51 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31EDF3A6784 for ; Wed, 6 Apr 2011 20:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-6ZjP0Q6qE8 for ; Wed, 6 Apr 2011 20:13:45 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 32D9A3A681C for ; Wed, 6 Apr 2011 20:13:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,314,1299416400"; d="scan'208,217";a="31700741" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 07 Apr 2011 13:15:26 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6308"; a="23222190" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcavi.tcif.telstra.com.au with ESMTP; 07 Apr 2011 13:15:27 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 7 Apr 2011 13:15:26 +1000 From: "Manger, James H" To: Paul Madsen , "oauth@ietf.org" Date: Thu, 7 Apr 2011 13:15:23 +1000 Thread-Topic: [OAUTH-WG] draft-15 editorials Thread-Index: Acv0bXKSFkj7XrrhT52Zzjt7Es6WhQAS+GLA Message-ID: <255B9BB34FB7D647A506DC292726F6E11281C39962@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11281BA9188@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943252CE4F8@TK5EX14MBXC203.redmond.corp.microsoft.com> <4D9C47A8.30605@gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234465664DF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D9C836C.9080704@gmail.com> In-Reply-To: <4D9C836C.9080704@gmail.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_255B9BB34FB7D647A506DC292726F6E11281C39962WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-15 editorials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 03:13:51 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11281C39962WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, The draft-15.1 abstract is just the first sentence of the abstract I sugges= ted last month [http://www.ietf.org/mail-archive/web/oauth/current/msg05693= .html and below]. The rest covered OAuth's other major aspect: issuing temp= orary credentials that resource servers can handle, while a separate servic= e can handle permanent or exotic credentials (eg assertions). Does it fit w= hat you were after? Your "directly negotiate access" phrase hints that there is more to OAuth 2= than delegation, but I'm not sure that it explains it. -- James Manger From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= aul Madsen Sent: Thursday, 7 April 2011 1:15 AM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-15 editorials Proposed text The OAuth 2.0 authorization protocol enables a third-party application to o= btain limited access to an HTTP service, either on behalf of an end-user by= orchestrating an approval interaction between the end-user and the HTTP se= rvice, or by allowing the third-party application to directly 'negotiate', = on its own behalf, such access with the HTTP service. And I acknowledge the concerns that 'negotiate' might create, thus the air = quotes .... paul From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Thursday, 17 March 2011 1:40 PM To: OAuth WG Subject: [OAUTH-WG] OAuth2 abstract Comments on draft-ietf-oauth-v2-13: 1. Abstract The 1-line abstract is not helpful - it merely repeats the title. The abstr= act is important as it is the text most widely seem around the rest of the = IETF community (eg in announcements of drafts and RFCs) and beyond. It need= s to mention: users delegating access to applications; applications orchest= rating that delegation; swapping permanent credentials for short-lived acce= ss tokens; and that it uses HTTP. Here is my suggestion: "The OAuth 2.0 authorization protocol allows an application to gain limited permission to access an HTTP service on behalf of a user by orchestrating an approval interaction between the user and the service. OAuth 2.0 uses temporary credentials, issued by an HTTP service either directly to an application or to represent user-delegated permissions. A collection of HTTP services can accept temporary credentials without needing to handle long-term user or application credentials, which can be restricted to a secure service that issues the temporary credentials." I think this text can be understood without knowing any of the specialised = terms introduced later in the specification. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E11281C39962WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Paul,

 

The draft-15.1 abstrac= t is just the first sentence of the abstract I suggested last month [http:/= /www.ietf.org/mail-archive/web/oauth/current/msg05693.html and below]. The = rest covered OAuth’s other major aspect: issuing temporary credentials that resource servers can handle, while a se= parate service can handle permanent or exotic credentials (eg assertions). = Does it fit what you were after?

 

Your “directly n= egotiate access” phrase hints that there is more to OAuth 2 than dele= gation, but I’m not sure that it explains it.

 

--

James Manger

 

From: oauth-bounces@ietf.org [mailt= o:oauth-bounces@ietf.org] On Behalf Of Paul Madsen
Sent: Thursday, 7 April 2011 1:15 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-15 editorials

 

Proposed text

The OAuth 2.0 authorization protocol enables a third-party application to o= btain limited access to an HTTP service, either on behalf of an end-user by= orchestrating an approval interaction between the end-user and the HTTP se= rvice, or by allowing the third-party application to directly 'negotiate', on its own behalf, such access with t= he HTTP service.

And I acknowledge the concerns that 'negotiate' might create, thus the air = quotes ....

paul

 

 

From: oauth-bounces@ietf.= org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Thursday, 17 March 2011 1:40 PM
To: OAuth WG
Subject: [OAUTH-WG] OAuth2 abstract

 

Comments on draft-ietf-oauth-v2-13:

 

1. Abstract

The 1-line abstract is not helpful – it merely= repeats the title. The abstract is important as it is the text most widely= seem around the rest of the IETF community (eg in announcements of drafts = and RFCs) and beyond. It needs to mention: users delegating access to applications; applications orchestrating that d= elegation; swapping permanent credentials for short-lived access tokens; an= d that it uses HTTP. Here is my suggestion:

 

  “The OAuth 2.0 authorization protocol a= llows an application to gain
  limited permission to access an HTTP service on behalf of a use= r by
  orchestrating an approval interaction between the user and the = service.
  OAuth 2.0 uses temporary credentials, issued by an HTTP service= either
  directly to an application or to represent user-delegated permi= ssions.
  A collection of HTTP services can accept temporary credentials = without
  needing to handle long-term user or application credentials, wh= ich
  can be restricted to a secure service that issues the temporary=
  credentials.”

 

I think this text can be understood without knowing = any of the specialised terms introduced later in the specification.

 

 

--

James Manger

 

--_000_255B9BB34FB7D647A506DC292726F6E11281C39962WSMSG3153Vsrv_-- From eran@hueniverse.com Wed Apr 6 23:21:53 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1353A6953 for ; Wed, 6 Apr 2011 23:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3-r3v+i+kw9 for ; Wed, 6 Apr 2011 23:21:49 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 380F83A67F3 for ; Wed, 6 Apr 2011 23:21:48 -0700 (PDT) Received: (qmail 18337 invoked from network); 7 Apr 2011 06:23:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Apr 2011 06:23:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 6 Apr 2011 23:23:32 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 6 Apr 2011 23:23:25 -0700 Thread-Topic: Note to early adopters of draft-hammer-oauth-v2-mac-token Thread-Index: Acv065bFaBlWgyzBQgSYV8FOfyQT7A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E161@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664E161P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Note to early adopters of draft-hammer-oauth-v2-mac-token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 06:21:53 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E161P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in the midst of editing a new version which includes a few breaking ch= anges such at header attribute name changes ('token' to 'id', 'signature' t= o 'mac') as well as a new attribute ('issuer' to indicate the host:port whe= re the credentials were issues - in OAuth, the host and post of the authori= zation server). The normalized request string is also changing (adding the = issuer value). These are all changed in an early revision, so all of this can still change= . I just wanted to give people the heads up that this is coming in a couple o= f weeks and that if you have deployed the draft or plan to, that you will n= eed to make these changes on both client and server. Apologies for any issues this might cause, but this draft is not yet stable= . EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E161P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am in the mids= t of editing a new version which includes a few breaking changes such at he= ader attribute name changes (‘token’ to ‘id’, ̵= 6;signature’ to ‘mac’) as well as a new attribute (‘= ;issuer’ to indicate the host:port where the credentials were issues = – in OAuth, the host and post of the authorization server). The norma= lized request string is also changing (adding the issuer value).=

 

These ar= e all changed in an early revision, so all of this can still change.

 

I ju= st wanted to give people the heads up that this is coming in a couple of we= eks and that if you have deployed the draft or plan to, that you will need = to make these changes on both client and server.

 

Apologies for any issues= this might cause, but this draft is not yet stable.

 

EHL

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E161P3PW5EX1MB01E_-- From eran@hueniverse.com Wed Apr 6 23:36:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68BE3A688B for ; Wed, 6 Apr 2011 23:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfQz2sNHJjug for ; Wed, 6 Apr 2011 23:36:55 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id BA4043A6876 for ; Wed, 6 Apr 2011 23:36:55 -0700 (PDT) Received: (qmail 31065 invoked from network); 7 Apr 2011 06:38:40 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Apr 2011 06:38:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 6 Apr 2011 23:38:21 -0700 From: Eran Hammer-Lahav To: Skylar Woodward Date: Wed, 6 Apr 2011 23:38:13 -0700 Thread-Topic: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 Thread-Index: Acu+GI0IEY1tVQdxTkilWUPUtovSXQ21RSzw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E162@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <809B826D-EFC6-439E-9926-D5AF085DBA60@kiva.org> In-Reply-To: <809B826D-EFC6-439E-9926-D5AF085DBA60@kiva.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 06:36:56 -0000 > -----Original Message----- > From: Skylar Woodward [mailto:skylar@kiva.org] > Sent: Thursday, January 27, 2011 3:52 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 >=20 > This is excellent. Thanks for pulling together a signature-based token sp= ec. > Some feedback: >=20 > - As I think was mentioned in a previous post, this spec is also attracti= ve as > method for asserting client credentials (eg, for access token requests). = Your > point is noted on substituting "client_id" as "token" though some languag= e to > recommend the general application of this field could be helpful for thos= e > reading the spec to draw the same conclusion. My personal preference > might be the use of the word "assertion" over "token" if this is meant to= be a > general-purpose mechanism. Otherwise, people will naturally draw a strong > correlation between related OAuth specs. I suppose this is the same sort = of > tension involved in keeping a more general name of MAC or assuming a > more integral term, OAUTH_MAC. In any case, it feels like a "hack" to ask > developers to put "client_id" into the "token" field, so I prefer multi-p= urpose > names where multiple uses are intended. The 'token' attribute was changed to 'id' and is now defined as the MAC key= identifier. > - When presenting an MAC token, it would be attractive if client credenti= als > could also be captured in the assertion without relying on a separate > assertion (imagine the confusion in two Authorization headers, MAC > [token=3Dclient_id] and MAC [token=3Dtoken]). A simple solution (and one= that > preserves the same double-secret signature as OAuth 1.0) would be to > require the value of "secret" (used as the signing key) to be a concatena= tion > of client_secret and token_secret. I assume this kind of special instruct= ion > could be made by providers just as simply as the explanation of the use o= f > "token" for client_id in client auth. I mention it to see if anyone sees = conflicts > or objections to this use, or if it is worth including the option in the = spec in > some manner. If the spec is trying to remain more independent from the > core OAuth spec, then I suppose that's a reason to both allow such altern= ate > use and not address it. If the spec means to address common use cases and > draw tight correlation between the two specs, then I see this as an posit= ive > clarification. Validating client identity on the presentation of tokens i= s a > valuable ability. Using client credentials in the assertion allows for th= e > signature to include an element that is potentially never sent over the w= ire > or in a previous OAuth exchange. The concept of including both the token credentials and client credentials = in one request was explicitly thrown out of OAuth 2.0. It is one of the bad= design choices in 1.0 and makes deployment at scale much harder. Do you ha= ve use cases for authenticating a single request with more than one set of = credentials? =20 > - Using a body hash and making it optional is a great alternative to the = OAuth > 1.0a method incorporating content body params. Given the confusion that > parameter ordering and sorting caused for 1.0a why not apply the same > method for query-string parameters? That is, normalize the query-string > parameters, sort them, create a parameter hash, and include it in the > assertion (optional). This allows providers to not require this if they = consider > it to be unnecessary for security as well as a hurdle to message signing.= In any > case, I'd see both elements as either optional or required. The only reason we normalize the request URI is that on many client and ser= ver platforms, the layer at which this is implemented does not have access = to the raw request (both on the client and server). Calculating a MAC on th= e entire request URI is critical. Providers wishing to avoid it should not = use query parameters. =20 > - As expressed, I had concerns over versioning of the format as any > modification could introduce brittleness to the construction of the Signa= ture > Base String. Your preference seems to be to introduce MAC2 if > incompatibility or confusion arises. Assuming everyone else is fine with = that, > it's an acceptable path forward. Yep. I have no intention turning this too into a framework... =20 EHL From eran@hueniverse.com Wed Apr 6 23:53:06 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70FA3A6814 for ; Wed, 6 Apr 2011 23:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3j0hipSydOi for ; Wed, 6 Apr 2011 23:53:06 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 30F6B3A67F3 for ; Wed, 6 Apr 2011 23:53:06 -0700 (PDT) Received: (qmail 12160 invoked from network); 7 Apr 2011 06:54:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Apr 2011 06:54:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 6 Apr 2011 23:54:42 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Wed, 6 Apr 2011 23:54:34 -0700 Thread-Topic: more comments on draft-hammer-oauth-v2-mac-token-02 -- algorithm param Thread-Index: AcuxSHVnmSRFc5caQL+nfm1VQbrgkQACjnbAA7aFd/ABAMSawAB0CinwC7wPgeA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E163@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E1127B45349E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1127D4581D7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB350E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D51DE36@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127D51DE36@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] more comments on draft-hammer-oauth-v2-mac-token-02 -- algorithm param X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 06:53:06 -0000 I do not want to allow the client any flexibility in choosing the algorithm= once a MAC key has been issued. Every other standard provide a negotiation= step in which the client can figure out which algorithms are available, an= d therefore needs to indicate which one was used. I don't want to support t= hat because it leads to complexity. I am trying my best to keep this as foc= used and limited as possible. EHL > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Sunday, February 06, 2011 5:43 AM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: RE: more comments on draft-hammer-oauth-v2-mac-token-02 -- > algorithm param >=20 > Eran, >=20 > >> 13. The MAC algorithm should be explicitly indicated in the request, > >> instead of being implied by the access-token/id. I suggest including a= n > "algorithm" > >> parameter in the "Authorization" request header. I also suggest > >> including an "algorithms" parameter in the "WWW-Authenticate" > >> response header that is a (comma-separated?) list of MAC algorithms th= at > the server supports. >=20 > > Why? The client does not get a choice which algorithm to use. There is = no > negotiation here. >=20 > Pretty much every standardised crypto message indicates the algorithm use= d > to protect it in the message itself. Why be different? >=20 > Consider hashing the body. You don't need the secret key to do this, but = you > do need to know the hash algorithm. With an algorithm parameter, a front- > end web server can use that to confirm the body-hash parameter is correct > before passing the message to a middle tier where the secret key is avail= able > to verify the MAC. >=20 > An algorithm parameter offers some ability to migrate to stronger MAC > algorithms if, say, (more) weaknesses in SHA-1 are found. Without it you > need to issue new credentials to migrate. >=20 > If you have a environment of heterogeneous servers (legacy, new, vendor A= , > vendor B...) they might support different algorithms, but it would handy = if > clients could use a single credential. >=20 > Secret keys are generally handled separately in software than support for > crypto algorithms. For instance, you can store a secret key in a Java Key > Store, but I don't think there is an associated spot to specify a MAC > algorithm. >=20 > -- > James Manger From torsten@lodderstedt.net Thu Apr 7 00:25:40 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637603A6814 for ; Thu, 7 Apr 2011 00:25:40 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ0M2QbpVppI for ; Thu, 7 Apr 2011 00:25:39 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by core3.amsl.com (Postfix) with ESMTP id 7F2113A67F3 for ; Thu, 7 Apr 2011 00:25:39 -0700 (PDT) Received: from [88.128.95.163] (helo=[10.135.144.173]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Q7jcg-0001Ve-Fn for oauth@ietf.org; Thu, 07 Apr 2011 09:27:22 +0200 Message-ID: <4D9D6759.3070904@lodderstedt.net> Date: Thu, 07 Apr 2011 09:27:21 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Security Considerations Section Proposal -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 07:25:40 -0000 Hi all, I just posted a new revision of the proposed text for the core draft's security considerations section (http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02). The text makes some strong statements wrt client secrets/authentication, HTTPS, refresh tokens and other topics. This is to facilitate a clear and understandable specification while also considering (and supporting) _all_ relevant use cases (e.g. native apps). Since this is the last major building block of the draft, we would like to include this text as soon as possible. So please give your feedback soon! thanks in advance, Torsten. From paul.madsen@gmail.com Thu Apr 7 06:12:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47FB928C0E3 for ; Thu, 7 Apr 2011 06:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPqM1ngZvNpx for ; Thu, 7 Apr 2011 06:12:51 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 186493A67A1 for ; Thu, 7 Apr 2011 06:12:51 -0700 (PDT) Received: by gyf3 with SMTP id 3so1180848gyf.31 for ; Thu, 07 Apr 2011 06:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=imxmgeU/+st02dHX33wy7auBqtsNP7mGEaTkVwd6AOE=; b=uxddvPMeTztZruaHW/5xIkHzYZ1IBvszpzSy/kqcc3RSaaMX556mHBONGu07OuMS/b U7VZ/9ncqY9XVevWOzQlETPigs3SgL9ugku7eCKUJ369b/JjZ7FiRPZV5kl5u098fLvL ArSO0ZTXtSjH+py0qN6U80nbbYFZbz84kLKhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=YglmD4V5I8XONbrHRMxAIuycnFcXO53xd8LE7+jf7oszLAoArDj4ivaiTPs739Uhbx mS/Zi5AB9tGQc7D6wUqSk7FvZqUMVcgvmyknbw9+aKq6o9dwJWnQ4Iidt3cQl+/TA85d nqRNWlLbONZ1mrNTz+oOZwr/fQP+zUjwbXnGM= Received: by 10.91.210.12 with SMTP id m12mr771440agq.67.1302182075228; Thu, 07 Apr 2011 06:14:35 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id d20sm349056ang.43.2011.04.07.06.14.31 (version=SSLv3 cipher=OTHER); Thu, 07 Apr 2011 06:14:32 -0700 (PDT) Message-ID: <4D9DB8B6.6020804@gmail.com> Date: Thu, 07 Apr 2011 09:14:30 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E11281BA9188@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943252CE4F8@TK5EX14MBXC203.redmond.corp.microsoft.com> <4D9C47A8.30605@gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234465664DF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D9C836C.9080704@gmail.com> <255B9BB34FB7D647A506DC292726F6E11281C39962@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11281C39962@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="------------060804020007020002060206" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-15 editorials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 13:12:56 -0000 This is a multi-part message in MIME format. --------------060804020007020002060206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi James, sorry I didnt see your earlier suggestion. And your text works for me - just looking for text that hints at something beyond delegation thanks paul On 4/6/11 11:15 PM, Manger, James H wrote: > > Paul, > > The draft-15.1 abstract is just the first sentence of the abstract I > suggested last month > [http://www.ietf.org/mail-archive/web/oauth/current/msg05693.html and > below]. The rest covered OAuth's other major aspect: issuing temporary > credentials that resource servers can handle, while a separate service > can handle permanent or exotic credentials (eg assertions). Does it > fit what you were after? > > Your "directly negotiate access" phrase hints that there is more to > OAuth 2 than delegation, but I'm not sure that it explains it. > > -- > > James Manger > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Paul Madsen > *Sent:* Thursday, 7 April 2011 1:15 AM > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] draft-15 editorials > > Proposed text > > The OAuth 2.0 authorization protocol enables a third-party application > to obtain limited access to an HTTP service, either on behalf of an > end-user by orchestrating an approval interaction between the end-user > and the HTTP service, or by allowing the third-party application to > directly 'negotiate', on its own behalf, such access with the HTTP > service. > > And I acknowledge the concerns that 'negotiate' might create, thus the > air quotes .... > > paul > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Manger, James H > *Sent:* Thursday, 17 March 2011 1:40 PM > *To:* OAuth WG > *Subject:* [OAUTH-WG] OAuth2 abstract > > Comments on draft-ietf-oauth-v2-13: > > 1. *Abstract* > > The 1-line abstract is not helpful -- it merely repeats the title. The > abstract is important as it is the text most widely seem around the > rest of the IETF community (eg in announcements of drafts and RFCs) > and beyond. It needs to mention: users delegating access to > applications; applications orchestrating that delegation; swapping > permanent credentials for short-lived access tokens; and that it uses > HTTP. Here is my suggestion: > > "The OAuth 2.0 authorization protocol allows an application to gain > limited permission to access an HTTP service on behalf of a user by > orchestrating an approval interaction between the user and the service. > OAuth 2.0 uses temporary credentials, issued by an HTTP service either > directly to an application or to represent user-delegated permissions. > A collection of HTTP services can accept temporary credentials without > needing to handle long-term user or application credentials, which > can be restricted to a secure service that issues the temporary > credentials." > > I think this text can be understood without knowing any of the > specialised terms introduced later in the specification. > > -- > > James Manger > --------------060804020007020002060206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi James, sorry I didnt see your earlier suggestion.

And your text works for me - just looking for text that hints at something beyond delegation

thanks

paul

On 4/6/11 11:15 PM, Manger, James H wrote:

Paul,

 

The draft-15.1 abstract is just the first sentence of the abstract I suggested last month [http://www.ietf.org/mail-archive/web/oauth/current/msg05693.html and below]. The rest covered OAuth’s other major aspect: issuing temporary credentials that resource servers can handle, while a separate service can handle permanent or exotic credentials (eg assertions). Does it fit what you were after?

 

Your “directly negotiate access” phrase hints that there is more to OAuth 2 than delegation, but I’m not sure that it explains it.

 

--

James Manger

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Paul Madsen
Sent: Thursday, 7 April 2011 1:15 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-15 editorials

 

Proposed text

The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service, or by allowing the third-party application to directly 'negotiate', on its own behalf, such access with the HTTP service.

And I acknowledge the concerns that 'negotiate' might create, thus the air quotes ....

paul

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Thursday, 17 March 2011 1:40 PM
To: OAuth WG
Subject: [OAUTH-WG] OAuth2 abstract

 

Comments on draft-ietf-oauth-v2-13:

 

1. Abstract

The 1-line abstract is not helpful – it merely repeats the title. The abstract is important as it is the text most widely seem around the rest of the IETF community (eg in announcements of drafts and RFCs) and beyond. It needs to mention: users delegating access to applications; applications orchestrating that delegation; swapping permanent credentials for short-lived access tokens; and that it uses HTTP. Here is my suggestion:

 

  “The OAuth 2.0 authorization protocol allows an application to gain
  limited permission to access an HTTP service on behalf of a user by
  orchestrating an approval interaction between the user and the service.
  OAuth 2.0 uses temporary credentials, issued by an HTTP service either
  directly to an application or to represent user-delegated permissions.
  A collection of HTTP services can accept temporary credentials without
  needing to handle long-term user or application credentials, which
  can be restricted to a secure service that issues the temporary
  credentials.”

 

I think this text can be understood without knowing any of the specialised terms introduced later in the specification.

 

 

--

James Manger

 

--------------060804020007020002060206-- From eran@hueniverse.com Thu Apr 7 07:08:31 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E903828C128 for ; Thu, 7 Apr 2011 07:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Npw2yer+StE for ; Thu, 7 Apr 2011 07:08:31 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 249F828C0FB for ; Thu, 7 Apr 2011 07:08:29 -0700 (PDT) Received: (qmail 14287 invoked from network); 7 Apr 2011 14:10:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Apr 2011 14:10:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 7 Apr 2011 07:10:08 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Thu, 7 Apr 2011 07:10:01 -0700 Thread-Topic: [OAUTH-WG] Security Considerations Section Proposal -02 Thread-Index: Acv09T9GhyV08uv6RkqVOcIesRwQ0AAOBwcQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E1A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D9D6759.3070904@lodderstedt.net> In-Reply-To: <4D9D6759.3070904@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Security Considerations Section Proposal -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 14:08:32 -0000 I think it would be best to publish -16 immediately with this text, mark it= as pending consensus, and continue with a single document. This will make = it easier for new readers as well as for everyone else. I will push it out in a couple of hours. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Thursday, April 07, 2011 12:27 AM > To: OAuth WG > Subject: [OAUTH-WG] Security Considerations Section Proposal -02 >=20 > Hi all, >=20 > I just posted a new revision of the proposed text for the core draft's se= curity > considerations section (http://tools.ietf.org/html/draft-lodderstedt-oaut= h- > securityconsiderations-02). >=20 > The text makes some strong statements wrt client secrets/authentication, > HTTPS, refresh tokens and other topics. This is to facilitate a clear and > understandable specification while also considering (and supporting) _all= _ > relevant use cases (e.g. native apps). >=20 > Since this is the last major building block of the draft, we would like t= o include > this text as soon as possible. >=20 > So please give your feedback soon! >=20 > thanks in advance, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From oleg_gryb@yahoo.com Thu Apr 7 09:34:55 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F7428C161 for ; Thu, 7 Apr 2011 09:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEgL7U04uUUi for ; Thu, 7 Apr 2011 09:34:54 -0700 (PDT) Received: from web37603.mail.mud.yahoo.com (web37603.mail.mud.yahoo.com [209.191.87.86]) by core3.amsl.com (Postfix) with SMTP id 0928528C15F for ; Thu, 7 Apr 2011 09:34:53 -0700 (PDT) Received: (qmail 30064 invoked by uid 60001); 7 Apr 2011 16:36:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1302194194; bh=Fwmic9v2FrXrSYr8aSF7SjMPbCYdUV6cH1kbCQ6RX0s=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=1YPV2OTeJfiBSoGyCDbPDrffHHvtXM1T9wWtTwtFlyvSvddZywBXzePRb12T5PzhNR7jarpLpoQTD9+8tge0tAScPVt3vdxJKMg8lLIzBURvOpEnAbN8flL2NcikCbU14swaqy8uQEmqSmbqi9MrTVnpdqqNW5farZzSeu4I8MQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=wej4vvukNUvK8PnoGkAId98qNu7LRKL0M12PndUX/OpIkK11niH13FvUbwvYMhl7OsH3Q1seOAotuuRffks0z0HdlLxc3gQ0PltIDOONdHhT9wcaCRDIuMujjwxexrTbXve9qvqKJjlrogBDTcVMMBtEQBEqb5nFqKsq3eeKLcE=; Message-ID: <901760.92438.qm@web37603.mail.mud.yahoo.com> X-YMail-OSG: pDUEh5gVM1nPZ9MT4.SkAMdLLkB3jaOBFLlsDEaaC5zCdyh Lq9UBmPumpHKMqv5_NI8q.KkI.Krzh8IAV3TICfdsRV.K0Re9czSvM0RX2kJ ih2oxSAyaEwZsVfQO05Yw2_H7SIzgSmeMDGrLqT4pwmPayZOq8wp3fZF0WGa qx27Z0dcyAZWLjCHZZ1.qH4sZtSzE6sp0seH62cl.NvgXkTLkuRVkBmV2Kxc BXI3h7SyoZZ5eXlYP4L_LpFzXUxtpDgsYuCVz9Qf9D7EOdi4KUc4EpwtPc4w dy_GTp7TtGYqhL1FGdGBtMqB1O_8ITIkS9BUkzANUqKGWA0pcRZl97gsvd.X rfOBqxO40L9ZOwLZfG9NZhUtLcV9_z_R7oGH2Fe3y444ZGRTF.rAz4pHpZAA R92LUxIa73ylIFg-- Received: from [67.121.115.80] by web37603.mail.mud.yahoo.com via HTTP; Thu, 07 Apr 2011 09:36:34 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <4D9D6759.3070904@lodderstedt.net> Date: Thu, 7 Apr 2011 09:36:34 -0700 (PDT) From: Oleg Gryb To: Torsten Lodderstedt , OAuth WG In-Reply-To: <4D9D6759.3070904@lodderstedt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [OAUTH-WG] Security Considerations Section Proposal -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:34:55 -0000 Definitions "they can seamlessly make use of it capabilities" - its? 2.3 "Application developers MUST NOT store access tokens in non-transient memory". What is non-transient memory? Is non-persistent cookie non-transient? Do we know how all browsers store their non-persistent cookies? What if my non-persistent cookie is swapped to a HD along with my user agent by OS? Consider alternative. Application developers MUST limit the life time and accessibility of access tokens in the same way how they protect other secrets on their clients. A 'secure' and 'HTTPOnly' attributes MUST be used if an access token is stored in a cookie. 2.6. "MUST NOT be transmitted in clear: access tokens" It contrdicts to the results of our "MUST" vs "SHOULD" discussion. If we have SHOULD in the spec, we should use the same here. 2.9. "It is strongly RECOMMENDED that native application developers use external browsers instead of browsers embedded in the application for performing the end-user authorization process. External browsers offer a familiar usage experience and a trusted environment, in which users can confirm the authentictity of the site" I'm not sure why we're writing this. Was it proven that embedded browsers are less secure than external. Did anyone analyze all mobile proprietary "external" and "internal" browsers. Please provide evidence or remove the whole paragraph (if such evidence doesn't exist) 2.10. "The authorization server operators SHOULD require..." Can this SHOULD be changed to MUST? If it was already discussed, please ignore and let me know where. ----- Original Message ---- > From: Torsten Lodderstedt > To: OAuth WG > Sent: Thu, April 7, 2011 12:27:21 AM > Subject: [OAUTH-WG] Security Considerations Section Proposal -02 > > Hi all, > > I just posted a new revision of the proposed text for the core draft's >security considerations section >(http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02). > > The text makes some strong statements wrt client secrets/authentication, >HTTPS, refresh tokens and other topics. This is to facilitate a clear and >understandable specification while also considering (and supporting) _all_ >relevant use cases (e.g. native apps). > > Since this is the last major building block of the draft, we would like to >include this text as soon as possible. > > So please give your feedback soon! > > thanks in advance, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Thu Apr 7 09:37:44 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C348828C164 for ; Thu, 7 Apr 2011 09:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSJhv3YCWct4 for ; Thu, 7 Apr 2011 09:37:43 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A6E7828C15F for ; Thu, 7 Apr 2011 09:37:43 -0700 (PDT) Received: (qmail 11066 invoked from network); 7 Apr 2011 16:39:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Apr 2011 16:39:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 7 Apr 2011 09:39:13 -0700 From: Eran Hammer-Lahav To: Oleg Gryb , Torsten Lodderstedt , OAuth WG Date: Thu, 7 Apr 2011 09:39:04 -0700 Thread-Topic: [OAUTH-WG] Security Considerations Section Proposal -02 Thread-Index: Acv1QfqeS3hFXZydT06yfvZgkwTUxAAADz6A Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E24B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D9D6759.3070904@lodderstedt.net> <901760.92438.qm@web37603.mail.mud.yahoo.com> In-Reply-To: <901760.92438.qm@web37603.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Security Considerations Section Proposal -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:37:45 -0000 Please hold off on editorial feedback. Trying to figure out section numbers= after the move is just too annoying. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Oleg Gryb > Sent: Thursday, April 07, 2011 9:37 AM > To: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] Security Considerations Section Proposal -02 >=20 > Definitions > "they can seamlessly make use of it capabilities" - its? >=20 > 2.3 "Application developers MUST NOT store access tokens in non-transient > memory". > What is non-transient memory? Is non-persistent cookie non-transient? Do > we know how all browsers store their non-persistent cookies? > What if my non-persistent cookie is swapped to a HD along with my user > agent by OS? >=20 > Consider alternative. Application developers MUST limit the life time and > accessibility of access tokens in the same way how they protect other sec= rets > on their clients. A 'secure' and 'HTTPOnly' attributes MUST be used if an > access token is stored in a cookie. >=20 > 2.6. >=20 > "MUST NOT be > transmitted in clear: access tokens" >=20 > It contrdicts to the results of our "MUST" vs "SHOULD" discussion. If we = have > SHOULD in the spec, we should use the same here. >=20 > 2.9. > "It is strongly RECOMMENDED that native application developers use > external browsers instead of browsers embedded in the application for > performing the end-user authorization process. External browsers > offer a familiar usage experience and a trusted environment, in which > users can confirm the authentictity of the site" >=20 > I'm not sure why we're writing this. Was it proven that embedded browsers > are less secure than external. Did anyone analyze all mobile proprietary > "external" > and "internal" browsers. Please provide evidence or remove the whole > paragraph (if such evidence doesn't exist) >=20 > 2.10. > "The authorization server operators SHOULD require..." > Can this SHOULD be changed to MUST? If it was already discussed, please > ignore and let me know where. >=20 >=20 >=20 >=20 > ----- Original Message ---- > > From: Torsten Lodderstedt > > To: OAuth WG > > Sent: Thu, April 7, 2011 12:27:21 AM > > Subject: [OAUTH-WG] Security Considerations Section Proposal -02 > > > > Hi all, > > > > I just posted a new revision of the proposed text for the core draft's > >security considerations section > >(http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsideratio= ns- > 02). > > > > The text makes some strong statements wrt client secrets/authenticatio= n, > >HTTPS, refresh tokens and other topics. This is to facilitate a clear a= nd > >understandable specification while also considering (and supporting) _al= l_ > >relevant use cases (e.g. native apps). > > > > Since this is the last major building block of the draft, we would lik= e to > >include this text as soon as possible. > > > > So please give your feedback soon! > > > > thanks in advance, > > Torsten. > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Thu Apr 7 09:47:34 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F423A698B for ; Thu, 7 Apr 2011 09:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19oMd77Tw7Z0 for ; Thu, 7 Apr 2011 09:47:30 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id 931E43A6A1E for ; Thu, 7 Apr 2011 09:47:30 -0700 (PDT) Received: from [80.187.101.233] (helo=[192.168.43.164]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Q7sOP-00039T-GZ; Thu, 07 Apr 2011 18:49:13 +0200 Message-ID: <4D9DEB07.9070302@lodderstedt.net> Date: Thu, 07 Apr 2011 18:49:11 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4D9D6759.3070904@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234465664E1A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664E1A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Security Considerations Section Proposal -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:47:34 -0000 fine with me, you can obtain the source from https://github.com/tlodderstedt/oauth2/raw/master/draft-lodderstedt-oauth-securityconsiderations.xml Am 07.04.2011 16:10, schrieb Eran Hammer-Lahav: > I think it would be best to publish -16 immediately with this text, mark it as pending consensus, and continue with a single document. This will make it easier for new readers as well as for everyone else. > > I will push it out in a couple of hours. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Torsten Lodderstedt >> Sent: Thursday, April 07, 2011 12:27 AM >> To: OAuth WG >> Subject: [OAUTH-WG] Security Considerations Section Proposal -02 >> >> Hi all, >> >> I just posted a new revision of the proposed text for the core draft's security >> considerations section (http://tools.ietf.org/html/draft-lodderstedt-oauth- >> securityconsiderations-02). >> >> The text makes some strong statements wrt client secrets/authentication, >> HTTPS, refresh tokens and other topics. This is to facilitate a clear and >> understandable specification while also considering (and supporting) _all_ >> relevant use cases (e.g. native apps). >> >> Since this is the last major building block of the draft, we would like to include >> this text as soon as possible. >> >> So please give your feedback soon! >> >> thanks in advance, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Thu Apr 7 09:51:32 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B903928C169 for ; Thu, 7 Apr 2011 09:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.57 X-Spam-Level: X-Spam-Status: No, score=-10.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6AnxswIcu6K for ; Thu, 7 Apr 2011 09:51:13 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id D481728C165 for ; Thu, 7 Apr 2011 09:51:12 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Apr 2011 09:52:57 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.38]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0270.002; Thu, 7 Apr 2011 09:52:57 -0700 From: Mike Jones To: Eran Hammer-Lahav , OAuth WG Thread-Topic: In the spirit of compromise Thread-Index: Acv1RDw74p2jkAGDSN2pm/iVHThVRg== Date: Thu, 7 Apr 2011 16:52:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252D0AF8@TK5EX14MBXC203.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.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252D0AF8TK5EX14MBXC203r_" MIME-Version: 1.0 Subject: [OAUTH-WG] In the spirit of compromise X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:51:32 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252D0AF8TK5EX14MBXC203r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having thought about it over night and discussed it, I'm willing to drop my= objection the WWW-Authenticate response not being in the framework specifi= cation, so as to close an open issue that could delay completion of the spe= cifications. Eran, in return, I'd like to ask you to drop your objection to extending th= e error registry in the framework spec so that "resource server error respo= nse" is in the "error usage location" list. If you do so, this would close= another open issue that could delay completion of the specifications. Thank you, -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 06, 2011 4:35 PM To: Mike Jones; OAuth WG Subject: OAuth2 scheme (was Error registry proposal (round 3)) Well... Can't say I didn't see this coming :) The issue is not simply about putting a section back, but about the overall= protocol architecture and how it complies with HTTP. For example, taking the MAC draft, how do you envision the resource server = responding to a failed authentication attempt? A 401 response and what head= er(s)? WWW-Authenticate with 'OAuth2' scheme? 'MAC' scheme? Both? Also see: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/78 You might think you are asking for a simple feature, but this is moving the= protocol from a purely authorization protocol to an authentication protoco= l which is what the split of the token types was designed to accomplish. What I am asking for is to provide full examples of how you envision the OA= uth2 scheme to work in practice, especially considering the MAC draft. Assu= me that the MAC draft, since it is defined as a general purpose scheme, is = not going to change (for the sake of argument only), do you envision it bei= ng used differently when combines with an OAuth access token? That would be= bad. I removed the WWW-Authenticate header and the OAuth2 scheme because it serv= ed no purpose and no one demonstrated how it will be actually used. WRAP is= not a good example because WRAP is a closed protocol (just like OAuth 1.0)= . There is no way to add new authentication schemes to WRAP and in that con= text, it makes sense to define a scheme. But here it will mean moving backw= ards to a protocol where only OAuth-specific authentication schemes can be = used, and they all must be defined as extensions of this master OAuth2 sche= me. There was pretty good consensus not to define a master scheme with sub sche= mes. That is well documented on the list. This thread included the discussi= on about using a common prefix for scheme names, etc. Hope we don't have to= repeat that. So if OAuth2 is not a master scheme for all other scheme to be defined as s= ub-schemes, what is it? I don't have an answer and we kinda need one to put= such a scheme back in the document. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 4:13 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) Actually, you correctly point out (indirectly), that this is related to one= of the open issues that needs to be resolved to complete the specs when yo= u wrote "For such a registry to be useful, you also need to standardize the= authentication header across all schemes and define a standard parameter u= sed to deliver such error codes". This open issue (which there wasn't time to discuss during last week's meet= ing) was the removal of the WWW-Authenticate Response Header. This feature= was present in WRAP and earlier OAuth drafts but was removed without a cle= ar consensus to do so. And indeed, during our private discussions on how t= he draft should be split, at that time, you took the position that the WWW-= Authenticate response should remain in the framework spec. The result has been that there is different and incompatible WWW-Authentica= te response functionality in multiple related drafts - specifically draft-h= ammer-oauth-v2-mac-token-02 and draft-ietf-oauth-v2-bearer-04. Interoperab= ility and developers would both be better served by moving this functionali= ty back into the core. I don't believe that each related OAuth specificatio= n should have to separately specify this functionality. As this was not di= scussed during last week's meeting, a consensus call from the chairs may be= necessary to resolve this issue. -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 06, 2011 3:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Putting aside my view that a registry for resource server error responses a= cross HTTP authentication schemes isn't very useful or interesting, I don't= have an objection to the bearer token specification defining such general = purpose registry. In a way, it is similar to the error response headers def= ined by Digest, only never made generally applicable. The difference in our approaches is that I don't consider the bearer token = or mac token specs to be extensions of the v2 spec, but fully specified HTT= P authentication schemes with OAuth 2.0 binding (i.e. the access token type= registration). Because of that, I don't think the v2 spec is the right pla= ce for such a registry, which is really about HTTP authentication schemes a= nd not OAuth. Therefore, I think it will be more confusing to put such a re= gistry in v2. I'll give you an example. Suppose someone will define a Digest access token= type. When issuing one, the server will send an access token (to be used a= s username) and a secret (to be used as password). To use such a token, the= client will use the HTTP Digest scheme (as is). Digest defines its own set= and method or specifying error code. Would you expect those to be register= ed in your proposed registry? I would assume not. For such a registry to be useful, you also need to standardize the authenti= cation header across all schemes and define a standard parameter used to de= liver such error codes. However, we already moved away from that design by = defining separate HTTP authentication schemes for each token type. But again, I don't have an objection to such a registry defined in the bear= er token spec. I have no intentions of using it for any HTTP authentication= scheme I plan to author. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 3:39 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) The problem with that situation is that it doesn't provide a central regist= ry for resource server error responses across specs, unlike the other kinds= of OAuth error responses. I could define that registry in the bearer toke= n spec, but it would be less confusing to unify it with the proposed regist= ry in the framework spec. I suspect developers would thank us for doing th= at. What do you say? -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 06, 2011 2:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Hi Mike, This is intentional. The error registry defined in v2 is not designed to re= cord errors for the protected resource endpoint response or the WWW-Authent= icate response header when used with the Bearer token scheme (or any other = scheme). The only purpose of the registry is to avoid name collisions between two er= rors used differently with the v2 specification. Since errors used with the= Bearer token scheme will never appear in the same place as the v2 endpoint= s, there is no need for combining these two registries. If the bearer token specification requires error extensibility, you should = retain the registry there and limit it to just the protected resource respo= nse space. Ideally, you would limit it to just the WWW-Authenticate header = 'error' parameter when used with the Bearer scheme. The MAC scheme does not= use error codes, but instead, relies fully on HTTP status code since no ad= ditional error conditions were identified. Also, since your ABNF permits adding additional Authorization header parame= ters, you might want to consider defining a process for doing that, if you = are going to define an error registry. Currently, to add additional paramet= ers, one has to update the Bearer token RFC, in contrast to simply register= ing a new error code (which is likely to come out of a new parameter). EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 2:25 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) Thanks for writing this up, Eran. I believe that this is a step in the rig= ht direction. Wearing my Bearer Token spec editor hat, I just tried to go through the exe= rcise of editing my document to use the registry in draft 15 to register th= e errors defined in the bearer token spec and I hit a roadblock. Specifica= lly, while the errors defined by my spec are returned by resource servers (= flow F in Figure 1), the registry defined by draft 15 does not include "res= ource server error response" in the "error usage location" list. Can you p= lease add this additional error usage location so that the registry can be = used by the bearer token specification? At that point, I believe we'll be able to close the open issue about the ne= ed for an error registry, and I'll update my draft accordingly. Thank you, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, April 05, 2011 3:52 PM To: OAuth WG Subject: [OAUTH-WG] Error registry proposal (round 3) The following is my new proposal, based on Mike Jones' and my earlier propo= sals. It is basically a combination of the two. This proposal does not allow defining new error codes unless another extens= ion is involved (new grant type, request parameter, token type). The reason= for not defining an open ended error registry is that defining new error c= odes for existing implementations is bad for interoperability and can lead = to unexpected results (developers not taking into account receiving a new e= rror when talking to a compliant 2.0 server). We don't have any use cases f= or defining such new errors for the v2 specification. New errors only come = from extensions and must be defined in that context. I have applied to changes to the -14 draft and clearly marked them with [[P= ending Consensus]] so that there is no issue with removing them or changing= them later. --- Add to the error codes list in sections 4.1.2.1 and 4.2.2.1: a 4xx or 5xx HTTP status code (except for 400 and 401) The authorization server MAY set the "error" parameter value to a numerical HTTP status code from the 4xx or 5xx range, with the exception of the 400 (Bad Request) and 401 (Unauthorized) status codes. For example, if the service is temporarily unavailable, the authorization server MAY return an error response with "error" set to "503". Add a new section 8.4: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the token error response (Section 5.2), such error codes MAY be defined. Extension error codes MUST be registered (following the procedures in Section 10.3) if the extension they are used in conjunction with is registered. Additional error codes used with unregistered extensions MAY be registered. Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" should be named "example_invalid". error-code =3D ALPHA *error-char error-char =3D "-" / "." / "_" / DIGIT / ALPHA Add a new section 10.3: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app-ads@tools.ietf.org email address or d= irectly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. 10.3.1. Registration Template Error name: The name requested (e.g., "example"). Error usage location: The location(s) where the error can be used. The possible locations are: authorization code grant error response (Section 4.1.2.1), implicit grant error response (Section 4.2.2.1), or token error response (Section 5.2). Related protocol extension: The name of the extension grant type, access token type, or extension parameter, the error code is used in conjunction with. Change controller: For standards-track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included. Specification document(s): Reference to document that specifies the error code, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required. --_000_4E1F6AAD24975D4BA5B1680429673943252D0AF8TK5EX14MBXC203r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Having thought about i= t over night and discussed it, I’m willing to drop my objection the W= WW-Authenticate response not being in the framework specification, so as to= close an open issue that could delay completion of the specifications.

 

Eran, in return, IR= 17;d like to ask you to drop your objection to extending the error registry= in the framework spec so that “resource server error response&= #8221; is in the “error usage location” list.  If you do s= o, this would close another open issue that could delay completion of the s= pecifications.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;         Thank you,

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

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, April 06, 2011 4:35 PM
To: Mike Jones; OAuth WG
Subject: OAuth2 scheme (was Error registry proposal (round 3))<= /o:p>

 

Well… Can’= t say I didn’t see this coming J

 

The issue is not simpl= y about putting a section back, but about the overall protocol architecture= and how it complies with HTTP.

 

For example, taking th= e MAC draft, how do you envision the resource server responding to a failed= authentication attempt? A 401 response and what header(s)? WWW-Authenticat= e with ‘OAuth2’ scheme? ‘MAC’ scheme? Both?

 

Also see: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/78<= /p>

 

You might think you ar= e asking for a simple feature, but this is moving the protocol from a purel= y authorization protocol to an authentication protocol which is what the sp= lit of the token types was designed to accomplish.

 

What I am asking for i= s to provide full examples of how you envision the OAuth2 scheme to work in= practice, especially considering the MAC draft. Assume that the MAC draft,= since it is defined as a general purpose scheme, is not going to change (for the sake of argument only), do you env= ision it being used differently when combines with an OAuth access token? T= hat would be bad.

 

I removed the WWW-Auth= enticate header and the OAuth2 scheme because it served no purpose and no o= ne demonstrated how it will be actually used. WRAP is not a good example be= cause WRAP is a closed protocol (just like OAuth 1.0). There is no way to add new authentication schemes to WRAP= and in that context, it makes sense to define a scheme. But here it will m= ean moving backwards to a protocol where only OAuth-specific authentication= schemes can be used, and they all must be defined as extensions of this master OAuth2 scheme.

 

There was pretty good = consensus not to define a master scheme with sub schemes. That is well docu= mented on the list. This thread included the discussion about using a commo= n prefix for scheme names, etc. Hope we don’t have to repeat that.

 

So if OAuth2 is not a = master scheme for all other scheme to be defined as sub-schemes, what is it= ? I don’t have an answer and we kinda need one to put such a scheme b= ack in the document.

 

EHL<= /p>

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Wednesday, April 06, 2011 4:13 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error registry proposal (round 3)

 

Actually, you correctl= y point out (indirectly), that this is related to one of the open issues th= at needs to be resolved to complete the specs when you wrote “= For such a registry to be useful, you also need to standardize the authentication header acros= s all schemes and define a standard parameter used to deliver such error co= des”.

 

This open issue (which= there wasn’t time to discuss during last week’s meeting) was t= he removal of the WWW-Authenticate Response Header.  This feature was = present in WRAP and earlier OAuth drafts but was removed without a clear consensus to do so.  And indeed, during our private d= iscussions on how the draft should be split, at that time, you took the pos= ition that the WWW-Authenticate response should remain in the framework spe= c.

 

The result has been th= at there is different and incompatible WWW-Authenticate response functional= ity in multiple related drafts – specifically draft-hammer-oauth-v2-m= ac-token-02 and draft-ietf-oauth-v2-bearer-04.  Interoperability and developers would both be better served by moving this= functionality back into the core. I don’t believe that each related = OAuth specification should have to separately specify this functionality.&n= bsp; As this was not discussed during last week’s meeting, a consensus call from the chairs may be necessary to= resolve this issue.

 

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

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, April 06, 2011 3:58 PM
To: Mike Jones; OAuth WG
Subject: RE: Error registry proposal (round 3)

 

Putting aside my view = that a registry for resource server error responses across HTTP authenticat= ion schemes isn’t very useful or interesting, I don’t have an o= bjection to the bearer token specification defining such general purpose registry. In a way, it is similar to the error respon= se headers defined by Digest, only never made generally applicable.

 

The difference in our = approaches is that I don’t consider the bearer token or mac token spe= cs to be extensions of the v2 spec, but fully specified HTTP authentication= schemes with OAuth 2.0 binding (i.e. the access token type registration). Because of that, I don’t think the = v2 spec is the right place for such a registry, which is really about HTTP = authentication schemes and not OAuth. Therefore, I think it will be more co= nfusing to put such a registry in v2.

 

I’ll give you an= example. Suppose someone will define a Digest access token type. When issu= ing one, the server will send an access token (to be used as username) and = a secret (to be used as password). To use such a token, the client will use the HTTP Digest scheme (as is). Digest d= efines its own set and method or specifying error code. Would you expect th= ose to be registered in your proposed registry? I would assume not.

 

For such a registry to= be useful, you also need to standardize the authentication header across a= ll schemes and define a standard parameter used to deliver such error codes= . However, we already moved away from that design by defining separate HTTP authentication schemes for each toke= n type.

 

But again, I don’= ;t have an objection to such a registry defined in the bearer token spec. I= have no intentions of using it for any HTTP authentication scheme I plan t= o author.

 

EHL<= /p>

 

 

 

 

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Wednesday, April 06, 2011 3:39 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error registry proposal (round 3)

 

The problem with that = situation is that it doesn’t provide a central registry for resource = server error responses across specs, unlike the other kinds of OAuth error = responses.  I could define that registry in the bearer token spec, but it would be less confusing to unify it with the= proposed registry in the framework spec.  I suspect developers would = thank us for doing that.

 

What do you say?<= /o:p>

 

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

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, April 06, 2011 2:58 PM
To: Mike Jones; OAuth WG
Subject: RE: Error registry proposal (round 3)

 

Hi Mike,

 

This is intentional. T= he error registry defined in v2 is not designed to record errors for the pr= otected resource endpoint response or the WWW-Authenticate response header = when used with the Bearer token scheme (or any other scheme).

 

The only purpose of th= e registry is to avoid name collisions between two errors used differently = with the v2 specification. Since errors used with the Bearer token scheme w= ill never appear in the same place as the v2 endpoints, there is no need for combining these two registries.

 

If the bearer token sp= ecification requires error extensibility, you should retain the registry th= ere and limit it to just the protected resource response space. Ideally, yo= u would limit it to just the WWW-Authenticate header ‘error’ parameter when used with the Bearer scheme. The= MAC scheme does not use error codes, but instead, relies fully on HTTP sta= tus code since no additional error conditions were identified.

 

Also, since your ABNF = permits adding additional Authorization header parameters, you might want t= o consider defining a process for doing that, if you are going to define an= error registry. Currently, to add additional parameters, one has to update the Bearer token RFC, in contrast to simply = registering a new error code (which is likely to come out of a new paramete= r).

 

EHL<= /p>

 

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Wednesday, April 06, 2011 2:25 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error registry proposal (round 3)

 

Thanks for writing thi= s up, Eran.  I believe that this is a step in the right direction.

 

Wearing my Bearer Toke= n spec editor hat, I just tried to go through the exercise of editing my do= cument to use the registry in draft 15 to register the errors defined in th= e bearer token spec and I hit a roadblock.  Specifically, while the errors defined by my spec are returned by resource= servers (flow F in Figure 1), the registry defined by draft 15 does not in= clude “resource server error response” in the “error usag= e location” list.  Can you please add this additional error usage location so that the registry can be used by the bearer token = specification?

 

At that point, I belie= ve we’ll be able to close the open issue about the need for an error = registry, and I’ll update my draft accordingly.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Thank you,

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, April 05, 2011 3:52 PM
To: OAuth WG
Subject: [OAUTH-WG] Error registry proposal (round 3)

 

The following is my new proposal, based on Mike J= ones’ and my earlier proposals. It is basically a combination of the = two.

 

This proposal does not allow defining new error c= odes unless another extension is involved (new grant type, request paramete= r, token type). The reason for not defining an open ended error registry is= that defining new error codes for existing implementations is bad for interoperability and can lead to unexp= ected results (developers not taking into account receiving a new error whe= n talking to a compliant 2.0 server). We don't have any use cases for defin= ing such new errors for the v2 specification. New errors only come from extensions and must be defined in that context.<= o:p>

 

I have applied to changes to the -14 draft and cl= early marked them with [[Pending Consensus]] so that there is no issue with= removing them or changing them later.

 

---

 

Add to the error codes list in sections 4.1.2.1 a= nd 4.2.2.1:

 

       &nbs= p; a 4xx or 5xx HTTP status code (except for 400 and 401)=

       &nbs= p;       The authorization server MAY set the= "error" parameter

       &nbs= p;       value to a numerical HTTP status cod= e from the 4xx or 5xx

       &nbs= p;       range, with the exception of the 400= (Bad Request) and

       &nbs= p;       401 (Unauthorized) status codes.&nbs= p; For example, if the

       &nbs= p;       service is temporarily unavailable, = the authorization

       &nbs= p;       server MAY return an error response = with "error" set to

       &nbs= p;       "503".

 

 

Add a new section 8.4:

 

8.4.  Defining Additional Error Codes=

 
   In cases where protocol exten=
sions (i.e. access token types,
   extension parameters, or exte=
nsion grant types) require additional
   error codes to be used with t=
he authorization code grant error
   response (Section 4.1.2.1), t=
he implicit grant error response
   (Section 4.2.2.1), or the tok=
en error response (Section 5.2), such
   error codes MAY be defined.
 
   Extension error codes MUST be=
 registered (following the procedures in
   Section 10.3) if the extensio=
n they are used in conjunction with is
   registered.  Additional =
error codes used with unregistered extensions
   MAY be registered.=

 
   Error codes MUST conform to t=
he error-code ABNF, and SHOULD be
   prefixed by an identifying na=
me when possible.  For example, an error
   identifying an invalid value =
set to the extension parameter "example"
   should be named "example=
_invalid".
 
 
     error-code &=
nbsp; =3D ALPHA *error-char
     error-char &=
nbsp; =3D "-" / "." / "_" / DIGIT / ALPHA

 

 

Add a new section 10.3:

 

10.3.  The OAuth Extensions Error Reg=
istry
 
   This specification establishe=
s the OAuth extensions error registry.
 
   Additional error codes used t=
ogether with other protocol extensions
   (i.e. extension grant types, =
access token types, or extension
   parameters) are registered on=
 the advice of one or more Designated
   Experts (appointed by the IES=
G or their delegate), with a
   Specification Required (using=
 terminology from [RFC5226]).  However,
   to allow for the allocation o=
f values prior to publication, the
   Designated Expert(s) may appr=
ove registration once they are satisfied
   that such a specification wil=
l be published.
 
   Registration requests should =
be sent to the [TBD]@ietf.org mailing
   list for review and comment, =
with an appropriate subject (e.g.,
   "Request for error code:=
 example"). [[ Note to RFC-EDITOR: The name
   of the mailing list should be=
 determined in consultation with the
   IESG and IANA.  Suggeste=
d name: oauth-ext-review. ]]
 
   Within at most 14 days of the=
 request, the Designated Expert(s) will
   either approve or deny the re=
gistration request, communicating this
   decision to the review list a=
nd IANA.  Denials should include an
   explanation and, if applicabl=
e, suggestions as to how to make the
   request successful.
 
   Decisions (or lack thereof) m=
ade by the Designated Expert can be
   first appealed to Application=
 Area Directors (contactable using
   app-ads@tools.ietf.org email address or directly by lookin=
g up their
   email addresses on http://www.iesg.org/ website) and, if the
   appellant is not satisfied wi=
th the response, to the full IESG (using
   the iesg@iesg.org mailing list).
 
   IANA should only accept regis=
try updates from the Designated
   Expert(s), and should direct =
all requests for registration to the
   review mailing list.
 
10.3.1.  Registration Template
 
   Error name:=

      The name re=
quested (e.g., "example").
   Error usage location:
      The locatio=
n(s) where the error can be used.  The possible

      locations a=
re: authorization code grant error response


      (Section 4.=
1.2.1), implicit grant error response


      (Section 4.=
2.2.1), or token error response (Section 5.2).


   Related protocol extension:


      The name of=
 the extension grant type, access token type, or


      extension p=
arameter, the error code is used in conjunction with.

   Change controller:=



      For standar=
ds-track RFCs, state "IETF".  For others, give the name=



      of the resp=
onsible party.  Other details (e.g., postal address,=



      e-mail addr=
ess, home page URI) may also be included.


   Specification document(s):


      Reference t=
o document that specifies the error code, preferably

      including a=
 URI that can be used to retrieve a copy of the


      document.&n=
bsp; An indication of the relevant sections may also be

      included, b=
ut is not required.


 


 
--_000_4E1F6AAD24975D4BA5B1680429673943252D0AF8TK5EX14MBXC203r_-- From eran@hueniverse.com Thu Apr 7 11:19:01 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7516B28C0D8 for ; Thu, 7 Apr 2011 11:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P91KFXKlmxxd for ; Thu, 7 Apr 2011 11:18:42 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E718D3A67B0 for ; Thu, 7 Apr 2011 11:18:41 -0700 (PDT) Received: (qmail 27708 invoked from network); 7 Apr 2011 18:20:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Apr 2011 18:20:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 7 Apr 2011 11:20:20 -0700 From: Eran Hammer-Lahav To: Mike Jones , OAuth WG Date: Thu, 7 Apr 2011 11:20:12 -0700 Thread-Topic: In the spirit of compromise Thread-Index: Acv1RDw74p2jkAGDSN2pm/iVHThVRgAABfMw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E298@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943252D0AF8@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252D0AF8@TK5EX14MBXC203.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_90C41DD21FB7C64BB94121FBBC2E7234465664E298P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] In the spirit of compromise X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 18:19:01 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E298P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, I don't think this is a matter of each one giving up something. I have significant technical reasons for my position, and I am much more in= terested in taking the time discussing these than just finding an easy way = to close issues. There is no reason to expect a thorough discussion taking = more than a week or two, which will still be faster than the time it will t= ake to finish review on the security considerations section. Adding an error registry for error codes used by the various HTTP authentic= ation schemes for use in 401 responses in the WWW-Authenticate header does = not make technical sense for the v2 specification as it currently stand. It= would only make sense if we were to define a master HTTP authentication sc= heme called OAuth2 (or similar) and require that every new token type uses = that scheme with a sub-scheme. Then, such an error registry will make sense= . For example: Authorization: OAuth2 type=3D"bearer", token=3D"asdalsijdlkasjd" Authorization: OAuth2 type=3D"mac", id=3D"asdasdasd", etc... If you have use cases and requirements for introducing such a new master HT= TP authentication scheme, please present them and we will have a discussion= about how to best address them, including the possibility of adding such a= scheme. In the past, such a proposal was rejected due to lack of working g= roup consensus. If I recall correctly, only Marius was advocating that appr= oach. Alternatively, if you have use cases or requirements for introducing just t= he WWW-Authenticate side of an OAuth2 authorization scheme (your open issue= ), which includes an 'error' attribute for use with the proposed registry, = please present those and explain how it will work alongside the Bearer and = MAC schemes (as currently drafted). Thanks, EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, April 07, 2011 9:53 AM To: Eran Hammer-Lahav; OAuth WG Subject: In the spirit of compromise Having thought about it over night and discussed it, I'm willing to drop my= objection the WWW-Authenticate response not being in the framework specifi= cation, so as to close an open issue that could delay completion of the spe= cifications. Eran, in return, I'd like to ask you to drop your objection to extending th= e error registry in the framework spec so that "resource server error respo= nse" is in the "error usage location" list. If you do so, this would close= another open issue that could delay completion of the specifications. Thank you, -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 06, 2011 4:35 PM To: Mike Jones; OAuth WG Subject: OAuth2 scheme (was Error registry proposal (round 3)) Well... Can't say I didn't see this coming :) The issue is not simply about putting a section back, but about the overall= protocol architecture and how it complies with HTTP. For example, taking the MAC draft, how do you envision the resource server = responding to a failed authentication attempt? A 401 response and what head= er(s)? WWW-Authenticate with 'OAuth2' scheme? 'MAC' scheme? Both? Also see: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/78 You might think you are asking for a simple feature, but this is moving the= protocol from a purely authorization protocol to an authentication protoco= l which is what the split of the token types was designed to accomplish. What I am asking for is to provide full examples of how you envision the OA= uth2 scheme to work in practice, especially considering the MAC draft. Assu= me that the MAC draft, since it is defined as a general purpose scheme, is = not going to change (for the sake of argument only), do you envision it bei= ng used differently when combines with an OAuth access token? That would be= bad. I removed the WWW-Authenticate header and the OAuth2 scheme because it serv= ed no purpose and no one demonstrated how it will be actually used. WRAP is= not a good example because WRAP is a closed protocol (just like OAuth 1.0)= . There is no way to add new authentication schemes to WRAP and in that con= text, it makes sense to define a scheme. But here it will mean moving backw= ards to a protocol where only OAuth-specific authentication schemes can be = used, and they all must be defined as extensions of this master OAuth2 sche= me. There was pretty good consensus not to define a master scheme with sub sche= mes. That is well documented on the list. This thread included the discussi= on about using a common prefix for scheme names, etc. Hope we don't have to= repeat that. So if OAuth2 is not a master scheme for all other scheme to be defined as s= ub-schemes, what is it? I don't have an answer and we kinda need one to put= such a scheme back in the document. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 4:13 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) Actually, you correctly point out (indirectly), that this is related to one= of the open issues that needs to be resolved to complete the specs when yo= u wrote "For such a registry to be useful, you also need to standardize the= authentication header across all schemes and define a standard parameter u= sed to deliver such error codes". This open issue (which there wasn't time to discuss during last week's meet= ing) was the removal of the WWW-Authenticate Response Header. This feature= was present in WRAP and earlier OAuth drafts but was removed without a cle= ar consensus to do so. And indeed, during our private discussions on how t= he draft should be split, at that time, you took the position that the WWW-= Authenticate response should remain in the framework spec. The result has been that there is different and incompatible WWW-Authentica= te response functionality in multiple related drafts - specifically draft-h= ammer-oauth-v2-mac-token-02 and draft-ietf-oauth-v2-bearer-04. Interoperab= ility and developers would both be better served by moving this functionali= ty back into the core. I don't believe that each related OAuth specificatio= n should have to separately specify this functionality. As this was not di= scussed during last week's meeting, a consensus call from the chairs may be= necessary to resolve this issue. -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 06, 2011 3:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Putting aside my view that a registry for resource server error responses a= cross HTTP authentication schemes isn't very useful or interesting, I don't= have an objection to the bearer token specification defining such general = purpose registry. In a way, it is similar to the error response headers def= ined by Digest, only never made generally applicable. The difference in our approaches is that I don't consider the bearer token = or mac token specs to be extensions of the v2 spec, but fully specified HTT= P authentication schemes with OAuth 2.0 binding (i.e. the access token type= registration). Because of that, I don't think the v2 spec is the right pla= ce for such a registry, which is really about HTTP authentication schemes a= nd not OAuth. Therefore, I think it will be more confusing to put such a re= gistry in v2. I'll give you an example. Suppose someone will define a Digest access token= type. When issuing one, the server will send an access token (to be used a= s username) and a secret (to be used as password). To use such a token, the= client will use the HTTP Digest scheme (as is). Digest defines its own set= and method or specifying error code. Would you expect those to be register= ed in your proposed registry? I would assume not. For such a registry to be useful, you also need to standardize the authenti= cation header across all schemes and define a standard parameter used to de= liver such error codes. However, we already moved away from that design by = defining separate HTTP authentication schemes for each token type. But again, I don't have an objection to such a registry defined in the bear= er token spec. I have no intentions of using it for any HTTP authentication= scheme I plan to author. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 3:39 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) The problem with that situation is that it doesn't provide a central regist= ry for resource server error responses across specs, unlike the other kinds= of OAuth error responses. I could define that registry in the bearer toke= n spec, but it would be less confusing to unify it with the proposed regist= ry in the framework spec. I suspect developers would thank us for doing th= at. What do you say? -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 06, 2011 2:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Hi Mike, This is intentional. The error registry defined in v2 is not designed to re= cord errors for the protected resource endpoint response or the WWW-Authent= icate response header when used with the Bearer token scheme (or any other = scheme). The only purpose of the registry is to avoid name collisions between two er= rors used differently with the v2 specification. Since errors used with the= Bearer token scheme will never appear in the same place as the v2 endpoint= s, there is no need for combining these two registries. If the bearer token specification requires error extensibility, you should = retain the registry there and limit it to just the protected resource respo= nse space. Ideally, you would limit it to just the WWW-Authenticate header = 'error' parameter when used with the Bearer scheme. The MAC scheme does not= use error codes, but instead, relies fully on HTTP status code since no ad= ditional error conditions were identified. Also, since your ABNF permits adding additional Authorization header parame= ters, you might want to consider defining a process for doing that, if you = are going to define an error registry. Currently, to add additional paramet= ers, one has to update the Bearer token RFC, in contrast to simply register= ing a new error code (which is likely to come out of a new parameter). EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 06, 2011 2:25 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) Thanks for writing this up, Eran. I believe that this is a step in the rig= ht direction. Wearing my Bearer Token spec editor hat, I just tried to go through the exe= rcise of editing my document to use the registry in draft 15 to register th= e errors defined in the bearer token spec and I hit a roadblock. Specifica= lly, while the errors defined by my spec are returned by resource servers (= flow F in Figure 1), the registry defined by draft 15 does not include "res= ource server error response" in the "error usage location" list. Can you p= lease add this additional error usage location so that the registry can be = used by the bearer token specification? At that point, I believe we'll be able to close the open issue about the ne= ed for an error registry, and I'll update my draft accordingly. Thank you, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, April 05, 2011 3:52 PM To: OAuth WG Subject: [OAUTH-WG] Error registry proposal (round 3) The following is my new proposal, based on Mike Jones' and my earlier propo= sals. It is basically a combination of the two. This proposal does not allow defining new error codes unless another extens= ion is involved (new grant type, request parameter, token type). The reason= for not defining an open ended error registry is that defining new error c= odes for existing implementations is bad for interoperability and can lead = to unexpected results (developers not taking into account receiving a new e= rror when talking to a compliant 2.0 server). We don't have any use cases f= or defining such new errors for the v2 specification. New errors only come = from extensions and must be defined in that context. I have applied to changes to the -14 draft and clearly marked them with [[P= ending Consensus]] so that there is no issue with removing them or changing= them later. --- Add to the error codes list in sections 4.1.2.1 and 4.2.2.1: a 4xx or 5xx HTTP status code (except for 400 and 401) The authorization server MAY set the "error" parameter value to a numerical HTTP status code from the 4xx or 5xx range, with the exception of the 400 (Bad Request) and 401 (Unauthorized) status codes. For example, if the service is temporarily unavailable, the authorization server MAY return an error response with "error" set to "503". Add a new section 8.4: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the token error response (Section 5.2), such error codes MAY be defined. Extension error codes MUST be registered (following the procedures in Section 10.3) if the extension they are used in conjunction with is registered. Additional error codes used with unregistered extensions MAY be registered. Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" should be named "example_invalid". error-code =3D ALPHA *error-char error-char =3D "-" / "." / "_" / DIGIT / ALPHA Add a new section 10.3: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app-ads@tools.ietf.org email address or d= irectly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. 10.3.1. Registration Template Error name: The name requested (e.g., "example"). Error usage location: The location(s) where the error can be used. The possible locations are: authorization code grant error response (Section 4.1.2.1), implicit grant error response (Section 4.2.2.1), or token error response (Section 5.2). Related protocol extension: The name of the extension grant type, access token type, or extension parameter, the error code is used in conjunction with. Change controller: For standards-track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included. Specification document(s): Reference to document that specifies the error code, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required. --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E298P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mike,

 

I don’t think this is a matter of each one gi= ving up something.

 

I have significant technical reasons for my position, a= nd I am much more interested in taking the time discussing these than just = finding an easy way to close issues. There is no reason to expect a thoroug= h discussion taking more than a week or two, which will still be faster tha= n the time it will take to finish review on the security considerations sec= tion.

 

Adding an error registry for error codes used by the various HTTP au= thentication schemes for use in 401 responses in the WWW-Authenticate heade= r does not make technical sense for the v2 specification as it currently st= and. It would only make sense if we were to define a master HTTP authentica= tion scheme called OAuth2 (or similar) and require that every new token typ= e uses that scheme with a sub-scheme. Then, such an error registry will mak= e sense.

 

For example:

 

Authorization: OAuth2 type=3D”bearer”, = token=3D”asdalsijdlkasjd”

Authorization: OAuth2 type=3D”mac&= #8221;, id=3D”asdasdasd”, etc…

 

<= p class=3DMsoNormal>If you have use cases and= requirements for introducing such a new master HTTP authentication scheme,= please present them and we will have a discussion about how to best addres= s them, including the possibility of adding such a scheme. In the past, suc= h a proposal was rejected due to lack of working group consensus. If I reca= ll correctly, only Marius was advocating that approach.

 

Alternatively, if = you have use cases or requirements for introducing just the WWW-Authenticat= e side of an OAuth2 authorization scheme (your open issue), which includes = an ‘error’ attribute for use with the proposed registry, please= present those and explain how it will work alongside the Bearer and MAC sc= hemes (as currently drafted).

 

Thanks,

 

EHL

 

 

=

From: Mike Jones [mailto:Michael.Jo= nes@microsoft.com]
Sent: Thursday, April 07, 2011 9:53 AM
= To: Eran Hammer-Lahav; OAuth WG
Subject: In the spirit of com= promise

 

Having thought a= bout it over night and discussed it, I’m willing to drop my objection= the WWW-Authenticate response not being in the framework specification, so= as to close an open issue that could delay completion of the specification= s.

=  

Eran, in return, I’d like to ask you to drop your objection to ex= tending the error registry in the framework spec so that “resource se= rver error response” is in the “error usage location” lis= t.  If you do so, this would close another open issue that could delay= completion of the specifications.

 

      &nb= sp;            =             &nb= sp;            =              &n= bsp;      Thank you,

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

 

From: Eran Hammer-Lahav [mailto:eran@= hueniverse.com]
Sent: Wednesday, April 06, 2011 4:35 PM
To= : Mike Jones; OAuth WG
Subject: OAuth2 scheme (was Error regi= stry proposal (round 3))

 

Well… Can’t say I didn’t see this coming J

 

The issue is not simply about putting a section back, but about th= e overall protocol architecture and how it complies with HTTP.

 

For example= , taking the MAC draft, how do you envision the resource server responding = to a failed authentication attempt? A 401 response and what header(s)? WWW-= Authenticate with ‘OAuth2’ scheme? ‘MAC’ scheme? Bo= th?

 

Also see: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/78

 

You might th= ink you are asking for a simple feature, but this is moving the protocol fr= om a purely authorization protocol to an authentication protocol which is w= hat the split of the token types was designed to accomplish.

 =

What I am ask= ing for is to provide full examples of how you envision the OAuth2 scheme t= o work in practice, especially considering the MAC draft. Assume that the M= AC draft, since it is defined as a general purpose scheme, is not going to = change (for the sake of argument only), do you envision it being used diffe= rently when combines with an OAuth access token? That would be bad.

 = ;

I remo= ved the WWW-Authenticate header and the OAuth2 scheme because it served no = purpose and no one demonstrated how it will be actually used. WRAP is not a= good example because WRAP is a closed protocol (just like OAuth 1.0). Ther= e is no way to add new authentication schemes to WRAP and in that context, = it makes sense to define a scheme. But here it will mean moving backwards t= o a protocol where only OAuth-specific authentication schemes can be used, = and they all must be defined as extensions of this master OAuth2 scheme.

=  

T= here was pretty good consensus not to define a master scheme with sub schem= es. That is well documented on the list. This thread included the discussio= n about using a common prefix for scheme names, etc. Hope we don’t ha= ve to repeat that.

 

So if OAuth2 is not a master scheme for all other schem= e to be defined as sub-schemes, what is it? I don’t have an answer an= d we kinda need one to put such a scheme back in the document.

 

EHL

 = ;

From: Mike Jones= [mailto:Michael.Jones@microsoft.com]
Sent: Wednesday, April 06,= 2011 4:13 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: = RE: Error registry proposal (round 3)

 

Actually, you correctly point out (indirectly), that this is = related to one of the open issues that needs to be resolved to complete the= specs when you wrote “For such = a registry to be useful, you also need to standardize the authentication he= ader across all schemes and define a standard parameter used to deliver suc= h error codes”.

 

This open issue= (which there wasn’t time to discuss during last week’s meeting= ) was the removal of the WWW-Authenticate Response Header.  This featu= re was present in WRAP and earlier OAuth drafts but was removed without a c= lear consensus to do so.  And indeed, during our private discussions o= n how the draft should be split, at that time, you took the position that t= he WWW-Authenticate response should remain in the framework spec.

 <= /o:p>

The resu= lt has been that there is different and incompatible WWW-Authenticate respo= nse functionality in multiple related drafts – specifically draft-ham= mer-oauth-v2-mac-token-02 and draft-ietf-oauth-v2-bearer-04.  Interope= rability and developers would both be better served by moving this function= ality back into the core. I don’t believe that each related OAuth spe= cification should have to separately specify this functionality.  As t= his was not discussed during last week’s meeting, a consensus call fr= om the chairs may be necessary to resolve this issue.

=

 =

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

 =

From: Eran Hammer-Lahav = [mailto:eran@hueniverse.com]
Sent: Wednesday, April 06, 2011 3:5= 8 PM
To: Mike Jones; OAuth WG
Subject: RE: Error regist= ry proposal (round 3)

 

Pu= tting aside my view that a registry for resource server error responses acr= oss HTTP authentication schemes isn’t very useful or interesting, I d= on’t have an objection to the bearer token specification defining suc= h general purpose registry. In a way, it is similar to the error response h= eaders defined by Digest, only never made generally applicable.<= /span>

 

The differ= ence in our approaches is that I don’t consider the bearer token or m= ac token specs to be extensions of the v2 spec, but fully specified HTTP au= thentication schemes with OAuth 2.0 binding (i.e. the access token type reg= istration). Because of that, I don’t think the v2 spec is the right p= lace for such a registry, which is really about HTTP authentication schemes= and not OAuth. Therefore, I think it will be more confusing to put such a = registry in v2.

 

I’ll give you an example. Suppose someone will def= ine a Digest access token type. When issuing one, the server will send an a= ccess token (to be used as username) and a secret (to be used as password).= To use such a token, the client will use the HTTP Digest scheme (as is). D= igest defines its own set and method or specifying error code. Would you ex= pect those to be registered in your proposed registry? I would assume not.<= o:p>

 

For such a registry to be useful, you also need to standardize the authent= ication header across all schemes and define a standard parameter used to d= eliver such error codes. However, we already moved away from that design by= defining separate HTTP authentication schemes for each token type.

 = ;

But ag= ain, I don’t have an objection to such a registry defined in the bear= er token spec. I have no intentions of using it for any HTTP authentication= scheme I plan to author.

 

EHL

 

 

 

 

 

From: Mike Jones [mailto:Michael.Jones= @microsoft.com]
Sent: Wednesday, April 06, 2011 3:39 PM
To= : Eran Hammer-Lahav; OAuth WG
Subject: RE: Error registry pro= posal (round 3)

=  

The prob= lem with that situation is that it doesn’t provide a central registry= for resource server error responses across specs, unlike the other kinds o= f OAuth error responses.  I could define that registry in the bearer t= oken spec, but it would be less confusing to unify it with the proposed reg= istry in the framework spec.  I suspect developers would thank us for = doing that.

 

What do you say?

 

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

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.c= om]
Sent: Wednesday, April 06, 2011 2:58 PM
To: Mike J= ones; OAuth WG
Subject: RE: Error registry proposal (round 3)

 

Hi Mike,<= /p>

 

This is intention= al. The error registry defined in v2 is not designed to record errors for t= he protected resource endpoint response or the WWW-Authenticate response he= ader when used with the Bearer token scheme (or any other scheme).

 =

The onl= y purpose of the registry is to avoid name collisions between two errors us= ed differently with the v2 specification. Since errors used with the Bearer= token scheme will never appear in the same place as the v2 endpoints, ther= e is no need for combining these two registries.

 

<= p class=3DMsoNormal>If the bearer token speci= fication requires error extensibility, you should retain the registry there= and limit it to just the protected resource response space. Ideally, you w= ould limit it to just the WWW-Authenticate header ‘error’ param= eter when used with the Bearer scheme. The MAC scheme does not use error co= des, but instead, relies fully on HTTP status code since no additional erro= r conditions were identified.

 

Also, since your ABNF permits adding additio= nal Authorization header parameters, you might want to consider defining a = process for doing that, if you are going to define an error registry. Curre= ntly, to add additional parameters, one has to update the Bearer token RFC,= in contrast to simply registering a new error code (which is likely to com= e out of a new parameter).

 

EHL

<= span style=3D'color:#1F497D'> 

 

From: Mike Jones [mailto:Michael.Jones@microsoft.= com]
Sent: Wednesday, April 06, 2011 2:25 PM
To: Eran = Hammer-Lahav; OAuth WG
Subject: RE: Error registry proposal (roun= d 3)

 

Thanks for writing = this up, Eran.  I believe that this is a step in the right direction.<= o:p>

 

Wearing my Bearer Token spec editor hat, I just tried to go through the ex= ercise of editing my document to use the registry in draft 15 to register t= he errors defined in the bearer token spec and I hit a roadblock.  Spe= cifically, while the errors defined by my spec are returned by resource ser= vers (flow F in Figure 1), the registry defined by draft 15 does not includ= e “resource server error response” in the “error usage lo= cation” list.  Can you please add this additional error usage lo= cation so that the registry can be used by the bearer token specification?<= o:p>

 

At that point, I believe we’ll be able to close the open issue about= the need for an error registry, and I’ll update my draft accordingly= .

<= o:p> 

            =             &nb= sp;            =             &nb= sp;            =   Thank you,

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

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, April 05, 2011 = 3:52 PM
To: OAuth WG
Subject: [OAUTH-WG] Error registry= proposal (round 3)

<= o:p> 

The following is my new proposa= l, based on Mike Jones’ and my earlier proposals. It is basically a c= ombination of the two.

 

This proposal does not allow defining new er= ror codes unless another extension is involved (new grant type, request par= ameter, token type). The reason for not defining an open ended error regist= ry is that defining new error codes for existing implementations is bad for= interoperability and can lead to unexpected results (developers not taking= into account receiving a new error when talking to a compliant 2.0 server)= . We don't have any use cases for defining such new errors for the v2 speci= fication. New errors only come from extensions and must be defined in that = context.

 

I have applied to changes to the -14 draft and clearly mar= ked them with [[Pending Consensus]] so that there is no issue with removing= them or changing them later.

&n= bsp;

---

 

Add to the error codes li= st in sections 4.1.2.1 and 4.2.2.1:

<= o:p> 

      &n= bsp;  a 4xx or 5xx HTTP status code (except for 400 and 401)

       &nbs= p;       The authorization server MAY set the= "error" parameter

 &n= bsp;            = ; value to a numerical HTTP status code from the 4xx or 5xx

        &nbs= p;      range, with the exception of the 400 (Bad = Request) and

    =            401 (Unauthori= zed) status codes.  For example, if the

           =     service is temporarily unavailable, the authorization

      &nb= sp;        server MAY return an error re= sponse with "error" set to

=             &nb= sp;  "503".

 

 

Add a new section 8.4:

 

8.4.  Defining Add=
itional Error Codes
 
  =
; In cases where protocol extensions (i.e. access token types,
   extension paramete=
rs, or extension grant types) require additional
   error codes to be used with the = authorization code grant error
   response (Section 4.1.2.1), the implicit grant err=
or response
 &=
nbsp; (Section 4.2.2.1), or the token error response (Section 5.2), such
   error co=
des MAY be defined.
 
  =
; Extension error codes MUST be registered (following the procedures in
   Section 1=
0.3) if the extension they are used in conjunction with is
   registered.  Addi=
tional error codes used with unregistered extensions
   MAY be registered.
 
   Error codes MUST conform to=
 the error-code ABNF, and SHOULD be
   prefixed by an identifying name when possible=
.  For example, an error
   identifying an invalid value set to the extension p=
arameter "example"
   should be named "example_invalid".
 
 
     error-code   =
=3D ALPHA *error-char
     error-char   =3D "-" / &quo=
t;." / "_" / DIGIT / ALPHA
 
 
Add a new section 10.3:
 
10.=
3.  The OAuth Extensions Error Registry
 
   This specification establishes the OAuth extensi=
ons error registry.
 
  =
; Additional error codes used together with other protocol extensions<=
/o:p>
   (i.e. exten=
sion grant types, access token types, or extension
<=
pre>   parameters) are registered on =
the advice of one or more Designated
   Experts (appointed by the IESG or their dele=
gate), with a
 =
;  Specification Required (using terminology from [RFC5226]).  Ho=
wever,
  =
 to allow for the allocation of values prior to publication, the=

   Designated Exper=
t(s) may approve registration once they are satisfied
   that such a specification w=
ill be published.
<=
o:p> 
   =
Registration requests should be sent to the [TBD]@ietf.org mailing
   list for revie=
w and comment, with an appropriate subject (e.g.,
   "Request for error code: e=
xample"). [[ Note to RFC-EDITOR: The name
=
   of the mailing list should be dete=
rmined in consultation with the
   IESG and IANA.  Suggested name: oauth-ext-re=
view. ]]
 =
;
   Within at=
 most 14 days of the request, the Designated Expert(s) will
   either approve or den=
y the registration request, communicating this
=
   decision to the review list and IA=
NA.  Denials should include an
   explanation and, if applicable, suggestions a=
s to how to make the
   request successful.
 
   Decisions (or lack thereof) made by the Designated Expert=
 can be
  =
; first appealed to Application Area Directors (contactable using
   app-ads@tools.ietf.org email address or dire=
ctly by looking up their
   email addresses on http=
://www.iesg.org/ website) and, if the
   appellant is not satisfied with the res=
ponse, to the full IESG (using
   the iesg@iesg.org=
 mailing list).
 
  =
; IANA should only accept registry updates from the Designated
   Expert(s), and sho=
uld direct all requests for registration to the
   review mailing list.
 
<=
pre>10.3.1.  Registration Template
 
   Error name:
      T=
he name requested (e.g., "example").
=
   Error usage location:
      =
The location(s) where the error can be used.  The possible<=
/span>
     =
 locations are: authorization code grant error response
      (Sectio=
n 4.1.2.1), implicit grant error response
      (Section 4.2.2.1), or=
 token error response (Section 5.2).
   Related protocol extension:
      The =
name of the extension grant type, access token type, or
      extensi=
on parameter, the error code is used in conjunction with.=

   Change controller:=

    =
;  For standards-track RFCs, state "IETF".  For others,=
 give the name
&nbs=
p;     of the responsible party.  Other details (e=
.g., postal address,
      e-mail address, home page URI) may also be=
 included.
  &=
nbsp;Specification document(s):
      Reference to document that spec=
ifies the error code, preferably
      including a URI that can be us=
ed to retrieve a copy of the
      document.  An indication of t=
he relevant sections may also be
      included, but is not required.=

 
 
= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E298P3PW5EX1MB01E_-- From wmills@yahoo-inc.com Thu Apr 7 12:18:48 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF0528C107 for ; Thu, 7 Apr 2011 12:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfrimgQ77pKp for ; Thu, 7 Apr 2011 12:18:44 -0700 (PDT) Received: from web32314.mail.mud.yahoo.com (web32314.mail.mud.yahoo.com [68.142.207.162]) by core3.amsl.com (Postfix) with SMTP id 61E4C3A6957 for ; Thu, 7 Apr 2011 12:18:44 -0700 (PDT) Received: (qmail 90754 invoked by uid 60001); 7 Apr 2011 19:20:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302204023; bh=fyGMJxvTBD0CKLF6KvM8XSW944TFJUkbPIkMxJ7RL18=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=QrpX/cvegfRMKW3ENbpcO0+5DAjPEFk5EX0EbSWe19ION5ySwm7cVMGlxQBSsTEs3zoFSBu1GYU3TAxofdkbQiCmcETdgUnp9gGP5qZswjLgw0M1lsBCz9Y0SCVBa2Yb1crodMIv2WJBWU/4IlbpMWeFDYZ+6ltSvqNEfo+YhzA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=mPNrnZyxoa3u3h5cluCt9AorrRKuWBCafwPPqO56Rc/hIZTMlU23Xtmq5M3NQsgI7Pc7jI4OHPTHDYKD56R0D7DluQBuPAwAphHyaN6kWdJBoS9E/FmnQ0YRDrwX0IbsfxAbE7zpIO3CV84h6Vr43Q8X3sTH9jUoVzf41HNCbjA=; Message-ID: <894903.90028.qm@web32314.mail.mud.yahoo.com> X-YMail-OSG: QUBZmxsVM1mdOqQ7In_O8Pv2kg60Sg5bkPkjuGq1GETir4W i8s4- Received: from [216.145.52.206] by web32314.mail.mud.yahoo.com via HTTP; Thu, 07 Apr 2011 12:20:23 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <4E1F6AAD24975D4BA5B1680429673943252D0AF8@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E298@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 7 Apr 2011 12:20:23 -0700 (PDT) From: "William J. Mills" To: Eran Hammer-Lahav , Mike Jones , OAuth WG In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664E298@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-949964989-1302204023=:90028" Subject: Re: [OAUTH-WG] In the spirit of compromise X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 19:18:48 -0000 --0-949964989-1302204023=:90028 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable For HTTP authentication things, is the right place to simple define a new H= TTP status code that does what we need?=C2=A0 There is already a registry f= or that and the "slow down" example is one that might make sense in the mor= e general HTTP context.=0A=0A=0A=0A________________________________=0AFrom:= Eran Hammer-Lahav =0ATo: Mike Jones ; OAuth WG =0ASent: Thursday, April 7, 2011 11:= 20 AM=0ASubject: Re: [OAUTH-WG] In the spirit of compromise=0A=0A=0AHi Mike= ,=0A=C2=A0=0AI don=E2=80=99t think this is a matter of each one giving up s= omething.=0A=C2=A0=0AI have significant technical reasons for my position, = and I am much more interested in taking the time discussing these than just= finding an easy way to close issues. There is no reason to expect a thorou= gh discussion taking more than a week or two, which will still be faster th= an the time it will take to finish review on the security considerations se= ction.=0A=C2=A0=0AAdding an error registry for error codes used by the vari= ous HTTP authentication schemes for use in 401 responses in the WWW-Authent= icate header does not make technical sense for the v2 specification as it c= urrently stand. It would only make sense if we were to define a master HTTP= authentication scheme called OAuth2 (or similar) and require that every ne= w token type uses that scheme with a sub-scheme. Then, such an error regist= ry will make sense.=0A=C2=A0=0AFor example:=0A=C2=A0=0AAuthorization: OAuth= 2 type=3D=E2=80=9Dbearer=E2=80=9D, token=3D=E2=80=9Dasdalsijdlkasjd=E2=80= =9D=0AAuthorization: OAuth2 type=3D=E2=80=9Dmac=E2=80=9D, id=3D=E2=80=9Dasd= asdasd=E2=80=9D, etc=E2=80=A6=0A=C2=A0=0AIf you have use cases and requirem= ents for introducing such a new master HTTP authentication scheme, please p= resent them and we will have a discussion about how to best address them, i= ncluding the possibility of adding such a scheme. In the past, such a propo= sal was rejected due to lack of working group consensus. If I recall correc= tly, only Marius was advocating that approach.=0A=C2=A0=0AAlternatively, if= you have use cases or requirements for introducing just the WWW-Authentica= te side of an OAuth2 authorization scheme (your open issue), which includes= an =E2=80=98error=E2=80=99 attribute for use with the proposed registry, p= lease present those and explain how it will work alongside the Bearer and M= AC schemes (as currently drafted).=0A=C2=A0=0AThanks,=0A=C2=A0=0AEHL=0A=C2= =A0=0A=C2=A0=0AFrom:Mike Jones [mailto:Michael.Jones@microsoft.com] =0ASent= : Thursday, April 07, 2011 9:53 AM=0ATo: Eran Hammer-Lahav; OAuth WG=0ASubj= ect: In the spirit of compromise=0A=C2=A0=0AHaving thought about it over ni= ght and discussed it, I=E2=80=99m willing to drop my objection the WWW-Auth= enticate response not being in the framework specification, so as to close = an open issue that could delay completion of the specifications.=0A=C2=A0= =0AEran, in return, I=E2=80=99d like to ask you to drop your objection to e= xtending the error registry in the framework spec so that =E2=80=9Cresource= server error response=E2=80=9D is in the =E2=80=9Cerror usage location=E2= =80=9D list.=C2=A0 If you do so, this would close another open issue that c= ould delay completion of the specifications.=0A=C2=A0=0A=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thank you,=0A=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike=0A=C2=A0=0AFrom:Eran Hammer-Lahav [mailto:eran@hueniverse.com] =0A= Sent: Wednesday, April 06, 2011 4:35 PM=0ATo: Mike Jones; OAuth WG=0ASubjec= t: OAuth2 scheme (was Error registry proposal (round 3))=0A=C2=A0=0AWell=E2= =80=A6 Can=E2=80=99t say I didn=E2=80=99t see this coming J=0A=C2=A0=0AThe = issue is not simply about putting a section back, but about the overall pro= tocol architecture and how it complies with HTTP.=0A=C2=A0=0AFor example, t= aking the MAC draft, how do you envision the resource server responding to = a failed authentication attempt? A 401 response and what header(s)? WWW-Aut= henticate with =E2=80=98OAuth2=E2=80=99 scheme? =E2=80=98MAC=E2=80=99 schem= e? Both?=0A=C2=A0=0AAlso see: http://trac.tools.ietf.org/wg/httpbis/trac/ti= cket/78=0A=C2=A0=0AYou might think you are asking for a simple feature, but= this is moving the protocol from a purely authorization protocol to an aut= hentication protocol which is what the split of the token types was designe= d to accomplish.=0A=C2=A0=0AWhat I am asking for is to provide full example= s of how you envision the OAuth2 scheme to work in practice, especially con= sidering the MAC draft. Assume that the MAC draft, since it is defined as a= general purpose scheme, is not going to change (for the sake of argument o= nly), do you envision it being used differently when combines with an OAuth= access token? That would be bad.=0A=C2=A0=0AI removed the WWW-Authenticate= header and the OAuth2 scheme because it served no purpose and no one demon= strated how it will be actually used. WRAP is not a good example because WR= AP is a closed protocol (just like OAuth 1.0). There is no way to add new a= uthentication schemes to WRAP and in that context, it makes sense to define= a scheme. But here it will mean moving backwards to a protocol where only = OAuth-specific authentication schemes can be used, and they all must be def= ined as extensions of this master OAuth2 scheme.=0A=C2=A0=0AThere was prett= y good consensus not to define a master scheme with sub schemes. That is we= ll documented on the list. This thread included the discussion about using = a common prefix for scheme names, etc. Hope we don=E2=80=99t have to repeat= that.=0A=C2=A0=0ASo if OAuth2 is not a master scheme for all other scheme = to be defined as sub-schemes, what is it? I don=E2=80=99t have an answer an= d we kinda need one to put such a scheme back in the document.=0A=C2=A0=0AE= HL=0A=C2=A0=0AFrom:Mike Jones [mailto:Michael.Jones@microsoft.com] =0ASent:= Wednesday, April 06, 2011 4:13 PM=0ATo: Eran Hammer-Lahav; OAuth WG=0ASubj= ect: RE: Error registry proposal (round 3)=0A=C2=A0=0AActually, you correct= ly point out (indirectly), that this is related to one of the open issues t= hat needs to be resolved to complete the specs when you wrote =E2=80=9CFor = such a registry to be useful, you also need to standardize the authenticati= on header across all schemes and define a standard parameter used to delive= r such error codes=E2=80=9D.=0A=C2=A0=0AThis open issue (which there wasn= =E2=80=99t time to discuss during last week=E2=80=99s meeting) was the remo= val of the WWW-Authenticate Response Header. =C2=A0This feature was present= in WRAP and earlier OAuth drafts but was removed without a clear consensus= to do so.=C2=A0 And indeed, during our private discussions on how the draf= t should be split, at that time, you took the position that the WWW-Authent= icate response should remain in the framework spec.=0A=C2=A0=0AThe result h= as been that there is different and incompatible WWW-Authenticate response = functionality in multiple related drafts =E2=80=93 specifically draft-hamme= r-oauth-v2-mac-token-02 and draft-ietf-oauth-v2-bearer-04.=C2=A0 Interopera= bility and developers would both be better served by moving this functional= ity back into the core. I don=E2=80=99t believe that each related OAuth spe= cification should have to separately specify this functionality.=C2=A0 As t= his was not discussed during last week=E2=80=99s meeting, a consensus call = from the chairs may be necessary to resolve this issue.=0A=C2=A0=0A=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --= Mike=0A=C2=A0=0AFrom:Eran Hammer-Lahav [mailto:eran@hueniverse.com] =0ASen= t: Wednesday, April 06, 2011 3:58 PM=0ATo: Mike Jones; OAuth WG=0ASubject: = RE: Error registry proposal (round 3)=0A=C2=A0=0APutting aside my view that= a registry for resource server error responses across HTTP authentication = schemes isn=E2=80=99t very useful or interesting, I don=E2=80=99t have an o= bjection to the bearer token specification defining such general purpose re= gistry. In a way, it is similar to the error response headers defined by Di= gest, only never made generally applicable.=0A=C2=A0=0AThe difference in ou= r approaches is that I don=E2=80=99t consider the bearer token or mac token= specs to be extensions of the v2 spec, but fully specified HTTP authentica= tion schemes with OAuth 2.0 binding (i.e. the access token type registratio= n). Because of that, I don=E2=80=99t think the v2 spec is the right place f= or such a registry, which is really about HTTP authentication schemes and n= ot OAuth. Therefore, I think it will be more confusing to put such a regist= ry in v2.=0A=C2=A0=0AI=E2=80=99ll give you an example. Suppose someone will= define a Digest access token type. When issuing one, the server will send = an access token (to be used as username) and a secret (to be used as passwo= rd). To use such a token, the client will use the HTTP Digest scheme (as is= ). Digest defines its own set and method or specifying error code. Would yo= u expect those to be registered in your proposed registry? I would assume n= ot.=0A=C2=A0=0AFor such a registry to be useful, you also need to standardi= ze the authentication header across all schemes and define a standard param= eter used to deliver such error codes. However, we already moved away from = that design by defining separate HTTP authentication schemes for each token= type.=0A=C2=A0=0ABut again, I don=E2=80=99t have an objection to such a re= gistry defined in the bearer token spec. I have no intentions of using it f= or any HTTP authentication scheme I plan to author.=0A=C2=A0=0AEHL=0A=C2=A0= =0A=C2=A0=0A=C2=A0=0A=C2=A0=0A=C2=A0=0AFrom:Mike Jones [mailto:Michael.Jone= s@microsoft.com] =0ASent: Wednesday, April 06, 2011 3:39 PM=0ATo: Eran Hamm= er-Lahav; OAuth WG=0ASubject: RE: Error registry proposal (round 3)=0A=C2= =A0=0AThe problem with that situation is that it doesn=E2=80=99t provide a = central registry for resource server error responses across specs, unlike t= he other kinds of OAuth error responses.=C2=A0 I could define that registry= in the bearer token spec, but it would be less confusing to unify it with = the proposed registry in the framework spec.=C2=A0 I suspect developers wou= ld thank us for doing that.=0A=C2=A0=0AWhat do you say?=0A=C2=A0=0A=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --= Mike=0A=C2=A0=0AFrom:Eran Hammer-Lahav [mailto:eran@hueniverse.com] =0ASen= t: Wednesday, April 06, 2011 2:58 PM=0ATo: Mike Jones; OAuth WG=0ASubject: = RE: Error registry proposal (round 3)=0A=C2=A0=0AHi Mike,=0A=C2=A0=0AThis i= s intentional. The error registry defined in v2 is not designed to record e= rrors for the protected resource endpoint response or the WWW-Authenticate = response header when used with the Bearer token scheme (or any other scheme= ).=0A=C2=A0=0AThe only purpose of the registry is to avoid name collisions = between two errors used differently with the v2 specification. Since errors= used with the Bearer token scheme will never appear in the same place as t= he v2 endpoints, there is no need for combining these two registries.=0A=C2= =A0=0AIf the bearer token specification requires error extensibility, you s= hould retain the registry there and limit it to just the protected resource= response space. Ideally, you would limit it to just the WWW-Authenticate h= eader =E2=80=98error=E2=80=99 parameter when used with the Bearer scheme. T= he MAC scheme does not use error codes, but instead, relies fully on HTTP s= tatus code since no additional error conditions were identified.=0A=C2=A0= =0AAlso, since your ABNF permits adding additional Authorization header par= ameters, you might want to consider defining a process for doing that, if y= ou are going to define an error registry. Currently, to add additional para= meters, one has to update the Bearer token RFC, in contrast to simply regis= tering a new error code (which is likely to come out of a new parameter).= =0A=C2=A0=0AEHL=0A=C2=A0=0A=C2=A0=0AFrom:Mike Jones [mailto:Michael.Jones@m= icrosoft.com] =0ASent: Wednesday, April 06, 2011 2:25 PM=0ATo: Eran Hammer-= Lahav; OAuth WG=0ASubject: RE: Error registry proposal (round 3)=0A=C2=A0= =0AThanks for writing this up, Eran.=C2=A0 I believe that this is a step in= the right direction.=0A=C2=A0=0AWearing my Bearer Token spec editor hat, I= just tried to go through the exercise of editing my document to use the re= gistry in draft 15 to register the errors defined in the bearer token spec = and I hit a roadblock.=C2=A0 Specifically, while the errors defined by my s= pec are returned by resource servers (flow F in Figure 1), the registry def= ined by draft 15 does not include =E2=80=9Cresource server error response= =E2=80=9D in the =E2=80=9Cerror usage location=E2=80=9D list.=C2=A0 Can you= please add this additional error usage location so that the registry can b= e used by the bearer token specification?=0A=C2=A0=0AAt that point, I belie= ve we=E2=80=99ll be able to close the open issue about the need for an erro= r registry, and I=E2=80=99ll update my draft accordingly.=0A=C2=A0=0A=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Th= ank you,=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 -- Mike=0A=C2=A0=0AFrom:oauth-bounces@ietf.org [mailto:oaut= h-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav=0ASent: Tuesday, April 0= 5, 2011 3:52 PM=0ATo: OAuth WG=0ASubject: [OAUTH-WG] Error registry proposa= l (round 3)=0A=C2=A0=0AThe following is my new proposal, based on Mike Jone= s=E2=80=99 and my earlier proposals. It is basically a combination of the t= wo.=0A=C2=A0=0AThis proposal does not allow defining new error codes unless= another extension is involved (new grant type, request parameter, token ty= pe). The reason for not defining an open ended error registry is that defin= ing new error codes for existing implementations is bad for interoperabilit= y and can lead to unexpected results (developers not taking into account re= ceiving a new error when talking to a compliant 2.0 server). We don't have = any use cases for defining such new errors for the v2 specification. New er= rors only come from extensions and must be defined in that context.=0A=C2= =A0=0AI have applied to changes to the -14 draft and clearly marked them wi= th [[Pending Consensus]] so that there is no issue with removing them or ch= anging them later.=0A=C2=A0=0A---=0A=C2=A0=0AAdd to the error codes list in= sections 4.1.2.1 and 4.2.2.1:=0A=C2=A0=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 a 4xx or 5xx HTTP status code (except for 400 and 401)=0A= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 The authorization server MAY set the "error" parameter=0A=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 value to a numerical HTTP status code from the 4xx or 5xx=0A=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= range, with the exception of the 400 (Bad Request) and=0A=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 401 (= Unauthorized) status codes.=C2=A0 For example, if the=0A=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 service = is temporarily unavailable, the authorization=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server MAY return= an error response with "error" set to=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "503".=0A=C2=A0=0A=C2= =A0=0AAdd a new section 8.4:=0A=C2=A0=0A8.4.=C2=A0 Defining Additional Erro= r Codes=0A=C2=A0=0A=C2=A0=C2=A0 In cases where protocol extensions (i.e. ac= cess token types,=0A=C2=A0=C2=A0 extension parameters, or extension grant t= ypes) require additional=0A=C2=A0=C2=A0 error codes to be used with the aut= horization code grant error=0A=C2=A0=C2=A0 response (Section 4.1.2.1), the = implicit grant error response=0A=C2=A0=C2=A0 (Section 4.2.2.1), or the toke= n error response (Section 5.2), such=0A=C2=A0=C2=A0 error codes MAY be defi= ned.=0A=C2=A0=0A=C2=A0=C2=A0 Extension error codes MUST be registered (foll= owing the procedures in=0A=C2=A0=C2=A0 Section 10.3) if the extension they = are used in conjunction with is=0A=C2=A0=C2=A0 registered.=C2=A0 Additional= error codes used with unregistered extensions=0A=C2=A0=C2=A0 MAY be regist= ered.=0A=C2=A0=0A=C2=A0=C2=A0 Error codes MUST conform to the error-code AB= NF, and SHOULD be=0A=C2=A0=C2=A0 prefixed by an identifying name when possi= ble.=C2=A0 For example, an error=0A=C2=A0=C2=A0 identifying an invalid valu= e set to the extension parameter "example"=0A=C2=A0=C2=A0 should be named "= example_invalid".=0A=C2=A0=0A=C2=A0=0A=C2=A0=C2=A0=C2=A0=C2=A0 error-code= =C2=A0=C2=A0 =3D ALPHA *error-char=0A=C2=A0=C2=A0=C2=A0=C2=A0 error-char=C2= =A0=C2=A0 =3D "-" / "." / "_" / DIGIT / ALPHA=0A=C2=A0=0A=C2=A0=0AAdd a new= section 10.3:=0A=C2=A0=0A10.3.=C2=A0 The OAuth Extensions Error Registry= =0A=C2=A0=0A=C2=A0=C2=A0 This specification establishes the OAuth extension= s error registry.=0A=C2=A0=0A=C2=A0=C2=A0 Additional error codes used toget= her with other protocol extensions=0A=C2=A0=C2=A0 (i.e. extension grant typ= es, access token types, or extension=0A=C2=A0=C2=A0 parameters) are registe= red on the advice of one or more Designated=0A=C2=A0=C2=A0 Experts (appoint= ed by the IESG or their delegate), with a=0A=C2=A0=C2=A0 Specification Requ= ired (using terminology from [RFC5226]).=C2=A0 However,=0A=C2=A0=C2=A0 to a= llow for the allocation of values prior to publication, the=0A=C2=A0=C2=A0 = Designated Expert(s) may approve registration once they are satisfied=0A=C2= =A0=C2=A0 that such a specification will be published.=0A=C2=A0=0A=C2=A0=C2= =A0 Registration requests should be sent to the [TBD]@ietf.org mailing=0A= =C2=A0=C2=A0 list for review and comment, with an appropriate subject (e.g.= ,=0A=C2=A0=C2=A0 "Request for error code: example"). [[ Note to RFC-EDITOR:= The name=0A=C2=A0=C2=A0 of the mailing list should be determined in consul= tation with the=0A=C2=A0=C2=A0 IESG and IANA.=C2=A0 Suggested name: oauth-e= xt-review. ]]=0A=C2=A0=0A=C2=A0=C2=A0 Within at most 14 days of the request= , the Designated Expert(s) will=0A=C2=A0=C2=A0 either approve or deny the r= egistration request, communicating this=0A=C2=A0=C2=A0 decision to the revi= ew list and IANA.=C2=A0 Denials should include an=0A=C2=A0=C2=A0 explanatio= n and, if applicable, suggestions as to how to make the=0A=C2=A0=C2=A0 requ= est successful.=0A=C2=A0=0A=C2=A0=C2=A0 Decisions (or lack thereof) made by= the Designated Expert can be=0A=C2=A0=C2=A0 first appealed to Application = Area Directors (contactable using=0A=C2=A0=C2=A0 app-ads@tools.ietf.org ema= il address or directly by looking up their=0A=C2=A0=C2=A0 email addresses o= n http://www.iesg.org/ website) and, if the=0A=C2=A0=C2=A0 appellant is not= satisfied with the response, to the full IESG (using=0A=C2=A0=C2=A0 the ie= sg@iesg.org mailing list).=0A=C2=A0=0A=C2=A0=C2=A0 IANA should only accept = registry updates from the Designated=0A=C2=A0=C2=A0 Expert(s), and should d= irect all requests for registration to the=0A=C2=A0=C2=A0 review mailing li= st.=0A=C2=A0=0A10.3.1.=C2=A0 Registration Template=0A=C2=A0=0A=C2=A0=C2=A0 = Error name:=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The name requested (e.g., "exa= mple").=0A=C2=A0=C2=A0 Error usage location:=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 The location(s) where the error can be used.=C2=A0 The possible=0A=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 locations are: authorization code grant error r= esponse=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(Section 4.1.2.1), implicit grant e= rror response=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (Section 4.2.2.1), or token = error response (Section 5.2).=0A=C2=A0=C2=A0 Related protocol extension:=0A= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The name of the extension grant type, access= token type, or=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 extension parameter, the e= rror code is used in conjunction with.=0A=C2=A0=C2=A0 Change controller:=0A= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For standards-track RFCs, state "IETF".=C2= =A0 For others, give the name=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the respo= nsible party.=C2=A0 Other details (e.g., postal address,=0A=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 e-mail address, home page URI) may also be included.=0A=C2= =A0 =C2=A0Specification document(s):=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Refer= ence to document that specifies the error code, preferably=0A=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 including a URI that can be used to retrieve a copy of t= he=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document.=C2=A0 An indication of the re= levant sections may also be=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 included, but = is not required.=0A=C2=A0=0A=C2=A0=0A______________________________________= _________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mail= man/listinfo/oauth --0-949964989-1302204023=:90028 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
For HTTP authentication things, is the right place to simple define a new= HTTP status code that does what we need?  There is already a registry= for that and the "slow down" example is one that might make sense in the m= ore general HTTP context.

From: Eran Hammer-Lahav <eran@hueniverse.c= om>
To: Mike Jones &= lt;Michael.Jones@microsoft.com>; OAuth WG <oauth@ietf.org>
<= span style=3D"font-weight: bold;">Sent: Thursday, April 7, 2011 = 11:20 AM
Subject: Re: [OAUTH= -WG] In the spirit of compromise

=0A
=
<= span style=3D"color: rgb(31, 73, 125);">Hi Mike,
 
I don=E2=80=99t think this is a matter of each one giving up so= mething.
 
I have significant technical= reasons for my position, and I am much more interested in taking the time = discussing these than just finding an easy way to close issues. There is no= reason to expect a thorough discussion taking more than a week or two, whi= ch will still be faster than the time it will take to finish review on the = security considerations section.
=  
Adding an error registry for error codes used by the = various HTTP authentication schemes for use in 401 responses in the WWW-Aut= henticate header does not make technical sense for the v2 specification as = it currently stand. It would only make sense if we were to define a master = HTTP authentication scheme called OAuth2 (or similar) and require that ever= y new token type uses that scheme with a sub-scheme. Then, such an error re= gistry will make sense.
 
For example:<= /span>
 
Authorization: OAuth2 type=3D=E2=80=9Db= earer=E2=80=9D, token=3D=E2=80=9Dasdalsijdlkasjd=E2=80=9D
Au= thorization: OAuth2 type=3D=E2=80=9Dmac=E2=80=9D, id=3D=E2=80=9Dasdasdasd= =E2=80=9D, etc=E2=80=A6
 
If you have u= se cases and requirements for introducing such a new master HTTP authentica= tion scheme, please present them and we will have a discussion about how to= best address them, including the possibility of adding such a scheme. In t= he past, such a proposal was rejected due to lack of working group consensu= s. If I recall correctly, only Marius was advocating that approach.<= /div>
 
Alternatively, if you have use cases or= requirements for introducing just the WWW-Authenticate side of an OAuth2 a= uthorization scheme (your open issue), which includes an =E2=80=98error=E2= =80=99 attribute for use with the proposed registry, please present those a= nd explain how it will work alongside the Bearer and MAC schemes (as curren= tly drafted).
 
Thanks,
 
EHL
 
 =
From:<= /b> M= ike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, A= pril 07, 2011 9:53 AM
To: Eran Hammer-Lahav; OAuth WG
Subje= ct: In the spirit of compromise
 
Having thought about it over night and = discussed it, I=E2=80=99m willing to drop my objection the WWW-Authenticate response= not being in the framework specification, so as to close an open issue tha= t could delay completion of the specifications.
 =
Eran, in return, I=E2=80=99d like to ask you to drop your objection = to extending the error registry in the framework spec so that =E2=80=9Creso= urce server error response=E2=80=9D is in the =E2=80=9Cerror usage location= =E2=80=9D list.  If you do so, this would close another open issue tha= t could delay completion of the specifications.
 =
           &n= bsp;            = ;            &n= bsp;            &nbs= p;            &= nbsp; Thank you,
       &nb= sp;            =             &nb= sp;            =             &nb= sp;      -- Mike
 
From: Eran Hammer-Lahav [mailto:= eran@hueniverse.com]
Sent: Wednesday, April 06, 2011 4:35 PM
= To: Mike Jones; OAuth WG
Subject: OAuth2 scheme (was Error= registry proposal (round 3))
 
Well=E2=80=A6 Can=E2=80=99t say I didn=E2= =80=99t see this coming J
=  
The issue is not simply about putting a section back,= but about the overall protocol architecture and how it complies with HTTP.=
 
For example, taking the MAC draft, h= ow do you envision the resource server responding to a failed authenticatio= n attempt? A 401 response and what header(s)? WWW-Authenticate with =E2=80= =98OAuth2=E2=80=99 scheme? =E2=80=98MAC=E2=80=99 scheme? Both?
=
 
Also see: http://trac.tools.ietf.org/wg/httpbis/t= rac/ticket/78
=  
You might think you are asking for a simple feature, = but this is moving the protocol from a purely authorization protocol to an = authentication protocol which is what the split of the token types was desi= gned to accomplish.
 
What I am asking = for is to provide full examples of how you envision the OAuth2 scheme to wo= rk in practice, especially considering the MAC draft. Assume that the MAC d= raft, since it is defined as a general purpose scheme, is not going to chan= ge (for the sake of argument only), do you envision it being used different= ly when combines with an OAuth access token? That would be bad.
=  
I removed the WWW-Authenticate header and the OAuth2 = scheme because it served no purpose and no one demonstrated how it will be = actually used. WRAP is not a good example because WRAP is a closed protocol= (just like OAuth 1.0). There is no way to add new authentication schemes t= o WRAP and in that context, it makes sense to define a scheme. But here it = will mean moving backwards to a protocol where only OAuth-specific authenti= cation schemes can be used, and they all must be defined as extensions of t= his master OAuth2 scheme.
=  
There was p= retty good consensus not to define a master scheme with sub schemes. That i= s well documented on the list. This thread included the discussion about using a = common prefix for scheme names, etc. Hope we don=E2=80=99t have to repeat t= hat.
 
So if OAuth2 is not a master sch= eme for all other scheme to be defined as sub-schemes, what is it? I don=E2= =80=99t have an answer and we kinda need one to put such a scheme back in t= he document.
 
EHL
&n= bsp;
From= : Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: We= dnesday, April 06, 2011 4:13 PM
To: Eran Hammer-Lahav; OAuth WGSubject: RE: Error registry proposal (round 3)
<= /div>
 
Actually, you corre= ctly point out (indirectly), that this is related to one of the open issues= that needs to be resolved to complete the specs when you wrote =E2=80=9CFor such a registry to be useful, you a= lso need to standardize the authentication header across all schemes and de= fine a standard parameter used to deliver such error codes=E2=80=9D.
 
T= his open issue (which there wasn=E2=80=99t time to discuss during last week= =E2=80=99s meeting) was the removal of the WWW-Authenticate Response Header= .  This feature was present in WRAP and earlier OAuth drafts but was r= emoved without a clear consensus to do so.  And indeed, during our pri= vate discussions on how the draft should be split, at that time, you took t= he position that the WWW-Authenticate response should remain in the framewo= rk spec.
 
The result has been that there is different and incomp= atible WWW-Authenticate response functionality in multiple related drafts = =E2=80=93 specifically draft-hammer-oauth-v2-mac-token-02 and draft-ietf-oa= uth-v2-bearer-04.  Interoperability and developers would both be bette= r served by moving this functionality back into the core. I don=E2=80=99t b= elieve that each related OAuth specification should have to separately spec= ify this functionality.  As this was not discussed during last week=E2= =80=99s meeting, a consensus call from the chairs may be necessary to resol= ve this issue.
 
           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  -- Mike
 
<= span style=3D"font-size: 10pt; font-family: "sans-serif";">From:<= /span> Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Wedne= sday, April 06, 2011 3:58 PM
To: Mike Jones; OAuth WG
Subject: RE: Error registry proposal (round 3)
 
Putting aside my view that a reg= istry for resource server error responses across HTTP authentication scheme= s isn=E2=80=99t very useful or interesting, I don=E2=80=99t have an objecti= on to the bearer token specification defining such general purpose registry= . In a way, it is similar to the error response headers defined by Digest, = only never made generally applicable.
 
The difference in our approaches is that I don=E2=80=99t consider the bear= er token or mac token specs to be extensions of the v2 spec, but fully spec= ified HTTP authentication schemes with OAuth 2.0 binding (i.e. the access token type registration). = Because of that, I don=E2=80=99t think the v2 spec is the right place for s= uch a registry, which is really about HTTP authentication schemes and not O= Auth. Therefore, I think it will be more confusing to put such a registry i= n v2.
 
I=E2=80=99ll give you an exampl= e. Suppose someone will define a Digest access token type. When issuing one= , the server will send an access token (to be used as username) and a secre= t (to be used as password). To use such a token, the client will use the HT= TP Digest scheme (as is). Digest defines its own set and method or specifyi= ng error code. Would you expect those to be registered in your proposed reg= istry? I would assume not.
 
For such a regis= try to be useful, you also need to standardize the authentication header ac= ross all schemes and define a standard parameter used to deliver such error= codes. However, we already moved away from that design by defining separat= e HTTP authentication schemes for each token type.
 =
But again, I don=E2=80=99t have an objection to such a regi= stry defined in the bearer token spec. I have no intentions of using it for= any HTTP authentication scheme I plan to author.
 
EHL
 
 
&= nbsp;
 
 
From: Mike Jones [mailto:Micha= el.Jones@microsoft.com]
Sent: Wednesday, April 06, 2011 3:39 PM<= br>To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error regi= stry proposal (round 3)
 
The problem with that situation is that it doesn=E2= =80=99t provide a central registry for resource server error responses acro= ss specs, unlike the other kinds of OAuth error responses.  I could de= fine that registry in the bearer token spec, but it would be less confusing= to unify it with the proposed registry in the framework spec.  I susp= ect developers would thank us for doing that.
 
Wha= t do you say?
 
    &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         -- Mike
=  
From: Eran Hammer-Lahav [mailto:eran@h= ueniverse.com]
Sent: Wednesday, April 06, 2011 2:58 PM
To:= Mike Jones; OAuth WG
Subject: RE: Error registry proposal (r= ound 3)
 = ;
Hi Mike,
 
This is intentiona= l. The error registry defined in v2 is not designed to record errors for th= e protected resource endpoint response or the WWW-Authenticate response hea= der when used with the Bearer token scheme (or any other scheme).
=  
The only purpose of the registry is to avoid name col= lisions between two errors used differently with the v2 specification. Sinc= e errors used with the Bearer token scheme will never appear in the same pl= ace as the v2 endpoints, there is no need for combining these two registrie= s.
 
= If the bearer token specification = requires error extensibility, you should retain the registry there and limi= t it to just the protected resource response space. Ideally, you would limi= t it to just the WWW-Authenticate header =E2=80=98error=E2=80=99 parameter = when used with the Bearer scheme. The MAC scheme does not use error codes, = but instead, relies fully on HTTP status code since no additional error conditions were identi= fied.
 
Also, since your ABNF permits a= dding additional Authorization header parameters, you might want to conside= r defining a process for doing that, if you are going to define an error re= gistry. Currently, to add additional parameters, one has to update the Bear= er token RFC, in contrast to simply registering a new error code (which is = likely to come out of a new parameter).
 
=
EHL
 
 
From: Mike Jones [mai= lto:Michael.Jones@microsoft.com]
Sent: Wednesday, April 06, 2011= 2:25 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: E= rror registry proposal (round 3)
 
Thanks for writing this up, Eran.  I= believe that this is a step in the right direction.
 
Wearing my Bearer Token spec editor hat, I just tried to go thr= ough the exercise of editing my document to use the registry in draft 15 to= register the errors defined in the bearer token spec and I hit a roadblock= .  Specifically, while the errors defined by my spec are returned by r= esource servers (flow F in Figure 1), the registry defined by draft 15 does= not include =E2=80=9Cresource server error response=E2=80=9D in the =E2=80= =9Cerror usage location=E2=80=9D list.  Can you please add this additi= onal error usage location so that the registry can be used by the bearer to= ken specification?
 
At that point, I believe we=E2=80=99ll be able = to close the open issue about the need for an error registry, and I=E2=80= =99ll update my draft accordingly.
 
 =             &nb= sp;            =             &nb= sp;            =              Th= ank you,
           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  -- Mike
 
<= span style=3D"font-size: 10pt; font-family: "sans-serif";">From:<= /span> oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f Eran Hammer-Lahav
Sent: Tuesday, April 05, 2011 3:52 PM
<= b>To: OAuth WG
Subject: [OAUTH-WG] Error registry proposal (r= ound 3)
 = ;
The following is my new prop= osal, based on Mike Jones=E2=80=99 and my earlier proposals. It is basicall= y a combination of the two.
&= nbsp;
This proposal does not a= llow defining new error codes unless another extension is involved (new gra= nt type, request parameter, token type). The reason for not defining an ope= n ended error registry is that defining new error codes for existing implem= entations is bad for interoperability and can lead to unexpected results (d= evelopers not taking into account receiving a new error when talking to a c= ompliant 2.0 server). We don't have any use cases for defining such new err= ors for the v2 specification. New errors only come from extensions and must be def= ined in that context.
 <= /div>
I have applied to changes to t= he -14 draft and clearly marked them with [[Pending Consensus]] so that the= re is no issue with removing them or changing them later.
 
---
 
Add to the error codes list in sections = 4.1.2.1 and 4.2.2.1:
 
    =      a 4xx or 5xx HTTP status code (except for 400 and = 401)
   &nb= sp;           The authori= zation server MAY set the "error" parameter
        = ;       value to a numerical HTTP status code= from the 4xx or 5xx
           &nbs= p;   range, with the exception of the 400 (Bad Request) and
   &nb= sp;           401 (Unauthorized) status codes.  For example, if the
      = ;         service is temporarily un= available, the authorization
          &n= bsp;    server MAY return an error response with "error" set= to
  =              "5= 03".
 
 
Add a new section 8.4:
 
8.4.  Defining Additional Error Codes
  
&=
nbsp;  In cases where protocol extensions (i.e. access token types,
   extension paramet=
ers, or extension grant types) require additional
   error codes to be used with the authoriz=
ation code grant error
 =
;  response (Section 4.1.2.1), the implicit grant error response
   (Section 4.2.2.1), o=
r the token error response (Section 5.2), such
   error codes MAY be defined.
 
   Extension error codes MUST be registered (following the p=
rocedures in
   Se=
ction 10.3) if the extension they are used in conjunction with is
   registered.  Additi=
onal error codes used with unregistered extensions
   MAY be registered.
  
   Error codes MUST conform to the error-code ABNF, and SH=
OULD be
   prefixe=
d by an identifying name when possible.  For example, an error<=
/pre>
   identifying an invalid=
 value set to the extension parameter "example"
   should be named "example_invalid".
<=
span style=3D"color: black;">  
  
  =
;   error-code   =3D ALPHA *error-char
     error-char &nb=
sp; =3D "-" / "." / "_" / DIGIT / ALPHA
  
 &nbs=
p;
Add a new section 10.3:
  
10.3.  The OAuth Extensions Error Registry
=

  
   This specification establishes the OAuth extens=
ions error registry.

  
   Additio=
nal error codes used together with other protocol extensions
   (i.e. extension grant types, =
access token types, or extension
   parameters) are registered on the advice of one or more D=
esignated
   Exper=
ts (appointed by the IESG or their delegate), with a
   Specification Required (using termino=
logy from [RFC5226]).  However,
   to allow for the allocation of values prior to public=
ation, the
   Desi=
gnated Expert(s) may approve registration once they are satisfied
   that such a specificatio=
n will be
 published.
  
   Registration requests s=
hould be sent to the [TBD]@ietf.org mailing
   list for review and comment, with an appropria=
te subject (e.g.,
 &nbs=
p; "Request for error code: example"). [[ Note to RFC-EDITOR: The name
   of the mailing list=
 should be determined in consultation with the
   IESG and IANA.  Suggested name: oauth-=
ext-review. ]]
  
   Within at most 14 da=
ys of the request, the Designated Expert(s) will
   either approve or deny the registration r=
equest,
 communicating this
 &n=
bsp; decision to the review list and IANA.  Denials should include an<=
/span>
   explanation and=
, if applicable, suggestions as to how to make the
   request successful.
  
   Decisions (or lack thereof) made by the Designated Exp=
ert can be
   firs=
t appealed to Application Area Directors (contactable using
   app-ads@tools.ietf.org email address or directly by looki=
ng up their
   ema=
il addresses on
 http://www.iesg.org/ website) and, if the
   appellant is not satisfied with the response, t=
o the full IESG (using
 =
;  the iesg@iesg.org mailing list).
  
   IANA should only accept registry update=
s from the Designated
 =
  Expert(s), and should direct all requests for registration to the
   review mailing li=
st.
  
10.3.1.  Registration Template
  
   Error name:
      The name requested (e.g., "example").<=
/span>
   Error usage loc=
ation:
   &nb=
sp;  The location(s) where the error can be used.  The possible
     =
; locations are: authorization code grant error response
<=
span style=3D"color: black;">      (Section 4.1.2.=
1), implicit grant error response
      (Section 4.2.2.1), or token error resp=
onse (Section 5.2).
 &n=
bsp; Related protocol extension:
      The name of the extension grant type, a=
ccess
 token type, or
  =
    extension parameter, the error code is used in conjuncti=
on with.
   Change=
 controller:
  &nb=
sp;   For standards-track RFCs, state "IETF".  For others, g=
ive the name
  &nb=
sp;   of the responsible party.  Other details (e.g., postal=
 address,
   =
   e-mail address, home page URI) may also be included.
   Specification document(s=
):
    &=
nbsp; Reference to document that specifies the error code, preferably
      in=
cluding a
 URI that can be used to retrieve a copy of the
      document.  An indic=
ation of the relevant sections may also be
      included, but is not required=
.
  
  
=

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

--0-949964989-1302204023=:90028-- From eran@hueniverse.com Thu Apr 7 13:27:15 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CF33A6A24 for ; Thu, 7 Apr 2011 13:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+uLbaUexpy1 for ; Thu, 7 Apr 2011 13:27:12 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BF3383A697B for ; Thu, 7 Apr 2011 13:27:11 -0700 (PDT) Received: (qmail 20350 invoked from network); 7 Apr 2011 20:28:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Apr 2011 20:28:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 7 Apr 2011 13:28:46 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , Mike Jones , OAuth WG Date: Thu, 7 Apr 2011 13:28:38 -0700 Thread-Topic: [OAUTH-WG] In the spirit of compromise Thread-Index: Acv1WN9DPuKpBeprTVSdjtOUyNSrkgACQwEw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E320@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943252D0AF8@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E298@P3PW5EX1MB01.EX1.SECURESERVER.NET> <894903.90028.qm@web32314.mail.mud.yahoo.com> In-Reply-To: <894903.90028.qm@web32314.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664E320P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] In the spirit of compromise X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 20:27:15 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E320P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGV5IEJpbGwsDQoNCkl0IG1pZ2h0IGJlIGluIGdlbmVyYWwgZm9yIHNvbWUgZXJyb3IgY29uZGl0 aW9ucyAoc3VjaCBhcyBzbG93IGRvd24pLiBJIHRoaW5rIHRoZSBjdXJyZW50IHByb3Bvc2FsIG9m ZmVycyBhIGdvb2QgYmFsYW5jZSBiZXR3ZWVuIHJldXNpbmcgSFRUUCBjb2RlcyBhbmQgZGVmaW5p bmcgbW9yZSBkZXRhaWxlZCBlcnJvciBjb2RlcyBmb3IgdGhlIGNvbW1vbiA0MDEvNDAwIGVycm9y cy4NCg0KVGhlIGlzc3VlIGhlcmUgaXMgYWJvdXQgbmV3IEhUVFAgYXV0aGVudGljYXRpb24gc2No ZW1lcywgaG93IHRoZXkgcmVsYXRlIGJhY2sgdG8gT0F1dGgsIGFuZCBob3cgdGhleSBtaWdodCBz aGFyZSBlcnJvciBjb2Rlcy4NCg0KRUhMDQoNCkZyb206IFdpbGxpYW0gSi4gTWlsbHMgW21haWx0 bzp3bWlsbHNAeWFob28taW5jLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxMSAx MjoyMCBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBNaWtlIEpvbmVzOyBPQXV0aCBXRw0KU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gSW4gdGhlIHNwaXJpdCBvZiBjb21wcm9taXNlDQoNCkZvciBI VFRQIGF1dGhlbnRpY2F0aW9uIHRoaW5ncywgaXMgdGhlIHJpZ2h0IHBsYWNlIHRvIHNpbXBsZSBk ZWZpbmUgYSBuZXcgSFRUUCBzdGF0dXMgY29kZSB0aGF0IGRvZXMgd2hhdCB3ZSBuZWVkPyAgVGhl cmUgaXMgYWxyZWFkeSBhIHJlZ2lzdHJ5IGZvciB0aGF0IGFuZCB0aGUgInNsb3cgZG93biIgZXhh bXBsZSBpcyBvbmUgdGhhdCBtaWdodCBtYWtlIHNlbnNlIGluIHRoZSBtb3JlIGdlbmVyYWwgSFRU UCBjb250ZXh0Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogRXJh biBIYW1tZXItTGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5jb20+DQpUbzogTWlrZSBKb25lcyA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgT0F1dGggV0cgPG9hdXRoQGlldGYub3JnPg0KU2Vu dDogVGh1cnNkYXksIEFwcmlsIDcsIDIwMTEgMTE6MjAgQU0NClN1YmplY3Q6IFJlOiBbT0FVVEgt V0ddIEluIHRoZSBzcGlyaXQgb2YgY29tcHJvbWlzZQ0KSGkgTWlrZSwNCg0KSSBkb27igJl0IHRo aW5rIHRoaXMgaXMgYSBtYXR0ZXIgb2YgZWFjaCBvbmUgZ2l2aW5nIHVwIHNvbWV0aGluZy4NCg0K SSBoYXZlIHNpZ25pZmljYW50IHRlY2huaWNhbCByZWFzb25zIGZvciBteSBwb3NpdGlvbiwgYW5k IEkgYW0gbXVjaCBtb3JlIGludGVyZXN0ZWQgaW4gdGFraW5nIHRoZSB0aW1lIGRpc2N1c3Npbmcg dGhlc2UgdGhhbiBqdXN0IGZpbmRpbmcgYW4gZWFzeSB3YXkgdG8gY2xvc2UgaXNzdWVzLiBUaGVy ZSBpcyBubyByZWFzb24gdG8gZXhwZWN0IGEgdGhvcm91Z2ggZGlzY3Vzc2lvbiB0YWtpbmcgbW9y ZSB0aGFuIGEgd2VlayBvciB0d28sIHdoaWNoIHdpbGwgc3RpbGwgYmUgZmFzdGVyIHRoYW4gdGhl IHRpbWUgaXQgd2lsbCB0YWtlIHRvIGZpbmlzaCByZXZpZXcgb24gdGhlIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHNlY3Rpb24uDQoNCkFkZGluZyBhbiBlcnJvciByZWdpc3RyeSBmb3IgZXJyb3Ig Y29kZXMgdXNlZCBieSB0aGUgdmFyaW91cyBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgZm9y IHVzZSBpbiA0MDEgcmVzcG9uc2VzIGluIHRoZSBXV1ctQXV0aGVudGljYXRlIGhlYWRlciBkb2Vz IG5vdCBtYWtlIHRlY2huaWNhbCBzZW5zZSBmb3IgdGhlIHYyIHNwZWNpZmljYXRpb24gYXMgaXQg Y3VycmVudGx5IHN0YW5kLiBJdCB3b3VsZCBvbmx5IG1ha2Ugc2Vuc2UgaWYgd2Ugd2VyZSB0byBk ZWZpbmUgYSBtYXN0ZXIgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWUgY2FsbGVkIE9BdXRoMiAo b3Igc2ltaWxhcikgYW5kIHJlcXVpcmUgdGhhdCBldmVyeSBuZXcgdG9rZW4gdHlwZSB1c2VzIHRo YXQgc2NoZW1lIHdpdGggYSBzdWItc2NoZW1lLiBUaGVuLCBzdWNoIGFuIGVycm9yIHJlZ2lzdHJ5 IHdpbGwgbWFrZSBzZW5zZS4NCg0KRm9yIGV4YW1wbGU6DQoNCkF1dGhvcml6YXRpb246IE9BdXRo MiB0eXBlPeKAnWJlYXJlcuKAnSwgdG9rZW494oCdYXNkYWxzaWpkbGthc2pk4oCdDQpBdXRob3Jp emF0aW9uOiBPQXV0aDIgdHlwZT3igJ1tYWPigJ0sIGlkPeKAnWFzZGFzZGFzZOKAnSwgZXRj4oCm DQoNCklmIHlvdSBoYXZlIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGZvciBpbnRyb2R1Y2lu ZyBzdWNoIGEgbmV3IG1hc3RlciBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSwgcGxlYXNlIHBy ZXNlbnQgdGhlbSBhbmQgd2Ugd2lsbCBoYXZlIGEgZGlzY3Vzc2lvbiBhYm91dCBob3cgdG8gYmVz dCBhZGRyZXNzIHRoZW0sIGluY2x1ZGluZyB0aGUgcG9zc2liaWxpdHkgb2YgYWRkaW5nIHN1Y2gg YSBzY2hlbWUuIEluIHRoZSBwYXN0LCBzdWNoIGEgcHJvcG9zYWwgd2FzIHJlamVjdGVkIGR1ZSB0 byBsYWNrIG9mIHdvcmtpbmcgZ3JvdXAgY29uc2Vuc3VzLiBJZiBJIHJlY2FsbCBjb3JyZWN0bHks IG9ubHkgTWFyaXVzIHdhcyBhZHZvY2F0aW5nIHRoYXQgYXBwcm9hY2guDQoNCkFsdGVybmF0aXZl bHksIGlmIHlvdSBoYXZlIHVzZSBjYXNlcyBvciByZXF1aXJlbWVudHMgZm9yIGludHJvZHVjaW5n IGp1c3QgdGhlIFdXVy1BdXRoZW50aWNhdGUgc2lkZSBvZiBhbiBPQXV0aDIgYXV0aG9yaXphdGlv biBzY2hlbWUgKHlvdXIgb3BlbiBpc3N1ZSksIHdoaWNoIGluY2x1ZGVzIGFuIOKAmGVycm9y4oCZ IGF0dHJpYnV0ZSBmb3IgdXNlIHdpdGggdGhlIHByb3Bvc2VkIHJlZ2lzdHJ5LCBwbGVhc2UgcHJl c2VudCB0aG9zZSBhbmQgZXhwbGFpbiBob3cgaXQgd2lsbCB3b3JrIGFsb25nc2lkZSB0aGUgQmVh cmVyIGFuZCBNQUMgc2NoZW1lcyAoYXMgY3VycmVudGx5IGRyYWZ0ZWQpLg0KDQpUaGFua3MsDQoN CkVITA0KDQoNCkZyb206IE1pa2UgSm9uZXMgW21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTEgOTo1MyBBTQ0KVG86IEVyYW4g SGFtbWVyLUxhaGF2OyBPQXV0aCBXRw0KU3ViamVjdDogSW4gdGhlIHNwaXJpdCBvZiBjb21wcm9t aXNlDQoNCkhhdmluZyB0aG91Z2h0IGFib3V0IGl0IG92ZXIgbmlnaHQgYW5kIGRpc2N1c3NlZCBp dCwgSeKAmW0gd2lsbGluZyB0byBkcm9wIG15IG9iamVjdGlvbiB0aGUgV1dXLUF1dGhlbnRpY2F0 ZSByZXNwb25zZSBub3QgYmVpbmcgaW4gdGhlIGZyYW1ld29yayBzcGVjaWZpY2F0aW9uLCBzbyBh cyB0byBjbG9zZSBhbiBvcGVuIGlzc3VlIHRoYXQgY291bGQgZGVsYXkgY29tcGxldGlvbiBvZiB0 aGUgc3BlY2lmaWNhdGlvbnMuDQoNCkVyYW4sIGluIHJldHVybiwgSeKAmWQgbGlrZSB0byBhc2sg eW91IHRvIGRyb3AgeW91ciBvYmplY3Rpb24gdG8gZXh0ZW5kaW5nIHRoZSBlcnJvciByZWdpc3Ry eSBpbiB0aGUgZnJhbWV3b3JrIHNwZWMgc28gdGhhdCDigJxyZXNvdXJjZSBzZXJ2ZXIgZXJyb3Ig cmVzcG9uc2XigJ0gaXMgaW4gdGhlIOKAnGVycm9yIHVzYWdlIGxvY2F0aW9u4oCdIGxpc3QuICBJ ZiB5b3UgZG8gc28sIHRoaXMgd291bGQgY2xvc2UgYW5vdGhlciBvcGVuIGlzc3VlIHRoYXQgY291 bGQgZGVsYXkgY29tcGxldGlvbiBvZiB0aGUgc3BlY2lmaWNhdGlvbnMuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFu ayB5b3UsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiBbbWFpbHRv OmVyYW5AaHVlbml2ZXJzZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA2LCAyMDExIDQ6 MzUgUE0NClRvOiBNaWtlIEpvbmVzOyBPQXV0aCBXRw0KU3ViamVjdDogT0F1dGgyIHNjaGVtZSAo d2FzIEVycm9yIHJlZ2lzdHJ5IHByb3Bvc2FsIChyb3VuZCAzKSkNCg0KV2VsbOKApiBDYW7igJl0 IHNheSBJIGRpZG7igJl0IHNlZSB0aGlzIGNvbWluZyDimLoNCg0KVGhlIGlzc3VlIGlzIG5vdCBz aW1wbHkgYWJvdXQgcHV0dGluZyBhIHNlY3Rpb24gYmFjaywgYnV0IGFib3V0IHRoZSBvdmVyYWxs IHByb3RvY29sIGFyY2hpdGVjdHVyZSBhbmQgaG93IGl0IGNvbXBsaWVzIHdpdGggSFRUUC4NCg0K Rm9yIGV4YW1wbGUsIHRha2luZyB0aGUgTUFDIGRyYWZ0LCBob3cgZG8geW91IGVudmlzaW9uIHRo ZSByZXNvdXJjZSBzZXJ2ZXIgcmVzcG9uZGluZyB0byBhIGZhaWxlZCBhdXRoZW50aWNhdGlvbiBh dHRlbXB0PyBBIDQwMSByZXNwb25zZSBhbmQgd2hhdCBoZWFkZXIocyk/IFdXVy1BdXRoZW50aWNh dGUgd2l0aCDigJhPQXV0aDLigJkgc2NoZW1lPyDigJhNQUPigJkgc2NoZW1lPyBCb3RoPw0KDQpB bHNvIHNlZTogaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvaHR0cGJpcy90cmFjL3RpY2tl dC83OA0KDQpZb3UgbWlnaHQgdGhpbmsgeW91IGFyZSBhc2tpbmcgZm9yIGEgc2ltcGxlIGZlYXR1 cmUsIGJ1dCB0aGlzIGlzIG1vdmluZyB0aGUgcHJvdG9jb2wgZnJvbSBhIHB1cmVseSBhdXRob3Jp emF0aW9uIHByb3RvY29sIHRvIGFuIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIHdoaWNoIGlzIHdo YXQgdGhlIHNwbGl0IG9mIHRoZSB0b2tlbiB0eXBlcyB3YXMgZGVzaWduZWQgdG8gYWNjb21wbGlz aC4NCg0KV2hhdCBJIGFtIGFza2luZyBmb3IgaXMgdG8gcHJvdmlkZSBmdWxsIGV4YW1wbGVzIG9m IGhvdyB5b3UgZW52aXNpb24gdGhlIE9BdXRoMiBzY2hlbWUgdG8gd29yayBpbiBwcmFjdGljZSwg ZXNwZWNpYWxseSBjb25zaWRlcmluZyB0aGUgTUFDIGRyYWZ0LiBBc3N1bWUgdGhhdCB0aGUgTUFD IGRyYWZ0LCBzaW5jZSBpdCBpcyBkZWZpbmVkIGFzIGEgZ2VuZXJhbCBwdXJwb3NlIHNjaGVtZSwg aXMgbm90IGdvaW5nIHRvIGNoYW5nZSAoZm9yIHRoZSBzYWtlIG9mIGFyZ3VtZW50IG9ubHkpLCBk byB5b3UgZW52aXNpb24gaXQgYmVpbmcgdXNlZCBkaWZmZXJlbnRseSB3aGVuIGNvbWJpbmVzIHdp dGggYW4gT0F1dGggYWNjZXNzIHRva2VuPyBUaGF0IHdvdWxkIGJlIGJhZC4NCg0KSSByZW1vdmVk IHRoZSBXV1ctQXV0aGVudGljYXRlIGhlYWRlciBhbmQgdGhlIE9BdXRoMiBzY2hlbWUgYmVjYXVz ZSBpdCBzZXJ2ZWQgbm8gcHVycG9zZSBhbmQgbm8gb25lIGRlbW9uc3RyYXRlZCBob3cgaXQgd2ls bCBiZSBhY3R1YWxseSB1c2VkLiBXUkFQIGlzIG5vdCBhIGdvb2QgZXhhbXBsZSBiZWNhdXNlIFdS QVAgaXMgYSBjbG9zZWQgcHJvdG9jb2wgKGp1c3QgbGlrZSBPQXV0aCAxLjApLiBUaGVyZSBpcyBu byB3YXkgdG8gYWRkIG5ldyBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIHRvIFdSQVAgYW5kIGluIHRo YXQgY29udGV4dCwgaXQgbWFrZXMgc2Vuc2UgdG8gZGVmaW5lIGEgc2NoZW1lLiBCdXQgaGVyZSBp dCB3aWxsIG1lYW4gbW92aW5nIGJhY2t3YXJkcyB0byBhIHByb3RvY29sIHdoZXJlIG9ubHkgT0F1 dGgtc3BlY2lmaWMgYXV0aGVudGljYXRpb24gc2NoZW1lcyBjYW4gYmUgdXNlZCwgYW5kIHRoZXkg YWxsIG11c3QgYmUgZGVmaW5lZCBhcyBleHRlbnNpb25zIG9mIHRoaXMgbWFzdGVyIE9BdXRoMiBz Y2hlbWUuDQoNClRoZXJlIHdhcyBwcmV0dHkgZ29vZCBjb25zZW5zdXMgbm90IHRvIGRlZmluZSBh IG1hc3RlciBzY2hlbWUgd2l0aCBzdWIgc2NoZW1lcy4gVGhhdCBpcyB3ZWxsIGRvY3VtZW50ZWQg b24gdGhlIGxpc3QuIFRoaXMgdGhyZWFkIGluY2x1ZGVkIHRoZSBkaXNjdXNzaW9uIGFib3V0IHVz aW5nIGEgY29tbW9uIHByZWZpeCBmb3Igc2NoZW1lIG5hbWVzLCBldGMuIEhvcGUgd2UgZG9u4oCZ dCBoYXZlIHRvIHJlcGVhdCB0aGF0Lg0KDQpTbyBpZiBPQXV0aDIgaXMgbm90IGEgbWFzdGVyIHNj aGVtZSBmb3IgYWxsIG90aGVyIHNjaGVtZSB0byBiZSBkZWZpbmVkIGFzIHN1Yi1zY2hlbWVzLCB3 aGF0IGlzIGl0PyBJIGRvbuKAmXQgaGF2ZSBhbiBhbnN3ZXIgYW5kIHdlIGtpbmRhIG5lZWQgb25l IHRvIHB1dCBzdWNoIGEgc2NoZW1lIGJhY2sgaW4gdGhlIGRvY3VtZW50Lg0KDQpFSEwNCg0KRnJv bTogTWlrZSBKb25lcyBbbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgQXByaWwgMDYsIDIwMTEgNDoxMyBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2 OyBPQXV0aCBXRw0KU3ViamVjdDogUkU6IEVycm9yIHJlZ2lzdHJ5IHByb3Bvc2FsIChyb3VuZCAz KQ0KDQpBY3R1YWxseSwgeW91IGNvcnJlY3RseSBwb2ludCBvdXQgKGluZGlyZWN0bHkpLCB0aGF0 IHRoaXMgaXMgcmVsYXRlZCB0byBvbmUgb2YgdGhlIG9wZW4gaXNzdWVzIHRoYXQgbmVlZHMgdG8g YmUgcmVzb2x2ZWQgdG8gY29tcGxldGUgdGhlIHNwZWNzIHdoZW4geW91IHdyb3RlIOKAnEZvciBz dWNoIGEgcmVnaXN0cnkgdG8gYmUgdXNlZnVsLCB5b3UgYWxzbyBuZWVkIHRvIHN0YW5kYXJkaXpl IHRoZSBhdXRoZW50aWNhdGlvbiBoZWFkZXIgYWNyb3NzIGFsbCBzY2hlbWVzIGFuZCBkZWZpbmUg YSBzdGFuZGFyZCBwYXJhbWV0ZXIgdXNlZCB0byBkZWxpdmVyIHN1Y2ggZXJyb3IgY29kZXPigJ0u DQoNClRoaXMgb3BlbiBpc3N1ZSAod2hpY2ggdGhlcmUgd2FzbuKAmXQgdGltZSB0byBkaXNjdXNz IGR1cmluZyBsYXN0IHdlZWvigJlzIG1lZXRpbmcpIHdhcyB0aGUgcmVtb3ZhbCBvZiB0aGUgV1dX LUF1dGhlbnRpY2F0ZSBSZXNwb25zZSBIZWFkZXIuICBUaGlzIGZlYXR1cmUgd2FzIHByZXNlbnQg aW4gV1JBUCBhbmQgZWFybGllciBPQXV0aCBkcmFmdHMgYnV0IHdhcyByZW1vdmVkIHdpdGhvdXQg YSBjbGVhciBjb25zZW5zdXMgdG8gZG8gc28uICBBbmQgaW5kZWVkLCBkdXJpbmcgb3VyIHByaXZh dGUgZGlzY3Vzc2lvbnMgb24gaG93IHRoZSBkcmFmdCBzaG91bGQgYmUgc3BsaXQsIGF0IHRoYXQg dGltZSwgeW91IHRvb2sgdGhlIHBvc2l0aW9uIHRoYXQgdGhlIFdXVy1BdXRoZW50aWNhdGUgcmVz cG9uc2Ugc2hvdWxkIHJlbWFpbiBpbiB0aGUgZnJhbWV3b3JrIHNwZWMuDQoNClRoZSByZXN1bHQg aGFzIGJlZW4gdGhhdCB0aGVyZSBpcyBkaWZmZXJlbnQgYW5kIGluY29tcGF0aWJsZSBXV1ctQXV0 aGVudGljYXRlIHJlc3BvbnNlIGZ1bmN0aW9uYWxpdHkgaW4gbXVsdGlwbGUgcmVsYXRlZCBkcmFm dHMg4oCTIHNwZWNpZmljYWxseSBkcmFmdC1oYW1tZXItb2F1dGgtdjItbWFjLXRva2VuLTAyIGFu ZCBkcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wNC4gIEludGVyb3BlcmFiaWxpdHkgYW5kIGRl dmVsb3BlcnMgd291bGQgYm90aCBiZSBiZXR0ZXIgc2VydmVkIGJ5IG1vdmluZyB0aGlzIGZ1bmN0 aW9uYWxpdHkgYmFjayBpbnRvIHRoZSBjb3JlLiBJIGRvbuKAmXQgYmVsaWV2ZSB0aGF0IGVhY2gg cmVsYXRlZCBPQXV0aCBzcGVjaWZpY2F0aW9uIHNob3VsZCBoYXZlIHRvIHNlcGFyYXRlbHkgc3Bl Y2lmeSB0aGlzIGZ1bmN0aW9uYWxpdHkuICBBcyB0aGlzIHdhcyBub3QgZGlzY3Vzc2VkIGR1cmlu ZyBsYXN0IHdlZWvigJlzIG1lZXRpbmcsIGEgY29uc2Vuc3VzIGNhbGwgZnJvbSB0aGUgY2hhaXJz IG1heSBiZSBuZWNlc3NhcnkgdG8gcmVzb2x2ZSB0aGlzIGlzc3VlLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr ZQ0KDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21d DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA2LCAyMDExIDM6NTggUE0NClRvOiBNaWtlIEpvbmVz OyBPQXV0aCBXRw0KU3ViamVjdDogUkU6IEVycm9yIHJlZ2lzdHJ5IHByb3Bvc2FsIChyb3VuZCAz KQ0KDQpQdXR0aW5nIGFzaWRlIG15IHZpZXcgdGhhdCBhIHJlZ2lzdHJ5IGZvciByZXNvdXJjZSBz ZXJ2ZXIgZXJyb3IgcmVzcG9uc2VzIGFjcm9zcyBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMg aXNu4oCZdCB2ZXJ5IHVzZWZ1bCBvciBpbnRlcmVzdGluZywgSSBkb27igJl0IGhhdmUgYW4gb2Jq ZWN0aW9uIHRvIHRoZSBiZWFyZXIgdG9rZW4gc3BlY2lmaWNhdGlvbiBkZWZpbmluZyBzdWNoIGdl bmVyYWwgcHVycG9zZSByZWdpc3RyeS4gSW4gYSB3YXksIGl0IGlzIHNpbWlsYXIgdG8gdGhlIGVy cm9yIHJlc3BvbnNlIGhlYWRlcnMgZGVmaW5lZCBieSBEaWdlc3QsIG9ubHkgbmV2ZXIgbWFkZSBn ZW5lcmFsbHkgYXBwbGljYWJsZS4NCg0KVGhlIGRpZmZlcmVuY2UgaW4gb3VyIGFwcHJvYWNoZXMg aXMgdGhhdCBJIGRvbuKAmXQgY29uc2lkZXIgdGhlIGJlYXJlciB0b2tlbiBvciBtYWMgdG9rZW4g c3BlY3MgdG8gYmUgZXh0ZW5zaW9ucyBvZiB0aGUgdjIgc3BlYywgYnV0IGZ1bGx5IHNwZWNpZmll ZCBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgd2l0aCBPQXV0aCAyLjAgYmluZGluZyAoaS5l LiB0aGUgYWNjZXNzIHRva2VuIHR5cGUgcmVnaXN0cmF0aW9uKS4gQmVjYXVzZSBvZiB0aGF0LCBJ IGRvbuKAmXQgdGhpbmsgdGhlIHYyIHNwZWMgaXMgdGhlIHJpZ2h0IHBsYWNlIGZvciBzdWNoIGEg cmVnaXN0cnksIHdoaWNoIGlzIHJlYWxseSBhYm91dCBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVt ZXMgYW5kIG5vdCBPQXV0aC4gVGhlcmVmb3JlLCBJIHRoaW5rIGl0IHdpbGwgYmUgbW9yZSBjb25m dXNpbmcgdG8gcHV0IHN1Y2ggYSByZWdpc3RyeSBpbiB2Mi4NCg0KSeKAmWxsIGdpdmUgeW91IGFu IGV4YW1wbGUuIFN1cHBvc2Ugc29tZW9uZSB3aWxsIGRlZmluZSBhIERpZ2VzdCBhY2Nlc3MgdG9r ZW4gdHlwZS4gV2hlbiBpc3N1aW5nIG9uZSwgdGhlIHNlcnZlciB3aWxsIHNlbmQgYW4gYWNjZXNz IHRva2VuICh0byBiZSB1c2VkIGFzIHVzZXJuYW1lKSBhbmQgYSBzZWNyZXQgKHRvIGJlIHVzZWQg YXMgcGFzc3dvcmQpLiBUbyB1c2Ugc3VjaCBhIHRva2VuLCB0aGUgY2xpZW50IHdpbGwgdXNlIHRo ZSBIVFRQIERpZ2VzdCBzY2hlbWUgKGFzIGlzKS4gRGlnZXN0IGRlZmluZXMgaXRzIG93biBzZXQg YW5kIG1ldGhvZCBvciBzcGVjaWZ5aW5nIGVycm9yIGNvZGUuIFdvdWxkIHlvdSBleHBlY3QgdGhv c2UgdG8gYmUgcmVnaXN0ZXJlZCBpbiB5b3VyIHByb3Bvc2VkIHJlZ2lzdHJ5PyBJIHdvdWxkIGFz c3VtZSBub3QuDQoNCkZvciBzdWNoIGEgcmVnaXN0cnkgdG8gYmUgdXNlZnVsLCB5b3UgYWxzbyBu ZWVkIHRvIHN0YW5kYXJkaXplIHRoZSBhdXRoZW50aWNhdGlvbiBoZWFkZXIgYWNyb3NzIGFsbCBz Y2hlbWVzIGFuZCBkZWZpbmUgYSBzdGFuZGFyZCBwYXJhbWV0ZXIgdXNlZCB0byBkZWxpdmVyIHN1 Y2ggZXJyb3IgY29kZXMuIEhvd2V2ZXIsIHdlIGFscmVhZHkgbW92ZWQgYXdheSBmcm9tIHRoYXQg ZGVzaWduIGJ5IGRlZmluaW5nIHNlcGFyYXRlIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcyBm b3IgZWFjaCB0b2tlbiB0eXBlLg0KDQpCdXQgYWdhaW4sIEkgZG9u4oCZdCBoYXZlIGFuIG9iamVj dGlvbiB0byBzdWNoIGEgcmVnaXN0cnkgZGVmaW5lZCBpbiB0aGUgYmVhcmVyIHRva2VuIHNwZWMu IEkgaGF2ZSBubyBpbnRlbnRpb25zIG9mIHVzaW5nIGl0IGZvciBhbnkgSFRUUCBhdXRoZW50aWNh dGlvbiBzY2hlbWUgSSBwbGFuIHRvIGF1dGhvci4NCg0KRUhMDQoNCg0KDQoNCg0KRnJvbTogTWlr ZSBKb25lcyBbbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV0NClNlbnQ6IFdlZG5l c2RheSwgQXByaWwgMDYsIDIwMTEgMzozOSBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0 aCBXRw0KU3ViamVjdDogUkU6IEVycm9yIHJlZ2lzdHJ5IHByb3Bvc2FsIChyb3VuZCAzKQ0KDQpU aGUgcHJvYmxlbSB3aXRoIHRoYXQgc2l0dWF0aW9uIGlzIHRoYXQgaXQgZG9lc27igJl0IHByb3Zp ZGUgYSBjZW50cmFsIHJlZ2lzdHJ5IGZvciByZXNvdXJjZSBzZXJ2ZXIgZXJyb3IgcmVzcG9uc2Vz IGFjcm9zcyBzcGVjcywgdW5saWtlIHRoZSBvdGhlciBraW5kcyBvZiBPQXV0aCBlcnJvciByZXNw b25zZXMuICBJIGNvdWxkIGRlZmluZSB0aGF0IHJlZ2lzdHJ5IGluIHRoZSBiZWFyZXIgdG9rZW4g c3BlYywgYnV0IGl0IHdvdWxkIGJlIGxlc3MgY29uZnVzaW5nIHRvIHVuaWZ5IGl0IHdpdGggdGhl IHByb3Bvc2VkIHJlZ2lzdHJ5IGluIHRoZSBmcmFtZXdvcmsgc3BlYy4gIEkgc3VzcGVjdCBkZXZl bG9wZXJzIHdvdWxkIHRoYW5rIHVzIGZvciBkb2luZyB0aGF0Lg0KDQpXaGF0IGRvIHlvdSBzYXk/ DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEVyYW4gSGFtbWVyLUxhaGF2IFttYWlsdG86ZXJh bkBodWVuaXZlcnNlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMDYsIDIwMTEgMjo1OCBQ TQ0KVG86IE1pa2UgSm9uZXM7IE9BdXRoIFdHDQpTdWJqZWN0OiBSRTogRXJyb3IgcmVnaXN0cnkg cHJvcG9zYWwgKHJvdW5kIDMpDQoNCkhpIE1pa2UsDQoNClRoaXMgaXMgaW50ZW50aW9uYWwuIFRo ZSBlcnJvciByZWdpc3RyeSBkZWZpbmVkIGluIHYyIGlzIG5vdCBkZXNpZ25lZCB0byByZWNvcmQg ZXJyb3JzIGZvciB0aGUgcHJvdGVjdGVkIHJlc291cmNlIGVuZHBvaW50IHJlc3BvbnNlIG9yIHRo ZSBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIGhlYWRlciB3aGVuIHVzZWQgd2l0aCB0aGUgQmVh cmVyIHRva2VuIHNjaGVtZSAob3IgYW55IG90aGVyIHNjaGVtZSkuDQoNClRoZSBvbmx5IHB1cnBv c2Ugb2YgdGhlIHJlZ2lzdHJ5IGlzIHRvIGF2b2lkIG5hbWUgY29sbGlzaW9ucyBiZXR3ZWVuIHR3 byBlcnJvcnMgdXNlZCBkaWZmZXJlbnRseSB3aXRoIHRoZSB2MiBzcGVjaWZpY2F0aW9uLiBTaW5j ZSBlcnJvcnMgdXNlZCB3aXRoIHRoZSBCZWFyZXIgdG9rZW4gc2NoZW1lIHdpbGwgbmV2ZXIgYXBw ZWFyIGluIHRoZSBzYW1lIHBsYWNlIGFzIHRoZSB2MiBlbmRwb2ludHMsIHRoZXJlIGlzIG5vIG5l ZWQgZm9yIGNvbWJpbmluZyB0aGVzZSB0d28gcmVnaXN0cmllcy4NCg0KSWYgdGhlIGJlYXJlciB0 b2tlbiBzcGVjaWZpY2F0aW9uIHJlcXVpcmVzIGVycm9yIGV4dGVuc2liaWxpdHksIHlvdSBzaG91 bGQgcmV0YWluIHRoZSByZWdpc3RyeSB0aGVyZSBhbmQgbGltaXQgaXQgdG8ganVzdCB0aGUgcHJv dGVjdGVkIHJlc291cmNlIHJlc3BvbnNlIHNwYWNlLiBJZGVhbGx5LCB5b3Ugd291bGQgbGltaXQg aXQgdG8ganVzdCB0aGUgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIg4oCYZXJyb3LigJkgcGFyYW1l dGVyIHdoZW4gdXNlZCB3aXRoIHRoZSBCZWFyZXIgc2NoZW1lLiBUaGUgTUFDIHNjaGVtZSBkb2Vz IG5vdCB1c2UgZXJyb3IgY29kZXMsIGJ1dCBpbnN0ZWFkLCByZWxpZXMgZnVsbHkgb24gSFRUUCBz dGF0dXMgY29kZSBzaW5jZSBubyBhZGRpdGlvbmFsIGVycm9yIGNvbmRpdGlvbnMgd2VyZSBpZGVu dGlmaWVkLg0KDQpBbHNvLCBzaW5jZSB5b3VyIEFCTkYgcGVybWl0cyBhZGRpbmcgYWRkaXRpb25h bCBBdXRob3JpemF0aW9uIGhlYWRlciBwYXJhbWV0ZXJzLCB5b3UgbWlnaHQgd2FudCB0byBjb25z aWRlciBkZWZpbmluZyBhIHByb2Nlc3MgZm9yIGRvaW5nIHRoYXQsIGlmIHlvdSBhcmUgZ29pbmcg dG8gZGVmaW5lIGFuIGVycm9yIHJlZ2lzdHJ5LiBDdXJyZW50bHksIHRvIGFkZCBhZGRpdGlvbmFs IHBhcmFtZXRlcnMsIG9uZSBoYXMgdG8gdXBkYXRlIHRoZSBCZWFyZXIgdG9rZW4gUkZDLCBpbiBj b250cmFzdCB0byBzaW1wbHkgcmVnaXN0ZXJpbmcgYSBuZXcgZXJyb3IgY29kZSAod2hpY2ggaXMg bGlrZWx5IHRvIGNvbWUgb3V0IG9mIGEgbmV3IHBhcmFtZXRlcikuDQoNCkVITA0KDQoNCkZyb206 IE1pa2UgSm9uZXMgW21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21dDQpTZW50OiBX ZWRuZXNkYXksIEFwcmlsIDA2LCAyMDExIDI6MjUgUE0NClRvOiBFcmFuIEhhbW1lci1MYWhhdjsg T0F1dGggV0cNClN1YmplY3Q6IFJFOiBFcnJvciByZWdpc3RyeSBwcm9wb3NhbCAocm91bmQgMykN Cg0KVGhhbmtzIGZvciB3cml0aW5nIHRoaXMgdXAsIEVyYW4uICBJIGJlbGlldmUgdGhhdCB0aGlz IGlzIGEgc3RlcCBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uLg0KDQpXZWFyaW5nIG15IEJlYXJlciBU b2tlbiBzcGVjIGVkaXRvciBoYXQsIEkganVzdCB0cmllZCB0byBnbyB0aHJvdWdoIHRoZSBleGVy Y2lzZSBvZiBlZGl0aW5nIG15IGRvY3VtZW50IHRvIHVzZSB0aGUgcmVnaXN0cnkgaW4gZHJhZnQg MTUgdG8gcmVnaXN0ZXIgdGhlIGVycm9ycyBkZWZpbmVkIGluIHRoZSBiZWFyZXIgdG9rZW4gc3Bl YyBhbmQgSSBoaXQgYSByb2FkYmxvY2suICBTcGVjaWZpY2FsbHksIHdoaWxlIHRoZSBlcnJvcnMg ZGVmaW5lZCBieSBteSBzcGVjIGFyZSByZXR1cm5lZCBieSByZXNvdXJjZSBzZXJ2ZXJzIChmbG93 IEYgaW4gRmlndXJlIDEpLCB0aGUgcmVnaXN0cnkgZGVmaW5lZCBieSBkcmFmdCAxNSBkb2VzIG5v dCBpbmNsdWRlIOKAnHJlc291cmNlIHNlcnZlciBlcnJvciByZXNwb25zZeKAnSBpbiB0aGUg4oCc ZXJyb3IgdXNhZ2UgbG9jYXRpb27igJ0gbGlzdC4gIENhbiB5b3UgcGxlYXNlIGFkZCB0aGlzIGFk ZGl0aW9uYWwgZXJyb3IgdXNhZ2UgbG9jYXRpb24gc28gdGhhdCB0aGUgcmVnaXN0cnkgY2FuIGJl IHVzZWQgYnkgdGhlIGJlYXJlciB0b2tlbiBzcGVjaWZpY2F0aW9uPw0KDQpBdCB0aGF0IHBvaW50 LCBJIGJlbGlldmUgd2XigJlsbCBiZSBhYmxlIHRvIGNsb3NlIHRoZSBvcGVuIGlzc3VlIGFib3V0 IHRoZSBuZWVkIGZvciBhbiBlcnJvciByZWdpc3RyeSwgYW5kIEnigJlsbCB1cGRhdGUgbXkgZHJh ZnQgYWNjb3JkaW5nbHkuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFuayB5b3UsDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpG cm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEVyYW4gSGFtbWVyLUxhaGF2DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAw NSwgMjAxMSAzOjUyIFBNDQpUbzogT0F1dGggV0cNClN1YmplY3Q6IFtPQVVUSC1XR10gRXJyb3Ig cmVnaXN0cnkgcHJvcG9zYWwgKHJvdW5kIDMpDQoNClRoZSBmb2xsb3dpbmcgaXMgbXkgbmV3IHBy b3Bvc2FsLCBiYXNlZCBvbiBNaWtlIEpvbmVz4oCZIGFuZCBteSBlYXJsaWVyIHByb3Bvc2Fscy4g SXQgaXMgYmFzaWNhbGx5IGEgY29tYmluYXRpb24gb2YgdGhlIHR3by4NCg0KVGhpcyBwcm9wb3Nh bCBkb2VzIG5vdCBhbGxvdyBkZWZpbmluZyBuZXcgZXJyb3IgY29kZXMgdW5sZXNzIGFub3RoZXIg ZXh0ZW5zaW9uIGlzIGludm9sdmVkIChuZXcgZ3JhbnQgdHlwZSwgcmVxdWVzdCBwYXJhbWV0ZXIs IHRva2VuIHR5cGUpLiBUaGUgcmVhc29uIGZvciBub3QgZGVmaW5pbmcgYW4gb3BlbiBlbmRlZCBl cnJvciByZWdpc3RyeSBpcyB0aGF0IGRlZmluaW5nIG5ldyBlcnJvciBjb2RlcyBmb3IgZXhpc3Rp bmcgaW1wbGVtZW50YXRpb25zIGlzIGJhZCBmb3IgaW50ZXJvcGVyYWJpbGl0eSBhbmQgY2FuIGxl YWQgdG8gdW5leHBlY3RlZCByZXN1bHRzIChkZXZlbG9wZXJzIG5vdCB0YWtpbmcgaW50byBhY2Nv dW50IHJlY2VpdmluZyBhIG5ldyBlcnJvciB3aGVuIHRhbGtpbmcgdG8gYSBjb21wbGlhbnQgMi4w IHNlcnZlcikuIFdlIGRvbid0IGhhdmUgYW55IHVzZSBjYXNlcyBmb3IgZGVmaW5pbmcgc3VjaCBu ZXcgZXJyb3JzIGZvciB0aGUgdjIgc3BlY2lmaWNhdGlvbi4gTmV3IGVycm9ycyBvbmx5IGNvbWUg ZnJvbSBleHRlbnNpb25zIGFuZCBtdXN0IGJlIGRlZmluZWQgaW4gdGhhdCBjb250ZXh0Lg0KDQpJ IGhhdmUgYXBwbGllZCB0byBjaGFuZ2VzIHRvIHRoZSAtMTQgZHJhZnQgYW5kIGNsZWFybHkgbWFy a2VkIHRoZW0gd2l0aCBbW1BlbmRpbmcgQ29uc2Vuc3VzXV0gc28gdGhhdCB0aGVyZSBpcyBubyBp c3N1ZSB3aXRoIHJlbW92aW5nIHRoZW0gb3IgY2hhbmdpbmcgdGhlbSBsYXRlci4NCg0KLS0tDQoN CkFkZCB0byB0aGUgZXJyb3IgY29kZXMgbGlzdCBpbiBzZWN0aW9ucyA0LjEuMi4xIGFuZCA0LjIu Mi4xOg0KDQogICAgICAgICBhIDR4eCBvciA1eHggSFRUUCBzdGF0dXMgY29kZSAoZXhjZXB0IGZv ciA0MDAgYW5kIDQwMSkNCiAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN QVkgc2V0IHRoZSAiZXJyb3IiIHBhcmFtZXRlcg0KICAgICAgICAgICAgICAgdmFsdWUgdG8gYSBu dW1lcmljYWwgSFRUUCBzdGF0dXMgY29kZSBmcm9tIHRoZSA0eHggb3IgNXh4DQogICAgICAgICAg ICAgICByYW5nZSwgd2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSA0MDAgKEJhZCBSZXF1ZXN0KSBh bmQNCiAgICAgICAgICAgICAgIDQwMSAoVW5hdXRob3JpemVkKSBzdGF0dXMgY29kZXMuICBGb3Ig ZXhhbXBsZSwgaWYgdGhlDQogICAgICAgICAgICAgICBzZXJ2aWNlIGlzIHRlbXBvcmFyaWx5IHVu YXZhaWxhYmxlLCB0aGUgYXV0aG9yaXphdGlvbg0KICAgICAgICAgICAgICAgc2VydmVyIE1BWSBy ZXR1cm4gYW4gZXJyb3IgcmVzcG9uc2Ugd2l0aCAiZXJyb3IiIHNldCB0bw0KICAgICAgICAgICAg ICAgIjUwMyIuDQoNCg0KQWRkIGEgbmV3IHNlY3Rpb24gOC40Og0KDQoNCjguNC4gIERlZmluaW5n IEFkZGl0aW9uYWwgRXJyb3IgQ29kZXMNCg0KDQoNCiAgIEluIGNhc2VzIHdoZXJlIHByb3RvY29s IGV4dGVuc2lvbnMgKGkuZS4gYWNjZXNzIHRva2VuIHR5cGVzLA0KDQogICBleHRlbnNpb24gcGFy YW1ldGVycywgb3IgZXh0ZW5zaW9uIGdyYW50IHR5cGVzKSByZXF1aXJlIGFkZGl0aW9uYWwNCg0K ICAgZXJyb3IgY29kZXMgdG8gYmUgdXNlZCB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3Jh bnQgZXJyb3INCg0KICAgcmVzcG9uc2UgKFNlY3Rpb24gNC4xLjIuMSksIHRoZSBpbXBsaWNpdCBn cmFudCBlcnJvciByZXNwb25zZQ0KDQogICAoU2VjdGlvbiA0LjIuMi4xKSwgb3IgdGhlIHRva2Vu IGVycm9yIHJlc3BvbnNlIChTZWN0aW9uIDUuMiksIHN1Y2gNCg0KICAgZXJyb3IgY29kZXMgTUFZ IGJlIGRlZmluZWQuDQoNCg0KDQogICBFeHRlbnNpb24gZXJyb3IgY29kZXMgTVVTVCBiZSByZWdp c3RlcmVkIChmb2xsb3dpbmcgdGhlIHByb2NlZHVyZXMgaW4NCg0KICAgU2VjdGlvbiAxMC4zKSBp ZiB0aGUgZXh0ZW5zaW9uIHRoZXkgYXJlIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCBpcw0KDQog ICByZWdpc3RlcmVkLiAgQWRkaXRpb25hbCBlcnJvciBjb2RlcyB1c2VkIHdpdGggdW5yZWdpc3Rl cmVkIGV4dGVuc2lvbnMNCg0KICAgTUFZIGJlIHJlZ2lzdGVyZWQuDQoNCg0KDQogICBFcnJvciBj b2RlcyBNVVNUIGNvbmZvcm0gdG8gdGhlIGVycm9yLWNvZGUgQUJORiwgYW5kIFNIT1VMRCBiZQ0K DQogICBwcmVmaXhlZCBieSBhbiBpZGVudGlmeWluZyBuYW1lIHdoZW4gcG9zc2libGUuICBGb3Ig ZXhhbXBsZSwgYW4gZXJyb3INCg0KICAgaWRlbnRpZnlpbmcgYW4gaW52YWxpZCB2YWx1ZSBzZXQg dG8gdGhlIGV4dGVuc2lvbiBwYXJhbWV0ZXIgImV4YW1wbGUiDQoNCiAgIHNob3VsZCBiZSBuYW1l ZCAiZXhhbXBsZV9pbnZhbGlkIi4NCg0KDQoNCg0KDQogICAgIGVycm9yLWNvZGUgICA9IEFMUEhB ICplcnJvci1jaGFyDQoNCiAgICAgZXJyb3ItY2hhciAgID0gIi0iIC8gIi4iIC8gIl8iIC8gRElH SVQgLyBBTFBIQQ0KDQoNCkFkZCBhIG5ldyBzZWN0aW9uIDEwLjM6DQoNCg0KMTAuMy4gIFRoZSBP QXV0aCBFeHRlbnNpb25zIEVycm9yIFJlZ2lzdHJ5DQoNCg0KDQogICBUaGlzIHNwZWNpZmljYXRp b24gZXN0YWJsaXNoZXMgdGhlIE9BdXRoIGV4dGVuc2lvbnMgZXJyb3IgcmVnaXN0cnkuDQoNCg0K DQoNCg0KICAgQWRkaXRpb25hbCBlcnJvciBjb2RlcyB1c2VkIHRvZ2V0aGVyIHdpdGggb3RoZXIg cHJvdG9jb2wgZXh0ZW5zaW9ucw0KDQogICAoaS5lLiBleHRlbnNpb24gZ3JhbnQgdHlwZXMsIGFj Y2VzcyB0b2tlbiB0eXBlcywgb3IgZXh0ZW5zaW9uDQoNCiAgIHBhcmFtZXRlcnMpIGFyZSByZWdp c3RlcmVkIG9uIHRoZSBhZHZpY2Ugb2Ygb25lIG9yIG1vcmUgRGVzaWduYXRlZA0KDQogICBFeHBl cnRzIChhcHBvaW50ZWQgYnkgdGhlIElFU0cgb3IgdGhlaXIgZGVsZWdhdGUpLCB3aXRoIGENCg0K ICAgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCAodXNpbmcgdGVybWlub2xvZ3kgZnJvbSBbUkZDNTIy Nl0pLiAgSG93ZXZlciwNCg0KICAgdG8gYWxsb3cgZm9yIHRoZSBhbGxvY2F0aW9uIG9mIHZhbHVl cyBwcmlvciB0byBwdWJsaWNhdGlvbiwgdGhlDQoNCiAgIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIG1h eSBhcHByb3ZlIHJlZ2lzdHJhdGlvbiBvbmNlIHRoZXkgYXJlIHNhdGlzZmllZA0KDQogICB0aGF0 IHN1Y2ggYSBzcGVjaWZpY2F0aW9uIHdpbGwgYmUNCg0KIHB1Ymxpc2hlZC4NCg0KDQoNCiAgIFJl Z2lzdHJhdGlvbiByZXF1ZXN0cyBzaG91bGQgYmUgc2VudCB0byB0aGUgW1RCRF1AaWV0Zi5vcmcg bWFpbGluZw0KDQogICBsaXN0IGZvciByZXZpZXcgYW5kIGNvbW1lbnQsIHdpdGggYW4gYXBwcm9w cmlhdGUgc3ViamVjdCAoZS5nLiwNCg0KICAgIlJlcXVlc3QgZm9yIGVycm9yIGNvZGU6IGV4YW1w bGUiKS4gW1sgTm90ZSB0byBSRkMtRURJVE9SOiBUaGUgbmFtZQ0KDQogICBvZiB0aGUgbWFpbGlu ZyBsaXN0IHNob3VsZCBiZSBkZXRlcm1pbmVkIGluIGNvbnN1bHRhdGlvbiB3aXRoIHRoZQ0KDQog ICBJRVNHIGFuZCBJQU5BLiAgU3VnZ2VzdGVkIG5hbWU6IG9hdXRoLWV4dC1yZXZpZXcuIF1dDQoN Cg0KDQogICBXaXRoaW4gYXQgbW9zdCAxNCBkYXlzIG9mIHRoZSByZXF1ZXN0LCB0aGUgRGVzaWdu YXRlZCBFeHBlcnQocykgd2lsbA0KDQogICBlaXRoZXIgYXBwcm92ZSBvciBkZW55IHRoZSByZWdp c3RyYXRpb24gcmVxdWVzdCwNCg0KIGNvbW11bmljYXRpbmcgdGhpcw0KDQogICBkZWNpc2lvbiB0 byB0aGUgcmV2aWV3IGxpc3QgYW5kIElBTkEuICBEZW5pYWxzIHNob3VsZCBpbmNsdWRlIGFuDQoN CiAgIGV4cGxhbmF0aW9uIGFuZCwgaWYgYXBwbGljYWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8gaG93 IHRvIG1ha2UgdGhlDQoNCiAgIHJlcXVlc3Qgc3VjY2Vzc2Z1bC4NCg0KDQoNCiAgIERlY2lzaW9u cyAob3IgbGFjayB0aGVyZW9mKSBtYWRlIGJ5IHRoZSBEZXNpZ25hdGVkIEV4cGVydCBjYW4gYmUN Cg0KICAgZmlyc3QgYXBwZWFsZWQgdG8gQXBwbGljYXRpb24gQXJlYSBEaXJlY3RvcnMgKGNvbnRh Y3RhYmxlIHVzaW5nDQoNCiAgIGFwcC1hZHNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmFwcC1hZHNA dG9vbHMuaWV0Zi5vcmc+IGVtYWlsIGFkZHJlc3Mgb3IgZGlyZWN0bHkgYnkgbG9va2luZyB1cCB0 aGVpcg0KDQogICBlbWFpbCBhZGRyZXNzZXMgb24NCg0KIGh0dHA6Ly93d3cuaWVzZy5vcmcvIHdl YnNpdGUpIGFuZCwgaWYgdGhlDQoNCiAgIGFwcGVsbGFudCBpcyBub3Qgc2F0aXNmaWVkIHdpdGgg dGhlIHJlc3BvbnNlLCB0byB0aGUgZnVsbCBJRVNHICh1c2luZw0KDQogICB0aGUgaWVzZ0BpZXNn Lm9yZzxtYWlsdG86aWVzZ0BpZXNnLm9yZz4gbWFpbGluZyBsaXN0KS4NCg0KDQoNCiAgIElBTkEg c2hvdWxkIG9ubHkgYWNjZXB0IHJlZ2lzdHJ5IHVwZGF0ZXMgZnJvbSB0aGUgRGVzaWduYXRlZA0K DQogICBFeHBlcnQocyksIGFuZCBzaG91bGQgZGlyZWN0IGFsbCByZXF1ZXN0cyBmb3IgcmVnaXN0 cmF0aW9uIHRvIHRoZQ0KDQogICByZXZpZXcgbWFpbGluZyBsaXN0Lg0KDQoNCg0KMTAuMy4xLiAg UmVnaXN0cmF0aW9uIFRlbXBsYXRlDQoNCg0KDQogICBFcnJvciBuYW1lOg0KDQogICAgICBUaGUg bmFtZSByZXF1ZXN0ZWQgKGUuZy4sICJleGFtcGxlIikuDQoNCiAgIEVycm9yIHVzYWdlIGxvY2F0 aW9uOg0KDQogICAgICBUaGUgbG9jYXRpb24ocykgd2hlcmUgdGhlIGVycm9yIGNhbiBiZSB1c2Vk LiAgVGhlIHBvc3NpYmxlDQoNCiAgICAgIGxvY2F0aW9ucyBhcmU6IGF1dGhvcml6YXRpb24gY29k ZSBncmFudCBlcnJvciByZXNwb25zZQ0KDQogICAgICAoU2VjdGlvbiA0LjEuMi4xKSwgaW1wbGlj aXQgZ3JhbnQgZXJyb3IgcmVzcG9uc2UNCg0KICAgICAgKFNlY3Rpb24gNC4yLjIuMSksIG9yIHRv a2VuIGVycm9yIHJlc3BvbnNlIChTZWN0aW9uIDUuMikuDQoNCiAgIFJlbGF0ZWQgcHJvdG9jb2wg ZXh0ZW5zaW9uOg0KDQogICAgICBUaGUgbmFtZSBvZiB0aGUgZXh0ZW5zaW9uIGdyYW50IHR5cGUs IGFjY2Vzcw0KDQogdG9rZW4gdHlwZSwgb3INCg0KICAgICAgZXh0ZW5zaW9uIHBhcmFtZXRlciwg dGhlIGVycm9yIGNvZGUgaXMgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoLg0KDQogICBDaGFuZ2Ug Y29udHJvbGxlcjoNCg0KICAgICAgRm9yIHN0YW5kYXJkcy10cmFjayBSRkNzLCBzdGF0ZSAiSUVU RiIuICBGb3Igb3RoZXJzLCBnaXZlIHRoZSBuYW1lDQoNCiAgICAgIG9mIHRoZSByZXNwb25zaWJs ZSBwYXJ0eS4gIE90aGVyIGRldGFpbHMgKGUuZy4sIHBvc3RhbCBhZGRyZXNzLA0KDQogICAgICBl LW1haWwgYWRkcmVzcywgaG9tZSBwYWdlIFVSSSkgbWF5IGFsc28gYmUgaW5jbHVkZWQuDQoNCiAg IFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6DQoNCiAgICAgIFJlZmVyZW5jZSB0byBkb2N1bWVu dCB0aGF0IHNwZWNpZmllcyB0aGUgZXJyb3IgY29kZSwgcHJlZmVyYWJseQ0KDQogICAgICBpbmNs dWRpbmcgYQ0KDQogVVJJIHRoYXQgY2FuIGJlIHVzZWQgdG8gcmV0cmlldmUgYSBjb3B5IG9mIHRo ZQ0KDQogICAgICBkb2N1bWVudC4gIEFuIGluZGljYXRpb24gb2YgdGhlIHJlbGV2YW50IHNlY3Rp b25zIG1heSBhbHNvIGJlDQoNCiAgICAgIGluY2x1ZGVkLCBidXQgaXMgbm90IHJlcXVpcmVkLg0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E320P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAw IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KcC55aXYyOTA3MzM2OThtc29wbGFp bnRleHQsIGxpLnlpdjI5MDczMzY5OG1zb3BsYWludGV4dCwgZGl2LnlpdjI5MDczMzY5OG1zb3Bs YWludGV4dA0KCXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThtc29wbGFpbnRleHQ7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2MjkwNzMzNjk4bXNv YWNldGF0ZSwgbGkueWl2MjkwNzMzNjk4bXNvYWNldGF0ZSwgZGl2LnlpdjI5MDczMzY5OG1zb2Fj ZXRhdGUNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjkwNzMzNjk4bXNvYWNldGF0ZTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC55aXYyOTA3MzM2OThtc29ub3Jt YWwsIGxpLnlpdjI5MDczMzY5OG1zb25vcm1hbCwgZGl2LnlpdjI5MDczMzY5OG1zb25vcm1hbA0K CXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThtc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2MjkwNzMzNjk4bXNvY2hwZGVmYXVsdCwg bGkueWl2MjkwNzMzNjk4bXNvY2hwZGVmYXVsdCwgZGl2LnlpdjI5MDczMzY5OG1zb2NocGRlZmF1 bHQNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjkwNzMzNjk4bXNvY2hwZGVmYXVsdDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYyOTA3MzM2OThtc29o eXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjkwNzMzNjk4bXNvaHlwZXJsaW5rO30NCnNw YW4ueWl2MjkwNzMzNjk4bXNvaHlwZXJsaW5rZm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MjkwNzMzNjk4bXNvaHlwZXJsaW5rZm9sbG93ZWQ7fQ0Kc3Bhbi55aXYyOTA3MzM2OThodG1scHJl Zm9ybWF0dGVkY2hhcg0KCXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThodG1scHJlZm9ybWF0 dGVkY2hhcjt9DQpzcGFuLnlpdjI5MDczMzY5OHBsYWludGV4dGNoYXINCgl7bXNvLXN0eWxlLW5h bWU6eWl2MjkwNzMzNjk4cGxhaW50ZXh0Y2hhcjt9DQpzcGFuLnlpdjI5MDczMzY5OGJhbGxvb250 ZXh0Y2hhcg0KCXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThiYWxsb29udGV4dGNoYXI7fQ0K c3Bhbi55aXYyOTA3MzM2OThlbWFpbHN0eWxlMjMNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjkwNzMz Njk4ZW1haWxzdHlsZTIzO30NCnNwYW4ueWl2MjkwNzMzNjk4ZW1haWxzdHlsZTI0DQoJe21zby1z dHlsZS1uYW1lOnlpdjI5MDczMzY5OGVtYWlsc3R5bGUyNDt9DQpzcGFuLnlpdjI5MDczMzY5OGVt YWlsc3R5bGUyNQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThlbWFpbHN0eWxlMjU7fQ0K c3Bhbi55aXYyOTA3MzM2OThlbWFpbHN0eWxlMjYNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjkwNzMz Njk4ZW1haWxzdHlsZTI2O30NCnNwYW4ueWl2MjkwNzMzNjk4ZW1haWxzdHlsZTI3DQoJe21zby1z dHlsZS1uYW1lOnlpdjI5MDczMzY5OGVtYWlsc3R5bGUyNzt9DQpzcGFuLnlpdjI5MDczMzY5OGVt YWlsc3R5bGUyOA0KCXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThlbWFpbHN0eWxlMjg7fQ0K c3Bhbi55aXYyOTA3MzM2OThlbWFpbHN0eWxlMjkNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjkwNzMz Njk4ZW1haWxzdHlsZTI5O30NCnNwYW4ueWl2MjkwNzMzNjk4ZW1haWxzdHlsZTMwDQoJe21zby1z dHlsZS1uYW1lOnlpdjI5MDczMzY5OGVtYWlsc3R5bGUzMDt9DQpzcGFuLnlpdjI5MDczMzY5OGVt YWlsc3R5bGUzMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThlbWFpbHN0eWxlMzE7fQ0K cC55aXYyOTA3MzM2OThtc29ub3JtYWwxLCBsaS55aXYyOTA3MzM2OThtc29ub3JtYWwxLCBkaXYu eWl2MjkwNzMzNjk4bXNvbm9ybWFsMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThtc29u b3JtYWwxOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi55aXYy OTA3MzM2OThtc29oeXBlcmxpbmsxDQoJe21zby1zdHlsZS1uYW1lOnlpdjI5MDczMzY5OG1zb2h5 cGVybGluazE7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4ueWl2MjkwNzMzNjk4bXNvaHlwZXJsaW5rZm9sbG93ZWQxDQoJe21zby1zdHlsZS1uYW1lOnlp djI5MDczMzY5OG1zb2h5cGVybGlua2ZvbGxvd2VkMTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLnlpdjI5MDczMzY5OG1zb3BsYWludGV4dDEsIGxpLnlp djI5MDczMzY5OG1zb3BsYWludGV4dDEsIGRpdi55aXYyOTA3MzM2OThtc29wbGFpbnRleHQxDQoJ e21zby1zdHlsZS1uYW1lOnlpdjI5MDczMzY5OG1zb3BsYWludGV4dDE7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpwLnlpdjI5MDczMzY5OG1zb2FjZXRhdGUxLCBsaS55 aXYyOTA3MzM2OThtc29hY2V0YXRlMSwgZGl2LnlpdjI5MDczMzY5OG1zb2FjZXRhdGUxDQoJe21z by1zdHlsZS1uYW1lOnlpdjI5MDczMzY5OG1zb2FjZXRhdGUxOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLnlpdjI5MDczMzY5OGh0bWxwcmVmb3JtYXR0ZWRjaGFy MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThodG1scHJlZm9ybWF0dGVkY2hhcjE7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLnlpdjI5MDczMzY5OHBsYWludGV4dGNo YXIxDQoJe21zby1zdHlsZS1uYW1lOnlpdjI5MDczMzY5OHBsYWludGV4dGNoYXIxOw0KCWZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30NCnNwYW4ueWl2MjkwNzMzNjk4YmFsbG9vbnRl eHRjaGFyMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThiYWxsb29udGV4dGNoYXIxOw0K CWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30NCnNwYW4ueWl2MjkwNzMzNjk4ZW1h aWxzdHlsZTIzMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThlbWFpbHN0eWxlMjMxOw0K CWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi55aXYyOTA3MzM2OThlbWFpbHN0eWxlMjQxDQoJe21zby1zdHlsZS1uYW1lOnlpdjI5MDcz MzY5OGVtYWlsc3R5bGUyNDE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzAwMjA2MDt9DQpzcGFuLnlpdjI5MDczMzY5OGVtYWlsc3R5bGUyNTENCgl7bXNvLXN0 eWxlLW5hbWU6eWl2MjkwNzMzNjk4ZW1haWxzdHlsZTI1MTsNCglmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4ueWl2MjkwNzMzNjk4ZW1haWxz dHlsZTI2MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThlbWFpbHN0eWxlMjYxOw0KCWZv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMwMDIwNjA7fQ0Kc3Bhbi55 aXYyOTA3MzM2OThlbWFpbHN0eWxlMjcxDQoJe21zby1zdHlsZS1uYW1lOnlpdjI5MDczMzY5OGVt YWlsc3R5bGUyNzE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLnlpdjI5MDczMzY5OGVtYWlsc3R5bGUyODENCgl7bXNvLXN0eWxlLW5h bWU6eWl2MjkwNzMzNjk4ZW1haWxzdHlsZTI4MTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4ueWl2MjkwNzMzNjk4ZW1haWxzdHlsZTI5 MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyOTA3MzM2OThlbWFpbHN0eWxlMjkxOw0KCWZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi55aXYyOTA3 MzM2OThlbWFpbHN0eWxlMzAxDQoJe21zby1zdHlsZS1uYW1lOnlpdjI5MDczMzY5OGVtYWlsc3R5 bGUzMDE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzAwMjA2 MDt9DQpzcGFuLnlpdjI5MDczMzY5OGVtYWlsc3R5bGUzMTENCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MjkwNzMzNjk4ZW1haWxzdHlsZTMxMTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnAueWl2MjkwNzMzNjk4bXNvY2hwZGVmYXVsdDEsIGxpLnlp djI5MDczMzY5OG1zb2NocGRlZmF1bHQxLCBkaXYueWl2MjkwNzMzNjk4bXNvY2hwZGVmYXVsdDEN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2MjkwNzMzNjk4bXNvY2hwZGVmYXVsdDE7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTU1DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxp bms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGV5IEJpbGwsPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5JdCBtaWdodCBiZSBpbiBnZW5lcmFsIGZvciBzb21lIGVycm9yIGNvbmRpdGlvbnMgKHN1Y2gg YXMgc2xvdyBkb3duKS4gSSB0aGluayB0aGUgY3VycmVudCBwcm9wb3NhbCBvZmZlcnMgYSBnb29k IGJhbGFuY2UgYmV0d2VlbiByZXVzaW5nIEhUVFAgY29kZXMgYW5kIGRlZmluaW5nIG1vcmUgZGV0 YWlsZWQgZXJyb3IgY29kZXMgZm9yIHRoZSBjb21tb24gNDAxLzQwMCBlcnJvcnMuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5UaGUgaXNzdWUgaGVyZSBpcyBhYm91dCBuZXcgSFRUUCBhdXRoZW50aWNhdGlv biBzY2hlbWVzLCBob3cgdGhleSByZWxhdGUgYmFjayB0byBPQXV0aCwgYW5kIGhvdyB0aGV5IG1p Z2h0IHNoYXJlIGVycm9yIGNvZGVzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVITDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiJz4gV2lsbGlhbSBKLiBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1p bmMuY29tXSA8YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxMSAxMjoyMCBQ TTxicj48Yj5Ubzo8L2I+IEVyYW4gSGFtbWVyLUxhaGF2OyBNaWtlIEpvbmVzOyBPQXV0aCBXRzxi cj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gSW4gdGhlIHNwaXJpdCBvZiBjb21wcm9t aXNlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj b2xvcjpibGFjayc+Rm9yIEhUVFAgYXV0aGVudGljYXRpb24gdGhpbmdzLCBpcyB0aGUgcmlnaHQg cGxhY2UgdG8gc2ltcGxlIGRlZmluZSBhIG5ldyBIVFRQIHN0YXR1cyBjb2RlIHRoYXQgZG9lcyB3 aGF0IHdlIG5lZWQ/Jm5ic3A7IFRoZXJlIGlzIGFscmVhZHkgYSByZWdpc3RyeSBmb3IgdGhhdCBh bmQgdGhlICZxdW90O3Nsb3cgZG93biZxdW90OyBleGFtcGxlIGlzIG9uZSB0aGF0IG1pZ2h0IG1h a2Ugc2Vuc2UgaW4gdGhlIG1vcmUgZ2VuZXJhbCBIVFRQIGNvbnRleHQuPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndo aXRlJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48ZGl2IGNsYXNzPU1z b05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48aHIgc2l6ZT0xIHdpZHRoPSIxMDAlIiBhbGlnbj1j ZW50ZXI+PC9zcGFuPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRv bToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IEVyYW4gSGFtbWVyLUxhaGF2ICZsdDtlcmFuQGh1 ZW5pdmVyc2UuY29tJmd0Ozxicj48Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbSZndDs7IE9BdXRoIFdHICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+ PGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCA3LCAyMDExIDExOjIwIEFNPGJyPjxiPlN1Ympl Y3Q6PC9iPiBSZTogW09BVVRILVdHXSBJbiB0aGUgc3Bpcml0IG9mIGNvbXByb21pc2U8L3NwYW4+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdiBpZD15 aXYyOTA3MzM2OTg+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkhpIE1pa2UsPC9zcGFuPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNr Z3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SSBkb27igJl0IHRoaW5r IHRoaXMgaXMgYSBtYXR0ZXIgb2YgZWFjaCBvbmUgZ2l2aW5nIHVwIHNvbWV0aGluZy48L3NwYW4+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5JIGhhdmUgc2ln bmlmaWNhbnQgdGVjaG5pY2FsIHJlYXNvbnMgZm9yIG15IHBvc2l0aW9uLCBhbmQgSSBhbSBtdWNo IG1vcmUgaW50ZXJlc3RlZCBpbiB0YWtpbmcgdGhlIHRpbWUgZGlzY3Vzc2luZyB0aGVzZSB0aGFu IGp1c3QgZmluZGluZyBhbiBlYXN5IHdheSB0byBjbG9zZSBpc3N1ZXMuIFRoZXJlIGlzIG5vIHJl YXNvbiB0byBleHBlY3QgYSB0aG9yb3VnaCBkaXNjdXNzaW9uIHRha2luZyBtb3JlIHRoYW4gYSB3 ZWVrIG9yIHR3bywgd2hpY2ggd2lsbCBzdGlsbCBiZSBmYXN0ZXIgdGhhbiB0aGUgdGltZSBpdCB3 aWxsIHRha2UgdG8gZmluaXNoIHJldmlldyBvbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg c2VjdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz5BZGRpbmcgYW4gZXJyb3IgcmVnaXN0cnkgZm9yIGVycm9yIGNvZGVzIHVzZWQgYnkgdGhl IHZhcmlvdXMgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIGZvciB1c2UgaW4gNDAxIHJlc3Bv bnNlcyBpbiB0aGUgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIgZG9lcyBub3QgbWFrZSB0ZWNobmlj YWwgc2Vuc2UgZm9yIHRoZSB2MiBzcGVjaWZpY2F0aW9uIGFzIGl0IGN1cnJlbnRseSBzdGFuZC4g SXQgd291bGQgb25seSBtYWtlIHNlbnNlIGlmIHdlIHdlcmUgdG8gZGVmaW5lIGEgbWFzdGVyIEhU VFAgYXV0aGVudGljYXRpb24gc2NoZW1lIGNhbGxlZCBPQXV0aDIgKG9yIHNpbWlsYXIpIGFuZCBy ZXF1aXJlIHRoYXQgZXZlcnkgbmV3IHRva2VuIHR5cGUgdXNlcyB0aGF0IHNjaGVtZSB3aXRoIGEg c3ViLXNjaGVtZS4gVGhlbiwgc3VjaCBhbiBlcnJvciByZWdpc3RyeSB3aWxsIG1ha2Ugc2Vuc2Uu PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Rm9y IGV4YW1wbGU6PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndo aXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+QXV0aG9yaXphdGlvbjogT0F1dGgyIHR5cGU94oCdYmVhcmVy4oCdLCB0b2tlbj3igJ1h c2RhbHNpamRsa2FzamTigJ08L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tn cm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5BdXRob3JpemF0aW9uOiBP QXV0aDIgdHlwZT3igJ1tYWPigJ0sIGlkPeKAnWFzZGFzZGFzZOKAnSwgZXRj4oCmPC9zcGFuPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SWYgeW91IGhhdmUg dXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgZm9yIGludHJvZHVjaW5nIHN1Y2ggYSBuZXcgbWFz dGVyIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lLCBwbGVhc2UgcHJlc2VudCB0aGVtIGFuZCB3 ZSB3aWxsIGhhdmUgYSBkaXNjdXNzaW9uIGFib3V0IGhvdyB0byBiZXN0IGFkZHJlc3MgdGhlbSwg aW5jbHVkaW5nIHRoZSBwb3NzaWJpbGl0eSBvZiBhZGRpbmcgc3VjaCBhIHNjaGVtZS4gSW4gdGhl IHBhc3QsIHN1Y2ggYSBwcm9wb3NhbCB3YXMgcmVqZWN0ZWQgZHVlIHRvIGxhY2sgb2Ygd29ya2lu ZyBncm91cCBjb25zZW5zdXMuIElmIEkgcmVjYWxsIGNvcnJlY3RseSwgb25seSBNYXJpdXMgd2Fz IGFkdm9jYXRpbmcgdGhhdCBhcHByb2FjaC48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz5BbHRlcm5hdGl2ZWx5LCBpZiB5b3UgaGF2ZSB1c2UgY2Fz ZXMgb3IgcmVxdWlyZW1lbnRzIGZvciBpbnRyb2R1Y2luZyBqdXN0IHRoZSBXV1ctQXV0aGVudGlj YXRlIHNpZGUgb2YgYW4gT0F1dGgyIGF1dGhvcml6YXRpb24gc2NoZW1lICh5b3VyIG9wZW4gaXNz dWUpLCB3aGljaCBpbmNsdWRlcyBhbiDigJhlcnJvcuKAmSBhdHRyaWJ1dGUgZm9yIHVzZSB3aXRo IHRoZSBwcm9wb3NlZCByZWdpc3RyeSwgcGxlYXNlIHByZXNlbnQgdGhvc2UgYW5kIGV4cGxhaW4g aG93IGl0IHdpbGwgd29yayBhbG9uZ3NpZGUgdGhlIEJlYXJlciBhbmQgTUFDIHNjaGVtZXMgKGFz IGN1cnJlbnRseSBkcmFmdGVkKS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz5UaGFua3MsPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+RUhMPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dDtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yIC1t b3otdXNlLXRleHQtY29sb3IgYmx1ZSc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjti b3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yJz48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IE1pa2UgSm9uZXMg W21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21dIDxicj48Yj5TZW50OjwvYj4gVGh1 cnNkYXksIEFwcmlsIDA3LCAyMDExIDk6NTMgQU08YnI+PGI+VG86PC9iPiBFcmFuIEhhbW1lci1M YWhhdjsgT0F1dGggV0c8YnI+PGI+U3ViamVjdDo8L2I+IEluIHRoZSBzcGlyaXQgb2YgY29tcHJv bWlzZTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dy b3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMDAyMDYwJz5IYXZpbmcgdGhvdWdodCBhYm91dCBp dCBvdmVyIG5pZ2h0IGFuZCBkaXNjdXNzZWQgaXQsIEnigJltIHdpbGxpbmcgdG8gZHJvcCBteSBv YmplY3Rpb24gdGhlIFdXVy1BdXRoZW50aWNhdGUgcmVzcG9uc2Ugbm90IGJlaW5nIGluIHRoZSBm cmFtZXdvcmsgc3BlY2lmaWNhdGlvbiwgc28gYXMgdG8gY2xvc2UgYW4gb3BlbiBpc3N1ZSB0aGF0 IGNvdWxkIGRlbGF5IGNvbXBsZXRpb24gb2YgdGhlIHNwZWNpZmljYXRpb25zLjwvc3Bhbj48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Nv bG9yOiMwMDIwNjAnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMwMDIwNjAnPkVyYW4sIGluIHJldHVy biwgSeKAmWQgbGlrZSB0byBhc2sgeW91IHRvIGRyb3AgeW91ciBvYmplY3Rpb24gdG8gZXh0ZW5k aW5nIHRoZSBlcnJvciByZWdpc3RyeSBpbiB0aGUgZnJhbWV3b3JrIHNwZWMgc28gdGhhdCDigJxy ZXNvdXJjZSBzZXJ2ZXIgZXJyb3IgcmVzcG9uc2XigJ0gaXMgaW4gdGhlIOKAnGVycm9yIHVzYWdl IGxvY2F0aW9u4oCdIGxpc3QuJm5ic3A7IElmIHlvdSBkbyBzbywgdGhpcyB3b3VsZCBjbG9zZSBh bm90aGVyIG9wZW4gaXNzdWUgdGhhdCBjb3VsZCBkZWxheSBjb21wbGV0aW9uIG9mIHRoZSBzcGVj aWZpY2F0aW9ucy48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMDAyMDYwJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFuayB5b3UsPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzAwMjA2MCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMDAyMDYwJz4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6LW1vei11c2Ut dGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yJz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IEVyYW4gSGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBo dWVuaXZlcnNlLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDA2LCAyMDEx IDQ6MzUgUE08YnI+PGI+VG86PC9iPiBNaWtlIEpvbmVzOyBPQXV0aCBXRzxicj48Yj5TdWJqZWN0 OjwvYj4gT0F1dGgyIHNjaGVtZSAod2FzIEVycm9yIHJlZ2lzdHJ5IHByb3Bvc2FsIChyb3VuZCAz KSk8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndo aXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+V2VsbOKApiBDYW7igJl0IHNheSBJIGRp ZG7igJl0IHNlZSB0aGlzIGNvbWluZyA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5Oldp bmdkaW5ncztjb2xvcjojMUY0OTdEJz5KPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+VGhlIGlzc3VlIGlzIG5vdCBzaW1wbHkgYWJvdXQgcHV0dGlu ZyBhIHNlY3Rpb24gYmFjaywgYnV0IGFib3V0IHRoZSBvdmVyYWxsIHByb3RvY29sIGFyY2hpdGVj dHVyZSBhbmQgaG93IGl0IGNvbXBsaWVzIHdpdGggSFRUUC48L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5Gb3IgZXhhbXBsZSwgdGFraW5nIHRoZSBN QUMgZHJhZnQsIGhvdyBkbyB5b3UgZW52aXNpb24gdGhlIHJlc291cmNlIHNlcnZlciByZXNwb25k aW5nIHRvIGEgZmFpbGVkIGF1dGhlbnRpY2F0aW9uIGF0dGVtcHQ/IEEgNDAxIHJlc3BvbnNlIGFu ZCB3aGF0IGhlYWRlcihzKT8gV1dXLUF1dGhlbnRpY2F0ZSB3aXRoIOKAmE9BdXRoMuKAmSBzY2hl bWU/IOKAmE1BQ+KAmSBzY2hlbWU/IEJvdGg/PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+QWxzbyBzZWU6IDxhIGhyZWY9Imh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL3dnL2h0dHBiaXMvdHJhYy90aWNrZXQvNzgiPmh0dHA6Ly90cmFjLnRvb2xz LmlldGYub3JnL3dnL2h0dHBiaXMvdHJhYy90aWNrZXQvNzg8L2E+PC9zcGFuPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5k OndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+WW91IG1pZ2h0IHRoaW5rIHlvdSBh cmUgYXNraW5nIGZvciBhIHNpbXBsZSBmZWF0dXJlLCBidXQgdGhpcyBpcyBtb3ZpbmcgdGhlIHBy b3RvY29sIGZyb20gYSBwdXJlbHkgYXV0aG9yaXphdGlvbiBwcm90b2NvbCB0byBhbiBhdXRoZW50 aWNhdGlvbiBwcm90b2NvbCB3aGljaCBpcyB3aGF0IHRoZSBzcGxpdCBvZiB0aGUgdG9rZW4gdHlw ZXMgd2FzIGRlc2lnbmVkIHRvIGFjY29tcGxpc2guPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+V2hhdCBJIGFtIGFza2luZyBmb3IgaXMgdG8gcHJv dmlkZSBmdWxsIGV4YW1wbGVzIG9mIGhvdyB5b3UgZW52aXNpb24gdGhlIE9BdXRoMiBzY2hlbWUg dG8gd29yayBpbiBwcmFjdGljZSwgZXNwZWNpYWxseSBjb25zaWRlcmluZyB0aGUgTUFDIGRyYWZ0 LiBBc3N1bWUgdGhhdCB0aGUgTUFDIGRyYWZ0LCBzaW5jZSBpdCBpcyBkZWZpbmVkIGFzIGEgZ2Vu ZXJhbCBwdXJwb3NlIHNjaGVtZSwgaXMgbm90IGdvaW5nIHRvIGNoYW5nZSAoZm9yIHRoZSBzYWtl IG9mIGFyZ3VtZW50IG9ubHkpLCBkbyB5b3UgZW52aXNpb24gaXQgYmVpbmcgdXNlZCBkaWZmZXJl bnRseSB3aGVuIGNvbWJpbmVzIHdpdGggYW4gT0F1dGggYWNjZXNzIHRva2VuPyBUaGF0IHdvdWxk IGJlIGJhZC48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz5JIHJlbW92ZWQgdGhlIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVyIGFuZCB0aGUgT0F1dGgy IHNjaGVtZSBiZWNhdXNlIGl0IHNlcnZlZCBubyBwdXJwb3NlIGFuZCBubyBvbmUgZGVtb25zdHJh dGVkIGhvdyBpdCB3aWxsIGJlIGFjdHVhbGx5IHVzZWQuIFdSQVAgaXMgbm90IGEgZ29vZCBleGFt cGxlIGJlY2F1c2UgV1JBUCBpcyBhIGNsb3NlZCBwcm90b2NvbCAoanVzdCBsaWtlIE9BdXRoIDEu MCkuIFRoZXJlIGlzIG5vIHdheSB0byBhZGQgbmV3IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgdG8g V1JBUCBhbmQgaW4gdGhhdCBjb250ZXh0LCBpdCBtYWtlcyBzZW5zZSB0byBkZWZpbmUgYSBzY2hl bWUuIEJ1dCBoZXJlIGl0IHdpbGwgbWVhbiBtb3ZpbmcgYmFja3dhcmRzIHRvIGEgcHJvdG9jb2wg d2hlcmUgb25seSBPQXV0aC1zcGVjaWZpYyBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIGNhbiBiZSB1 c2VkLCBhbmQgdGhleSBhbGwgbXVzdCBiZSBkZWZpbmVkIGFzIGV4dGVuc2lvbnMgb2YgdGhpcyBt YXN0ZXIgT0F1dGgyIHNjaGVtZS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz5UaGVyZSB3YXMgcHJldHR5IGdvb2QgY29uc2Vuc3VzIG5vdCB0byBk ZWZpbmUgYSBtYXN0ZXIgc2NoZW1lIHdpdGggc3ViIHNjaGVtZXMuIFRoYXQgaXMgd2VsbCBkb2N1 bWVudGVkIG9uIHRoZSBsaXN0LiBUaGlzIHRocmVhZCBpbmNsdWRlZCB0aGUgZGlzY3Vzc2lvbiBh Ym91dCB1c2luZyBhIGNvbW1vbiBwcmVmaXggZm9yIHNjaGVtZSBuYW1lcywgZXRjLiBIb3BlIHdl IGRvbuKAmXQgaGF2ZSB0byByZXBlYXQgdGhhdC48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5TbyBpZiBPQXV0aDIgaXMgbm90IGEgbWFzdGVyIHNj aGVtZSBmb3IgYWxsIG90aGVyIHNjaGVtZSB0byBiZSBkZWZpbmVkIGFzIHN1Yi1zY2hlbWVzLCB3 aGF0IGlzIGl0PyBJIGRvbuKAmXQgaGF2ZSBhbiBhbnN3ZXIgYW5kIHdlIGtpbmRhIG5lZWQgb25l IHRvIHB1dCBzdWNoIGEgc2NoZW1lIGJhY2sgaW4gdGhlIGRvY3VtZW50Ljwvc3Bhbj48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dy b3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkVITDwvc3Bhbj48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCB3aW5kb3d0ZXh0IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7Ym9yZGVyLWNv bG9yOi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvciYjMTM7JiMxMDsgLW1v ei11c2UtdGV4dC1jb2xvciBibHVlJz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2Jv cmRlci1jb2xvcjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3InPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gTWlrZSBKb25lcyBb bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBXZWRu ZXNkYXksIEFwcmlsIDA2LCAyMDExIDQ6MTMgUE08YnI+PGI+VG86PC9iPiBFcmFuIEhhbW1lci1M YWhhdjsgT0F1dGggV0c8YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBFcnJvciByZWdpc3RyeSBwcm9w b3NhbCAocm91bmQgMyk8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzAwMjA2MCc+QWN0dWFsbHksIHlv dSBjb3JyZWN0bHkgcG9pbnQgb3V0IChpbmRpcmVjdGx5KSwgdGhhdCB0aGlzIGlzIHJlbGF0ZWQg dG8gb25lIG9mIHRoZSBvcGVuIGlzc3VlcyB0aGF0IG5lZWRzIHRvIGJlIHJlc29sdmVkIHRvIGNv bXBsZXRlIHRoZSBzcGVjcyB3aGVuIHlvdSB3cm90ZSDigJw8L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPkZvciBzdWNoIGEgcmVnaXN0cnkgdG8gYmUgdXNlZnVsLCB5b3UgYWxzbyBu ZWVkIHRvIHN0YW5kYXJkaXplIHRoZSBhdXRoZW50aWNhdGlvbiBoZWFkZXIgYWNyb3NzIGFsbCBz Y2hlbWVzIGFuZCBkZWZpbmUgYSBzdGFuZGFyZCBwYXJhbWV0ZXIgdXNlZCB0byBkZWxpdmVyIHN1 Y2ggZXJyb3IgY29kZXM8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOiMwMDIwNjAnPuKAnS48L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdjb2xvcjojMDAyMDYwJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMDAyMDYwJz5UaGlzIG9w ZW4gaXNzdWUgKHdoaWNoIHRoZXJlIHdhc27igJl0IHRpbWUgdG8gZGlzY3VzcyBkdXJpbmcgbGFz dCB3ZWVr4oCZcyBtZWV0aW5nKSB3YXMgdGhlIHJlbW92YWwgb2YgdGhlIFdXVy1BdXRoZW50aWNh dGUgUmVzcG9uc2UgSGVhZGVyLiAmbmJzcDtUaGlzIGZlYXR1cmUgd2FzIHByZXNlbnQgaW4gV1JB UCBhbmQgZWFybGllciBPQXV0aCBkcmFmdHMgYnV0IHdhcyByZW1vdmVkIHdpdGhvdXQgYSBjbGVh ciBjb25zZW5zdXMgdG8gZG8gc28uJm5ic3A7IEFuZCBpbmRlZWQsIGR1cmluZyBvdXIgcHJpdmF0 ZSBkaXNjdXNzaW9ucyBvbiBob3cgdGhlIGRyYWZ0IHNob3VsZCBiZSBzcGxpdCwgYXQgdGhhdCB0 aW1lLCB5b3UgdG9vayB0aGUgcG9zaXRpb24gdGhhdCB0aGUgV1dXLUF1dGhlbnRpY2F0ZSByZXNw b25zZSBzaG91bGQgcmVtYWluIGluIHRoZSBmcmFtZXdvcmsgc3BlYy48L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjoj MDAyMDYwJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMDAyMDYwJz5UaGUgcmVzdWx0IGhhcyBiZWVu IHRoYXQgdGhlcmUgaXMgZGlmZmVyZW50IGFuZCBpbmNvbXBhdGlibGUgV1dXLUF1dGhlbnRpY2F0 ZSByZXNwb25zZSBmdW5jdGlvbmFsaXR5IGluIG11bHRpcGxlIHJlbGF0ZWQgZHJhZnRzIOKAkyBz cGVjaWZpY2FsbHkgZHJhZnQtaGFtbWVyLW9hdXRoLXYyLW1hYy10b2tlbi0wMiBhbmQgZHJhZnQt aWV0Zi1vYXV0aC12Mi1iZWFyZXItMDQuJm5ic3A7IEludGVyb3BlcmFiaWxpdHkgYW5kIGRldmVs b3BlcnMgd291bGQgYm90aCBiZSBiZXR0ZXIgc2VydmVkIGJ5IG1vdmluZyB0aGlzIGZ1bmN0aW9u YWxpdHkgYmFjayBpbnRvIHRoZSBjb3JlLiBJIGRvbuKAmXQgYmVsaWV2ZSB0aGF0IGVhY2ggcmVs YXRlZCBPQXV0aCBzcGVjaWZpY2F0aW9uIHNob3VsZCBoYXZlIHRvIHNlcGFyYXRlbHkgc3BlY2lm eSB0aGlzIGZ1bmN0aW9uYWxpdHkuJm5ic3A7IEFzIHRoaXMgd2FzIG5vdCBkaXNjdXNzZWQgZHVy aW5nIGxhc3Qgd2Vla+KAmXMgbWVldGluZywgYSBjb25zZW5zdXMgY2FsbCBmcm9tIHRoZSBjaGFp cnMgbWF5IGJlIG5lY2Vzc2FyeSB0byByZXNvbHZlIHRoaXMgaXNzdWUuPC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6 IzAwMjA2MCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Y29sb3I6IzAwMjA2MCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47 Ym9yZGVyLWNvbG9yOi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvcic+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiBFcmFuIEhhbW1l ci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dIDxicj48Yj5TZW50OjwvYj4gV2Vk bmVzZGF5LCBBcHJpbCAwNiwgMjAxMSAzOjU4IFBNPGJyPjxiPlRvOjwvYj4gTWlrZSBKb25lczsg T0F1dGggV0c8YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBFcnJvciByZWdpc3RyeSBwcm9wb3NhbCAo cm91bmQgMyk8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+UHV0dGluZyBhc2lkZSBteSB2 aWV3IHRoYXQgYSByZWdpc3RyeSBmb3IgcmVzb3VyY2Ugc2VydmVyIGVycm9yIHJlc3BvbnNlcyBh Y3Jvc3MgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIGlzbuKAmXQgdmVyeSB1c2VmdWwgb3Ig aW50ZXJlc3RpbmcsIEkgZG9u4oCZdCBoYXZlIGFuIG9iamVjdGlvbiB0byB0aGUgYmVhcmVyIHRv a2VuIHNwZWNpZmljYXRpb24gZGVmaW5pbmcgc3VjaCBnZW5lcmFsIHB1cnBvc2UgcmVnaXN0cnku IEluIGEgd2F5LCBpdCBpcyBzaW1pbGFyIHRvIHRoZSBlcnJvciByZXNwb25zZSBoZWFkZXJzIGRl ZmluZWQgYnkgRGlnZXN0LCBvbmx5IG5ldmVyIG1hZGUgZ2VuZXJhbGx5IGFwcGxpY2FibGUuPC9z cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhlIGRp ZmZlcmVuY2UgaW4gb3VyIGFwcHJvYWNoZXMgaXMgdGhhdCBJIGRvbuKAmXQgY29uc2lkZXIgdGhl IGJlYXJlciB0b2tlbiBvciBtYWMgdG9rZW4gc3BlY3MgdG8gYmUgZXh0ZW5zaW9ucyBvZiB0aGUg djIgc3BlYywgYnV0IGZ1bGx5IHNwZWNpZmllZCBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMg d2l0aCBPQXV0aCAyLjAgYmluZGluZyAoaS5lLiB0aGUgYWNjZXNzIHRva2VuIHR5cGUgcmVnaXN0 cmF0aW9uKS4gQmVjYXVzZSBvZiB0aGF0LCBJIGRvbuKAmXQgdGhpbmsgdGhlIHYyIHNwZWMgaXMg dGhlIHJpZ2h0IHBsYWNlIGZvciBzdWNoIGEgcmVnaXN0cnksIHdoaWNoIGlzIHJlYWxseSBhYm91 dCBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgYW5kIG5vdCBPQXV0aC4gVGhlcmVmb3JlLCBJ IHRoaW5rIGl0IHdpbGwgYmUgbW9yZSBjb25mdXNpbmcgdG8gcHV0IHN1Y2ggYSByZWdpc3RyeSBp biB2Mi48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUn PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz5J4oCZbGwgZ2l2ZSB5b3UgYW4gZXhhbXBsZS4gU3VwcG9zZSBzb21lb25lIHdpbGwgZGVmaW5l IGEgRGlnZXN0IGFjY2VzcyB0b2tlbiB0eXBlLiBXaGVuIGlzc3Vpbmcgb25lLCB0aGUgc2VydmVy IHdpbGwgc2VuZCBhbiBhY2Nlc3MgdG9rZW4gKHRvIGJlIHVzZWQgYXMgdXNlcm5hbWUpIGFuZCBh IHNlY3JldCAodG8gYmUgdXNlZCBhcyBwYXNzd29yZCkuIFRvIHVzZSBzdWNoIGEgdG9rZW4sIHRo ZSBjbGllbnQgd2lsbCB1c2UgdGhlIEhUVFAgRGlnZXN0IHNjaGVtZSAoYXMgaXMpLiBEaWdlc3Qg ZGVmaW5lcyBpdHMgb3duIHNldCBhbmQgbWV0aG9kIG9yIHNwZWNpZnlpbmcgZXJyb3IgY29kZS4g V291bGQgeW91IGV4cGVjdCB0aG9zZSB0byBiZSByZWdpc3RlcmVkIGluIHlvdXIgcHJvcG9zZWQg cmVnaXN0cnk/IEkgd291bGQgYXNzdW1lIG5vdC48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5Gb3Igc3VjaCBhIHJlZ2lzdHJ5IHRvIGJlIHVzZWZ1 bCwgeW91IGFsc28gbmVlZCB0byBzdGFuZGFyZGl6ZSB0aGUgYXV0aGVudGljYXRpb24gaGVhZGVy IGFjcm9zcyBhbGwgc2NoZW1lcyBhbmQgZGVmaW5lIGEgc3RhbmRhcmQgcGFyYW1ldGVyIHVzZWQg dG8gZGVsaXZlciBzdWNoIGVycm9yIGNvZGVzLiBIb3dldmVyLCB3ZSBhbHJlYWR5IG1vdmVkIGF3 YXkgZnJvbSB0aGF0IGRlc2lnbiBieSBkZWZpbmluZyBzZXBhcmF0ZSBIVFRQIGF1dGhlbnRpY2F0 aW9uIHNjaGVtZXMgZm9yIGVhY2ggdG9rZW4gdHlwZS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUn PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5CdXQgYWdhaW4sIEkgZG9u4oCZdCBoYXZlIGFu IG9iamVjdGlvbiB0byBzdWNoIGEgcmVnaXN0cnkgZGVmaW5lZCBpbiB0aGUgYmVhcmVyIHRva2Vu IHNwZWMuIEkgaGF2ZSBubyBpbnRlbnRpb25zIG9mIHVzaW5nIGl0IGZvciBhbnkgSFRUUCBhdXRo ZW50aWNhdGlvbiBzY2hlbWUgSSBwbGFuIHRvIGF1dGhvci48L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+RUhMPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRl Jz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdDtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0 LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3IgYmx1ZSc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbjtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNv bG9yJz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IE1p a2UgSm9uZXMgW21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21dIDxicj48Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAwNiwgMjAxMSAzOjM5IFBNPGJyPjxiPlRvOjwvYj4gRXJh biBIYW1tZXItTGFoYXY7IE9BdXRoIFdHPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogRXJyb3IgcmVn aXN0cnkgcHJvcG9zYWwgKHJvdW5kIDMpPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMwMDIwNjAnPlRo ZSBwcm9ibGVtIHdpdGggdGhhdCBzaXR1YXRpb24gaXMgdGhhdCBpdCBkb2VzbuKAmXQgcHJvdmlk ZSBhIGNlbnRyYWwgcmVnaXN0cnkgZm9yIHJlc291cmNlIHNlcnZlciBlcnJvciByZXNwb25zZXMg YWNyb3NzIHNwZWNzLCB1bmxpa2UgdGhlIG90aGVyIGtpbmRzIG9mIE9BdXRoIGVycm9yIHJlc3Bv bnNlcy4mbmJzcDsgSSBjb3VsZCBkZWZpbmUgdGhhdCByZWdpc3RyeSBpbiB0aGUgYmVhcmVyIHRv a2VuIHNwZWMsIGJ1dCBpdCB3b3VsZCBiZSBsZXNzIGNvbmZ1c2luZyB0byB1bmlmeSBpdCB3aXRo IHRoZSBwcm9wb3NlZCByZWdpc3RyeSBpbiB0aGUgZnJhbWV3b3JrIHNwZWMuJm5ic3A7IEkgc3Vz cGVjdCBkZXZlbG9wZXJzIHdvdWxkIHRoYW5rIHVzIGZvciBkb2luZyB0aGF0Ljwvc3Bhbj48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Nv bG9yOiMwMDIwNjAnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMwMDIwNjAnPldoYXQgZG8geW91IHNh eT88L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdjb2xvcjojMDAyMDYwJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMDAyMDYwJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9y OiMwMDIwNjAnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRl ci1jb2xvcjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3InPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48Yj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpi bGFjayc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gRXJhbiBIYW1tZXItTGFo YXYgW21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXSA8YnI+PGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgQXByaWwgMDYsIDIwMTEgMjo1OCBQTTxicj48Yj5Ubzo8L2I+IE1pa2UgSm9uZXM7IE9BdXRo IFdHPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogRXJyb3IgcmVnaXN0cnkgcHJvcG9zYWwgKHJvdW5k IDMpPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkhpIE1pa2UsPC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhpcyBpcyBpbnRlbnRpb25h bC4gVGhlIGVycm9yIHJlZ2lzdHJ5IGRlZmluZWQgaW4gdjIgaXMgbm90IGRlc2lnbmVkIHRvIHJl Y29yZCBlcnJvcnMgZm9yIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UgZW5kcG9pbnQgcmVzcG9uc2Ug b3IgdGhlIFdXVy1BdXRoZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyIHdoZW4gdXNlZCB3aXRoIHRo ZSBCZWFyZXIgdG9rZW4gc2NoZW1lIChvciBhbnkgb3RoZXIgc2NoZW1lKS48L3NwYW4+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tn cm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5UaGUgb25seSBwdXJwb3Nl IG9mIHRoZSByZWdpc3RyeSBpcyB0byBhdm9pZCBuYW1lIGNvbGxpc2lvbnMgYmV0d2VlbiB0d28g ZXJyb3JzIHVzZWQgZGlmZmVyZW50bHkgd2l0aCB0aGUgdjIgc3BlY2lmaWNhdGlvbi4gU2luY2Ug ZXJyb3JzIHVzZWQgd2l0aCB0aGUgQmVhcmVyIHRva2VuIHNjaGVtZSB3aWxsIG5ldmVyIGFwcGVh ciBpbiB0aGUgc2FtZSBwbGFjZSBhcyB0aGUgdjIgZW5kcG9pbnRzLCB0aGVyZSBpcyBubyBuZWVk IGZvciBjb21iaW5pbmcgdGhlc2UgdHdvIHJlZ2lzdHJpZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndo aXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SWYgdGhlIGJlYXJlciB0b2tlbiBzcGVj aWZpY2F0aW9uIHJlcXVpcmVzIGVycm9yIGV4dGVuc2liaWxpdHksIHlvdSBzaG91bGQgcmV0YWlu IHRoZSByZWdpc3RyeSB0aGVyZSBhbmQgbGltaXQgaXQgdG8ganVzdCB0aGUgcHJvdGVjdGVkIHJl c291cmNlIHJlc3BvbnNlIHNwYWNlLiBJZGVhbGx5LCB5b3Ugd291bGQgbGltaXQgaXQgdG8ganVz dCB0aGUgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIg4oCYZXJyb3LigJkgcGFyYW1ldGVyIHdoZW4g dXNlZCB3aXRoIHRoZSBCZWFyZXIgc2NoZW1lLiBUaGUgTUFDIHNjaGVtZSBkb2VzIG5vdCB1c2Ug ZXJyb3IgY29kZXMsIGJ1dCBpbnN0ZWFkLCByZWxpZXMgZnVsbHkgb24gSFRUUCBzdGF0dXMgY29k ZSBzaW5jZSBubyBhZGRpdGlvbmFsIGVycm9yIGNvbmRpdGlvbnMgd2VyZSBpZGVudGlmaWVkLjwv c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkFsc28s IHNpbmNlIHlvdXIgQUJORiBwZXJtaXRzIGFkZGluZyBhZGRpdGlvbmFsIEF1dGhvcml6YXRpb24g aGVhZGVyIHBhcmFtZXRlcnMsIHlvdSBtaWdodCB3YW50IHRvIGNvbnNpZGVyIGRlZmluaW5nIGEg cHJvY2VzcyBmb3IgZG9pbmcgdGhhdCwgaWYgeW91IGFyZSBnb2luZyB0byBkZWZpbmUgYW4gZXJy b3IgcmVnaXN0cnkuIEN1cnJlbnRseSwgdG8gYWRkIGFkZGl0aW9uYWwgcGFyYW1ldGVycywgb25l IGhhcyB0byB1cGRhdGUgdGhlIEJlYXJlciB0b2tlbiBSRkMsIGluIGNvbnRyYXN0IHRvIHNpbXBs eSByZWdpc3RlcmluZyBhIG5ldyBlcnJvciBjb2RlICh3aGljaCBpcyBsaWtlbHkgdG8gY29tZSBv dXQgb2YgYSBuZXcgcGFyYW1ldGVyKS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz5FSEw8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 O2JvcmRlci1jb2xvcjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3IgLW1v ei11c2UtdGV4dC1jb2xvciBibHVlJz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2Jv cmRlci1jb2xvcjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3InPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gTWlrZSBKb25lcyBb bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBXZWRu ZXNkYXksIEFwcmlsIDA2LCAyMDExIDI6MjUgUE08YnI+PGI+VG86PC9iPiBFcmFuIEhhbW1lci1M YWhhdjsgT0F1dGggV0c8YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBFcnJvciByZWdpc3RyeSBwcm9w b3NhbCAocm91bmQgMyk8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzAwMjA2MCc+VGhhbmtzIGZvciB3 cml0aW5nIHRoaXMgdXAsIEVyYW4uJm5ic3A7IEkgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgYSBzdGVw IGluIHRoZSByaWdodCBkaXJlY3Rpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzAwMjA2MCc+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nY29sb3I6IzAwMjA2MCc+V2VhcmluZyBteSBCZWFyZXIgVG9rZW4gc3BlYyBlZGl0b3Ig aGF0LCBJIGp1c3QgdHJpZWQgdG8gZ28gdGhyb3VnaCB0aGUgZXhlcmNpc2Ugb2YgZWRpdGluZyBt eSBkb2N1bWVudCB0byB1c2UgdGhlIHJlZ2lzdHJ5IGluIGRyYWZ0IDE1IHRvIHJlZ2lzdGVyIHRo ZSBlcnJvcnMgZGVmaW5lZCBpbiB0aGUgYmVhcmVyIHRva2VuIHNwZWMgYW5kIEkgaGl0IGEgcm9h ZGJsb2NrLiZuYnNwOyBTcGVjaWZpY2FsbHksIHdoaWxlIHRoZSBlcnJvcnMgZGVmaW5lZCBieSBt eSBzcGVjIGFyZSByZXR1cm5lZCBieSByZXNvdXJjZSBzZXJ2ZXJzIChmbG93IEYgaW4gRmlndXJl IDEpLCB0aGUgcmVnaXN0cnkgZGVmaW5lZCBieSBkcmFmdCAxNSBkb2VzIG5vdCBpbmNsdWRlIOKA nHJlc291cmNlIHNlcnZlciBlcnJvciByZXNwb25zZeKAnSBpbiB0aGUg4oCcZXJyb3IgdXNhZ2Ug bG9jYXRpb27igJ0gbGlzdC4mbmJzcDsgQ2FuIHlvdSBwbGVhc2UgYWRkIHRoaXMgYWRkaXRpb25h bCBlcnJvciB1c2FnZSBsb2NhdGlvbiBzbyB0aGF0IHRoZSByZWdpc3RyeSBjYW4gYmUgdXNlZCBi eSB0aGUgYmVhcmVyIHRva2VuIHNwZWNpZmljYXRpb24/PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMwMDIwNjAnPkF0IHRo YXQgcG9pbnQsIEkgYmVsaWV2ZSB3ZeKAmWxsIGJlIGFibGUgdG8gY2xvc2UgdGhlIG9wZW4gaXNz dWUgYWJvdXQgdGhlIG5lZWQgZm9yIGFuIGVycm9yIHJlZ2lzdHJ5LCBhbmQgSeKAmWxsIHVwZGF0 ZSBteSBkcmFmdCBhY2NvcmRpbmdseS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMDAyMDYwJz4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdjb2xvcjojMDAyMDYwJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VGhhbmsgeW91LDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9y OiMwMDIwNjAnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRl ci1jb2xvcjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3InPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48Yj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpi bGFjayc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gb2F1dGgtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8 L2I+RXJhbiBIYW1tZXItTGFoYXY8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDA1LCAy MDExIDM6NTIgUE08YnI+PGI+VG86PC9iPiBPQXV0aCBXRzxicj48Yj5TdWJqZWN0OjwvYj4gW09B VVRILVdHXSBFcnJvciByZWdpc3RyeSBwcm9wb3NhbCAocm91bmQgMyk8L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPlRoZSBmb2xsb3dpbmcgaXMgbXkgbmV3IHByb3Bvc2FsLCBiYXNlZCBvbiBN aWtlIEpvbmVz4oCZIGFuZCBteSBlYXJsaWVyIHByb3Bvc2Fscy4gSXQgaXMgYmFzaWNhbGx5IGEg Y29tYmluYXRpb24gb2YgdGhlIHR3by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPlRoaXMgcHJvcG9zYWwgZG9lcyBub3QgYWxsb3cgZGVmaW5pbmcgbmV3IGVycm9yIGNv ZGVzIHVubGVzcyBhbm90aGVyIGV4dGVuc2lvbiBpcyBpbnZvbHZlZCAobmV3IGdyYW50IHR5cGUs IHJlcXVlc3QgcGFyYW1ldGVyLCB0b2tlbiB0eXBlKS4gVGhlIHJlYXNvbiBmb3Igbm90IGRlZmlu aW5nIGFuIG9wZW4gZW5kZWQgZXJyb3IgcmVnaXN0cnkgaXMgdGhhdCBkZWZpbmluZyBuZXcgZXJy b3IgY29kZXMgZm9yIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBpcyBiYWQgZm9yIGludGVyb3Bl cmFiaWxpdHkgYW5kIGNhbiBsZWFkIHRvIHVuZXhwZWN0ZWQgcmVzdWx0cyAoZGV2ZWxvcGVycyBu b3QgdGFraW5nIGludG8gYWNjb3VudCByZWNlaXZpbmcgYSBuZXcgZXJyb3Igd2hlbiB0YWxraW5n IHRvIGEgY29tcGxpYW50IDIuMCBzZXJ2ZXIpLiBXZSBkb24ndCBoYXZlIGFueSB1c2UgY2FzZXMg Zm9yIGRlZmluaW5nIHN1Y2ggbmV3IGVycm9ycyBmb3IgdGhlIHYyIHNwZWNpZmljYXRpb24uIE5l dyBlcnJvcnMgb25seSBjb21lIGZyb20gZXh0ZW5zaW9ucyBhbmQgbXVzdCBiZSBkZWZpbmVkIGlu IHRoYXQgY29udGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkkg aGF2ZSBhcHBsaWVkIHRvIGNoYW5nZXMgdG8gdGhlIC0xNCBkcmFmdCBhbmQgY2xlYXJseSBtYXJr ZWQgdGhlbSB3aXRoIFtbUGVuZGluZyBDb25zZW5zdXNdXSBzbyB0aGF0IHRoZXJlIGlzIG5vIGlz c3VlIHdpdGggcmVtb3ZpbmcgdGhlbSBvciBjaGFuZ2luZyB0aGVtIGxhdGVyLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+LS0tPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz5BZGQgdG8gdGhlIGVycm9yIGNvZGVzIGxpc3QgaW4gc2VjdGlvbnMg NC4xLjIuMSBhbmQgNC4yLjIuMTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSA0eHggb3IgNXh4IEhUVFAg c3RhdHVzIGNvZGUgKGV4Y2VwdCBmb3IgNDAwIGFuZCA0MDEpPC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBzZXQgdGhlICZxdW90 O2Vycm9yJnF1b3Q7IHBhcmFtZXRlcjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHZhbHVlIHRvIGEgbnVtZXJpY2FsIEhUVFAgc3RhdHVzIGNvZGUgZnJvbSB0aGUgNHh4IG9yIDV4 eDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xv cjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJhbmdlLCB3aXRoIHRoZSBleGNl cHRpb24gb2YgdGhlIDQwMCAoQmFkIFJlcXVlc3QpIGFuZDwvc3Bhbj48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDQwMSAoVW5hdXRob3JpemVkKSBzdGF0dXMgY29kZXMuJm5ic3A7IEZvciBl eGFtcGxlLCBpZiB0aGU8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7Y29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2aWNl IGlzIHRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlLCB0aGUgYXV0aG9yaXphdGlvbjwvc3Bhbj48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlcnZlciBNQVkgcmV0dXJuIGFuIGVycm9yIHJlc3Bv bnNlIHdpdGggJnF1b3Q7ZXJyb3ImcXVvdDsgc2V0IHRvPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7NTAzJnF1b3Q7Ljwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNr Z3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkFkZCBhIG5ldyBzZWN0aW9u IDguNDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUn PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+OC40LiZuYnNwOyBEZWZpbmluZyBBZGRpdGlvbmFs IEVycm9yIENvZGVzPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4gJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mbmJzcDsmbmJzcDsgSW4gY2FzZXMgd2hlcmUgcHJvdG9jb2wgZXh0ZW5zaW9ucyAo aS5lLiBhY2Nlc3MgdG9rZW4gdHlwZXMsPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHls ZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJz cDsgZXh0ZW5zaW9uIHBhcmFtZXRlcnMsIG9yIGV4dGVuc2lvbiBncmFudCB0eXBlcykgcmVxdWly ZSBhZGRpdGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgZXJyb3IgY29k ZXMgdG8gYmUgdXNlZCB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgZXJyb3I8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyByZXNwb25zZSAoU2VjdGlvbiA0LjEuMi4x KSwgdGhlIGltcGxpY2l0IGdyYW50IGVycm9yIHJlc3BvbnNlPG86cD48L286cD48L3NwYW4+PC9w cmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDsmbmJzcDsgKFNlY3Rpb24gNC4yLjIuMSksIG9yIHRoZSB0b2tlbiBlcnJvciByZXNw b25zZSAoU2VjdGlvbiA1LjIpLCBzdWNoPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHls ZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJz cDsgZXJyb3IgY29kZXMgTUFZIGJlIGRlZmluZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+PHBy ZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4gJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgRXh0ZW5zaW9uIGVycm9yIGNv ZGVzIE1VU1QgYmUgcmVnaXN0ZXJlZCAoZm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGluPG86cD48 L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgU2VjdGlvbiAxMC4zKSBpZiB0aGUgZXh0ZW5z aW9uIHRoZXkgYXJlIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCBpczxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+Jm5ic3A7Jm5ic3A7IHJlZ2lzdGVyZWQuJm5ic3A7IEFkZGl0aW9uYWwgZXJyb3IgY29k ZXMgdXNlZCB3aXRoIHVucmVnaXN0ZXJlZCBleHRlbnNpb25zPG86cD48L286cD48L3NwYW4+PC9w cmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDsmbmJzcDsgTUFZIGJlIHJlZ2lzdGVyZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+ PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4g Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0 ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgRXJyb3IgY29kZXMgTVVT VCBjb25mb3JtIHRvIHRoZSBlcnJvci1jb2RlIEFCTkYsIGFuZCBTSE9VTEQgYmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyBwcmVmaXhlZCBieSBhbiBpZGVudGlmeWluZyBuYW1l IHdoZW4gcG9zc2libGUuJm5ic3A7IEZvciBleGFtcGxlLCBhbiBlcnJvcjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7Jm5ic3A7IGlkZW50aWZ5aW5nIGFuIGludmFsaWQgdmFsdWUgc2V0IHRv IHRoZSBleHRlbnNpb24gcGFyYW1ldGVyICZxdW90O2V4YW1wbGUmcXVvdDs8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOyZuYnNwOyBzaG91bGQgYmUgbmFtZWQgJnF1b3Q7ZXhhbXBsZV9pbnZh bGlkJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGVycm9yLWNvZGUmbmJzcDsmbmJzcDsgPSBBTFBIQSAqZXJyb3ItY2hhcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVycm9yLWNoYXImbmJzcDsmbmJz cDsgPSAmcXVvdDstJnF1b3Q7IC8gJnF1b3Q7LiZxdW90OyAvICZxdW90O18mcXVvdDsgLyBESUdJ VCAvIEFMUEhBPG86cD48L286cD48L3NwYW4+PC9wcmU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5BZGQgYSBuZXcgc2VjdGlv biAxMC4zOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0 ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4xMC4zLiZuYnNwOyBUaGUgT0F1dGggRXh0ZW5z aW9ucyBFcnJvciBSZWdpc3RyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ICZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiBlc3RhYmxpc2hl cyB0aGUgT0F1dGggZXh0ZW5zaW9ucyBlcnJvciByZWdpc3RyeS48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+Jm5ic3A7Jm5ic3A7IEFkZGl0aW9uYWwgZXJyb3IgY29kZXMgdXNlZCB0b2dldGhlciB3 aXRoIG90aGVyIHByb3RvY29sIGV4dGVuc2lvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJl IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OyZuYnNwOyAoaS5lLiBleHRlbnNpb24gZ3JhbnQgdHlwZXMsIGFjY2VzcyB0b2tlbiB0eXBlcywg b3IgZXh0ZW5zaW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgcGFyYW1ldGVy cykgYXJlIHJlZ2lzdGVyZWQgb24gdGhlIGFkdmljZSBvZiBvbmUgb3IgbW9yZSBEZXNpZ25hdGVk PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgRXhwZXJ0cyAoYXBwb2ludGVkIGJ5 IHRoZSBJRVNHIG9yIHRoZWlyIGRlbGVnYXRlKSwgd2l0aCBhPG86cD48L286cD48L3NwYW4+PC9w cmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDsmbmJzcDsgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCAodXNpbmcgdGVybWlub2xvZ3kg ZnJvbSBbUkZDNTIyNl0pLiZuYnNwOyBIb3dldmVyLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxw cmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5i c3A7Jm5ic3A7IHRvIGFsbG93IGZvciB0aGUgYWxsb2NhdGlvbiBvZiB2YWx1ZXMgcHJpb3IgdG8g cHVibGljYXRpb24sIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tn cm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7IERlc2ln bmF0ZWQgRXhwZXJ0KHMpIG1heSBhcHByb3ZlIHJlZ2lzdHJhdGlvbiBvbmNlIHRoZXkgYXJlIHNh dGlzZmllZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7IHRoYXQgc3VjaCBhIHNw ZWNpZmljYXRpb24gd2lsbCBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+IHB1Ymxpc2hlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0 eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZu YnNwOyBSZWdpc3RyYXRpb24gcmVxdWVzdHMgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIFtUQkRdQGll dGYub3JnIG1haWxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyBsaXN0IGZv ciByZXZpZXcgYW5kIGNvbW1lbnQsIHdpdGggYW4gYXBwcm9wcmlhdGUgc3ViamVjdCAoZS5nLiw8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyAmcXVvdDtSZXF1ZXN0IGZvciBlcnJv ciBjb2RlOiBleGFtcGxlJnF1b3Q7KS4gW1sgTm90ZSB0byBSRkMtRURJVE9SOiBUaGUgbmFtZTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7IG9mIHRoZSBtYWlsaW5nIGxpc3Qgc2hv dWxkIGJlIGRldGVybWluZWQgaW4gY29uc3VsdGF0aW9uIHdpdGggdGhlPG86cD48L286cD48L3Nw YW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mbmJzcDsmbmJzcDsgSUVTRyBhbmQgSUFOQS4mbmJzcDsgU3VnZ2VzdGVkIG5hbWU6 IG9hdXRoLWV4dC1yZXZpZXcuIF1dPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4gJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgV2l0aGluIGF0IG1vc3QgMTQgZGF5cyBvZiB0 aGUgcmVxdWVzdCwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIHdpbGw8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOyZuYnNwOyBlaXRoZXIgYXBwcm92ZSBvciBkZW55IHRoZSByZWdpc3RyYXRp b24gcmVxdWVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5k OndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiBjb21tdW5pY2F0aW5nIHRoaXM8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyBkZWNpc2lvbiB0byB0aGUgcmV2aWV3IGxp c3QgYW5kIElBTkEuJm5ic3A7IERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOyZuYnNwOyBleHBsYW5hdGlvbiBhbmQsIGlmIGFwcGxpY2FibGUsIHN1 Z2dlc3Rpb25zIGFzIHRvIGhvdyB0byBtYWtlIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxw cmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5i c3A7Jm5ic3A7IHJlcXVlc3Qgc3VjY2Vzc2Z1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJl IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiAmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyBEZWNpc2lvbnMgKG9yIGxhY2sg dGhlcmVvZikgbWFkZSBieSB0aGUgRGVzaWduYXRlZCBFeHBlcnQgY2FuIGJlPG86cD48L286cD48 L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgZmlyc3QgYXBwZWFsZWQgdG8gQXBwbGljYXRpb24gQXJl YSBEaXJlY3RvcnMgKGNvbnRhY3RhYmxlIHVzaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+PHBy ZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOmFwcC1hZHNAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5hcHAtYWRzQHRvb2xzLmlldGYub3JnPC9hPiBlbWFpbCBhZGRyZXNzIG9yIGRpcmVj dGx5IGJ5IGxvb2tpbmcgdXAgdGhlaXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxl PSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNw OyBlbWFpbCBhZGRyZXNzZXMgb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiA8YSBocmVmPSJodHRw Oi8vd3d3Lmllc2cub3JnLyI+aHR0cDovL3d3dy5pZXNnLm9yZy88L2E+IHdlYnNpdGUpIGFuZCwg aWYgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0 ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgYXBwZWxsYW50IGlzIG5v dCBzYXRpc2ZpZWQgd2l0aCB0aGUgcmVzcG9uc2UsIHRvIHRoZSBmdWxsIElFU0cgKHVzaW5nPG86 cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgdGhlIDxhIGhyZWY9Im1haWx0bzppZXNn QGllc2cub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWVzZ0BpZXNnLm9yZzwvYT4gbWFpbGluZyBsaXN0 KS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48 cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOyZuYnNwOyBJQU5BIHNob3VsZCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1cGRhdGVzIGZyb20g dGhlIERlc2lnbmF0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyBFeHBlcnQo cyksIGFuZCBzaG91bGQgZGlyZWN0IGFsbCByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0aW9uIHRvIHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7IHJldmlldyBtYWlsaW5nIGxpc3Qu PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+PHBy ZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4xMC4z LjEuJm5ic3A7IFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxw cmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ICZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUn PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7IEVycm9yIG5hbWU6PG86cD48 L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIG5hbWUg cmVxdWVzdGVkIChlLmcuLCAmcXVvdDtleGFtcGxlJnF1b3Q7KS48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOyZuYnNwOyBFcnJvciB1c2FnZSBsb2NhdGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgbG9jYXRpb24ocykgd2hlcmUg dGhlIGVycm9yIGNhbiBiZSB1c2VkLiZuYnNwOyBUaGUgcG9zc2libGU8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsb2NhdGlvbnMgYXJlOiBhdXRo b3JpemF0aW9uIGNvZGUgZ3JhbnQgZXJyb3IgcmVzcG9uc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT48cHJlIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoU2VjdGlvbiA0LjEuMi4xKSwgaW1wbGlj aXQgZ3JhbnQgZXJyb3IgcmVzcG9uc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxl PSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAoU2VjdGlvbiA0LjIuMi4xKSwgb3IgdG9rZW4gZXJyb3IgcmVz cG9uc2UgKFNlY3Rpb24gNS4yKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyBS ZWxhdGVkIHByb3RvY29sIGV4dGVuc2lvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0 eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgbmFtZSBvZiB0aGUgZXh0ZW5zaW9uIGdyYW50IHR5 cGUsIGFjY2VzczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+IHRva2VuIHR5cGUsIG9yPG86cD48L286 cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXh0ZW5zaW9uIHBh cmFtZXRlciwgdGhlIGVycm9yIGNvZGUgaXMgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7IENoYW5nZSBjb250cm9sbGVyOjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZvciBzdGFuZGFy ZHMtdHJhY2sgUkZDcywgc3RhdGUgJnF1b3Q7SUVURiZxdW90Oy4mbmJzcDsgRm9yIG90aGVycywg Z2l2ZSB0aGUgbmFtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG9mIHRoZSByZXNwb25zaWJsZSBwYXJ0eS4mbmJzcDsgT3RoZXIgZGV0YWlscyAo ZS5nLiwgcG9zdGFsIGFkZHJlc3MsPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFnZSBVUkkpIG1heSBhbHNv IGJlIGluY2x1ZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7ICZuYnNwO1NwZWNpZmlj YXRpb24gZG9jdW1lbnQocyk6PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgUmVmZXJlbmNlIHRvIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSBl cnJvciBjb2RlLCBwcmVmZXJhYmx5PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgaW5jbHVkaW5nIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJl IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiBVUkkg dGhhdCBjYW4gYmUgdXNlZCB0byByZXRyaWV2ZSBhIGNvcHkgb2YgdGhlPG86cD48L286cD48L3Nw YW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZG9jdW1lbnQuJm5ic3A7IEFu IGluZGljYXRpb24gb2YgdGhlIHJlbGV2YW50IHNlY3Rpb25zIG1heSBhbHNvIGJlPG86cD48L286 cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5jbHVkZWQsIGJ1 dCBpcyBub3QgcmVxdWlyZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0 O2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PGJyPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPk9BdXRoIG1haWxpbmcg bGlzdDxicj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9h Pjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E320P3PW5EX1MB01E_-- From James.H.Manger@team.telstra.com Thu Apr 7 18:47:14 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704E13A69A5 for ; Thu, 7 Apr 2011 18:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvKZuhwdMRp8 for ; Thu, 7 Apr 2011 18:47:08 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id CDBBB3A69A2 for ; Thu, 7 Apr 2011 18:47:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,321,1299416400"; d="scan'208,217";a="29900531" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipobni.tcif.telstra.com.au with ESMTP; 08 Apr 2011 11:48:51 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6309"; a="23419691" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcdni.tcif.telstra.com.au with ESMTP; 08 Apr 2011 11:48:52 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Fri, 8 Apr 2011 11:48:51 +1000 From: "Manger, James H" To: OAuth WG Date: Fri, 8 Apr 2011 11:48:49 +1000 Thread-Topic: OAuth2 scheme Thread-Index: Acv0szxJR54h3FRORpezZ9L8nUeh+gAxRy2g Message-ID: <255B9BB34FB7D647A506DC292726F6E11281CAB8DB@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465664E11D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664E11D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11281CAB8DBWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth2 scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 01:47:14 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11281CAB8DBWSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We should define a "WWW-Authenticate: OAuth2 ..." response header - not to = encompass the MAC, Bearer, and any other generic HTTP authentication scheme= , but as a way for a server to tell the client that it can perform an OAuth= 2 get-a-token flow to gain access. When the sort of OAuth2 flow depends on = the error with a current token (eg expired vs invalid) then the "WWW-Authen= ticate: OAuth2 ..." response header needs to reflect this. It could do so b= e including an error code. A better, more direct, approach is to explicitly= identify "refresh flow" and/or "user-delegation flow" and/or "assertion fl= ow" etc. Bearer or OAuth2 WWW-Authenticate response header? The rule should be: #1. If the client can fix an error by sending an "Authorization: Bearer ...= " request header (or the query or POST alternative) then the server should = return "WWW-Authenticate: Bearer ...". #2. If the client can fix an error by performing an OAuth2 flow at an autho= rization server then the resource server should return "WWW-Authenticate: O= Auth2 ...". The server can return both response headers if both options are possible. There is no point in re-presenting a rejected Bearer token so #1 isn't that= useful. It could be appropriate if no token was presented as the client mi= ght have a token, but didn't know this resource needed it. It might be appr= opriate if a client presented a token with insufficient scope as the client= might have another token with the right scope so "WWW-Authenticate: Bearer= scope=3D..." could help. #1 is not really necessary when a presented token= is invalid or expired as the client needs to get a new one (eg using an OA= uth2 flow that is outside the scope of the Bearer scheme). I don't think an error code in a "WWW-Authenticate: Bearer ..." response he= lps a client retry the request with a "Authorization: Bearer ..." header th= at will work. An error code might help a client choose the right OAuth2 flow (eg refresh = vs new user-delegation) so it might have a place in #2, a "WWW-Authenticate= : OAuth2 ..." response header. Eran said to Mike: > Alternatively, if you have use cases or requirements for introducing just= the WWW-Authenticate side of an OAuth2 authorization scheme (your open iss= ue), which includes an 'error' attribute for use with the proposed registry= , please present those and explain how it will work alongside the Bearer an= d MAC schemes (as currently drafted). The "discovery" use-case in this email warrants the WWW-Authenticate side o= f an OAuth2 scheme. An error attribute (plus a registry) might help, but we need the rest of th= e details of the response header first. It works well alongside Bearer and MAC schemes: a "WWW-Auth.: OAuth2" respo= nse points to OAuth2 flows the client can try; a "WWW-Auth.: MAC/Bearer" re= sponse points to retrying a request with "Authz: MAC/Bearer". Even when a c= lient is given multiple options it will know which to choose based on its c= ontext (eg if it doesn't have another Bearer token it will ignore the "WWW-= Auth: Bearer" response and follow the "WWW-Auth: OAuth2" response). -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E11281CAB8DBWSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We should define a = 220;WWW-Authenticate: OAuth2 …” response header – not to = encompass the MAC, Bearer, and any other generic HTTP authentication scheme= , but as a way for a server to tell the client that it can perform an OAuth2 get-a-token flow to gain access. When the sort of OAuth2 flow de= pends on the error with a current token (eg expired vs invalid) then the &#= 8220;WWW-Authenticate: OAuth2 …” response header needs to refle= ct this. It could do so be including an error code. A better, more direct, approach is to explicitly identify “refresh f= low” and/or “user-delegation flow” and/or “assertio= n flow” etc.

 

Bearer or OAuth2 WW= W-Authenticate response header?

The rule should be:

#1. If the client can = fix an error by sending an “Authorization: Bearer …” requ= est header (or the query or POST alternative) then the server should return= “WWW-Authenticate: Bearer …”.

 

#2. If the client can = fix an error by performing an OAuth2 flow at an authorization server then t= he resource server should return “WWW-Authenticate: OAuth2 …= 221;.

 

The server can return = both response headers if both options are possible.

 

There is no point in r= e-presenting a rejected Bearer token so #1 isn’t that useful. It coul= d be appropriate if no token was presented as the client might have a token= , but didn’t know this resource needed it. It might be appropriate if a client presented a token with insufficient sc= ope as the client might have another token with the right scope so “W= WW-Authenticate: Bearer scope=3D…” could help. #1 is not really= necessary when a presented token is invalid or expired as the client needs to get a new one (eg using an OAuth2 flow that is outs= ide the scope of the Bearer scheme).

 

I don’t think an= error code in a “WWW-Authenticate: Bearer …” response he= lps a client retry the request with a “Authorization: Bearer …&= #8221; header that will work.

An error code might he= lp a client choose the right OAuth2 flow (eg refresh vs new user-delegation= ) so it might have a place in #2, a “WWW-Authenticate: OAuth2 …= ” response header.

 

Eran said to Mike:

> Al= ternatively, if you have use cases or requirements for introducing just the= WWW-Authenticate side of an OAuth2 authorization scheme (your open issue),= which includes an ‘error’ attribute for use with the proposed registry, please present those and explain how it wi= ll work alongside the Bearer and MAC schemes (as currently drafted).

 

The “discovery&#= 8221; use-case in this email warrants the WWW-Authenticate side of an OAuth= 2 scheme.

An error attribute (pl= us a registry) might help, but we need the rest of the details of the respo= nse header first.

It works well alongsid= e Bearer and MAC schemes: a “WWW-Auth.: OAuth2” response points= to OAuth2 flows the client can try; a “WWW-Auth.: MAC/Bearer” = response points to retrying a request with “Authz: MAC/Bearer”. Even when a client is given multiple options it will know which to choose = based on its context (eg if it doesn’t have another Bearer token it w= ill ignore the “WWW-Auth: Bearer” response and follow the ̶= 0;WWW-Auth: OAuth2” response).

 

 

--

James Manger

--_000_255B9BB34FB7D647A506DC292726F6E11281CAB8DBWSMSG3153Vsrv_-- From wmills@yahoo-inc.com Thu Apr 7 18:59:14 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43723A6834 for ; Thu, 7 Apr 2011 18:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxkq4maBgJ6K for ; Thu, 7 Apr 2011 18:59:11 -0700 (PDT) Received: from web32303.mail.mud.yahoo.com (web32303.mail.mud.yahoo.com [68.142.207.151]) by core3.amsl.com (Postfix) with SMTP id 6715E3A6824 for ; Thu, 7 Apr 2011 18:59:11 -0700 (PDT) Received: (qmail 31319 invoked by uid 60001); 8 Apr 2011 02:00:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302228053; bh=Pf0PeH4aciEkSiOcuu1hi+HvSLhuFmbMx3ZoEmAYqLI=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=SfxH6hwiJwe25qhU4i0F19seeWJJxaOWTdlLR1k5TqjWH8kPbOQwFDkwFilqp6ffxhXcshWsi2oJEwEczGXRE+hhNpLicbs4K7moRlD8aCm8u6AnFTEMVD+oiIeqz+7jDZVsBLS3lV/9EriYOL4N1AlinbKIOmPr+vjo20yaRbY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=gHdKRdhGZY4ex2lrFhfUbWz9rSwSYJl7U57ep26jCcLsZsn3b+2tN9sWeTrzJ2x2ARVw+yxjJVo8YPO4n8UDv0aSSniVo6CARMJ65LZy8kHi9f4thpM79fE8AIvokd+u7EKL8k4Pp5y8zx5/6QY6wI0LMYbwL04bAdFOlsNKCGY=; Message-ID: <249220.24403.qm@web32303.mail.mud.yahoo.com> X-YMail-OSG: lLUTu5wVM1k96dv4qSQ5RVrt2qyYnH1vL1epvIT_4WHN3Kd XebprT.XcJZt15eo4Z9ReiBH43IyuK.LisML9zVmvkPJ6JOwSqTVNR3E_ccU QJ_EB2gH3_oELvNgKRn.qYxxuhgAFzBhdW5Yf7vSkcm0gwIvFZKvsZoVomZ5 o6mXLUW87k38D2QVbHlXpjq8XWA0wg1p5Qsl2DZmJRoLoFJ_bvKZadG0sq9Y YdenVPS7bRYVoOJpqc34gYZTFA240VAvfzTXaqjjQuVJW5HsxuFjeGk9ZXp4 apMXQ5cDvvwYQWrOnVGsK0M09wsJatJ1e3rZji1nPusnJBoH67.WDgwM2GJ9 OYKnkGQ1_v.w1kkRBGx7a7LWJ2ct5y.XqTscl6gOm Received: from [216.145.52.206] by web32303.mail.mud.yahoo.com via HTTP; Thu, 07 Apr 2011 19:00:53 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <90C41DD21FB7C64BB94121FBBC2E7234465664E11D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281CAB8DB@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 7 Apr 2011 19:00:53 -0700 (PDT) From: "William J. Mills" To: "Manger, James H" , OAuth WG In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11281CAB8DB@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-978235021-1302228053=:24403" Subject: Re: [OAUTH-WG] OAuth2 scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 01:59:15 -0000 --0-978235021-1302228053=:24403 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In the SASL mechanism draft spec where we went with that is to use LINK hea= ders.=C2=A0 See http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-01= if you want to take a look.=C2=A0 WWW-Authenticate headers return the supp= orted authentication schemes and LINK headers tell you there are OAuth endp= oints you can interact with.=0A=0AIt's a swag at discovery in band, might w= ork here too.=0A=0A=0A=0A________________________________=0AFrom: "Manger, = James H" =0ATo: OAuth WG = =0ASent: Thursday, April 7, 2011 6:48 PM=0ASubject: Re: [OAUTH-WG] OAuth2 s= cheme=0A=0A=0A =0AWe should define a =E2=80=9CWWW-Authenticate: OAuth2 =E2= =80=A6=E2=80=9D response header =E2=80=93 not to encompass the MAC, Bearer,= and any other generic HTTP authentication scheme, but as a way for a serve= r to tell the client that it can perform an OAuth2 get-a-token flow to gain= access. When the sort of OAuth2 flow depends on the error with a current t= oken (eg expired vs invalid) then the =E2=80=9CWWW-Authenticate: OAuth2 =E2= =80=A6=E2=80=9D response header needs to reflect this. It could do so be in= cluding an error code. A better, more direct, approach is to explicitly ide= ntify =E2=80=9Crefresh flow=E2=80=9D and/or =E2=80=9Cuser-delegation flow= =E2=80=9D and/or =E2=80=9Cassertion flow=E2=80=9D etc.=0A=C2=A0=0ABearer or= OAuth2 WWW-Authenticate response header?=0AThe rule should be:=0A#1. If th= e client can fix an error by sending an =E2=80=9CAuthorization: Bearer =E2= =80=A6=E2=80=9D request header (or the query or POST alternative) then the = server should return =E2=80=9CWWW-Authenticate: Bearer =E2=80=A6=E2=80=9D.= =0A=C2=A0=0A#2. If the client can fix an error by performing an OAuth2 flow= at an authorization server then the resource server should return =E2=80= =9CWWW-Authenticate: OAuth2 =E2=80=A6=E2=80=9D.=0A=C2=A0=0AThe server can r= eturn both response headers if both options are possible.=0A=C2=A0=0AThere = is no point in re-presenting a rejected Bearer token so #1 isn=E2=80=99t th= at useful. It could be appropriate if no token was presented as the client = might have a token, but didn=E2=80=99t know this resource needed it. It mig= ht be appropriate if a client presented a token with insufficient scope as = the client might have another token with the right scope so =E2=80=9CWWW-Au= thenticate: Bearer scope=3D=E2=80=A6=E2=80=9D could help. #1 is not really = necessary when a presented token is invalid or expired as the client needs = to get a new one (eg using an OAuth2 flow that is outside the scope of the = Bearer scheme).=0A=C2=A0=0AI don=E2=80=99t think an error code in a =E2=80= =9CWWW-Authenticate: Bearer =E2=80=A6=E2=80=9D response helps a client retr= y the request with a =E2=80=9CAuthorization: Bearer =E2=80=A6=E2=80=9D head= er that will work.=0AAn error code might help a client choose the right OAu= th2 flow (eg refresh vs new user-delegation) so it might have a place in #2= , a =E2=80=9CWWW-Authenticate: OAuth2 =E2=80=A6=E2=80=9D response header.= =0A=C2=A0=0AEran said to Mike:=0A> Alternatively, if you have use cases or = requirements for introducing just the WWW-Authenticate side of an OAuth2 au= thorization scheme (your open issue), which includes an =E2=80=98error=E2= =80=99 attribute for use with the proposed registry, please present those a= nd explain how it will work alongside the Bearer and MAC schemes (as curren= tly drafted).=0A=C2=A0=0AThe =E2=80=9Cdiscovery=E2=80=9D use-case in this e= mail warrants the WWW-Authenticate side of an OAuth2 scheme.=0AAn error att= ribute (plus a registry) might help, but we need the rest of the details of= the response header first.=0AIt works well alongside Bearer and MAC scheme= s: a =E2=80=9CWWW-Auth.: OAuth2=E2=80=9D response points to OAuth2 flows th= e client can try; a =E2=80=9CWWW-Auth.: MAC/Bearer=E2=80=9D response points= to retrying a request with =E2=80=9CAuthz: MAC/Bearer=E2=80=9D. Even when = a client is given multiple options it will know which to choose based on it= s context (eg if it doesn=E2=80=99t have another Bearer token it will ignor= e the =E2=80=9CWWW-Auth: Bearer=E2=80=9D response and follow the =E2=80=9CW= WW-Auth: OAuth2=E2=80=9D response).=0A=C2=A0=0A=C2=A0=0A--=0AJames Manger= =0A_______________________________________________=0AOAuth mailing list=0AO= Auth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-978235021-1302228053=:24403 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In the SASL mechanism draft spec where we went with that is to use LINK h= eaders.  See http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-= 01 if you want to take a look.  WWW-Authenticate headers return the su= pported authentication schemes and LINK headers tell you there are OAuth en= dpoints you can interact with.

It's a swag at discovery in band, might work here too.

From: "Ma= nger, James H" <James.H.Manger@team.telstra.com>
To: OAuth WG <oauth@ietf.org>= ;
Sent: Thursday, April= 7, 2011 6:48 PM
Subject: Re: [OAUTH-WG] OAuth2 scheme

=0A
=0A=0A =0A =0A=0A=0A=0A
=0A
We should define a =E2=80=9CWWW-Authenticate: OAuth= 2 =E2=80=A6=E2=80=9D response header =E2=80=93 not to encompass the MAC, Be= arer, and any other generic HTTP authentication scheme, but as a way for a = server to tell the client that it can perform=0A an OAuth2 get-a-token flow= to gain access. When the sort of OAuth2 flow depends on the error with a c= urrent token (eg expired vs invalid) then the =E2=80=9CWWW-Authenticate: OA= uth2 =E2=80=A6=E2=80=9D response header needs to reflect this. It could do = so be including an error code.=0A A better, more direct, approach is to exp= licitly identify =E2=80=9Crefresh flow=E2=80=9D and/or =E2=80=9Cuser-delega= tion flow=E2=80=9D and/or =E2=80=9Cassertion flow=E2=80=9D etc. =0A
 
=0A
Bearer or OAuth2 WWW-Authenticate res= ponse header?
=0A
The rule should be:
=0A#1. If the client can fix an error by sending an =E2=80=9CAuthorization: B= earer =E2=80=A6=E2=80=9D request header (or the query or POST alternative) = then the server should return =E2=80=9CWWW-Authenticate: Bearer =E2=80=A6= =E2=80=9D.
=0A
 
=0A
#2. If the client = can fix an error by performing an OAuth2 flow at an authorization server th= en the resource server should return =E2=80=9CWWW-Authenticate: OAuth2 =E2= =80=A6=E2=80=9D.
=0A
 
=0A
The server c= an return both response headers if both options are possible.
= =0A
 
=0A
There is no point in re-presenting a rejec= ted Bearer token so #1 isn=E2=80=99t that useful. It could be appropriate i= f no token was presented as the client might have a token, but didn=E2=80= =99t know this resource needed it.=0A It might be appropriate if a client p= resented a token with insufficient scope as the client might have another t= oken with the right scope so =E2=80=9CWWW-Authenticate: Bearer scope=3D=E2= =80=A6=E2=80=9D could help. #1 is not really necessary when a presented tok= en is invalid or expired=0A as the client needs to get a new one (eg using = an OAuth2 flow that is outside the scope of the Bearer scheme). =0A
 
=0A
I don=E2=80=99t think an error code in a= =E2=80=9CWWW-Authenticate: Bearer =E2=80=A6=E2=80=9D response helps a clie= nt retry the request with a =E2=80=9CAuthorization: Bearer =E2=80=A6=E2=80= =9D header that will work.
=0A
An error code might help a cl= ient choose the right OAuth2 flow (eg refresh vs new user-delegation) so it= might have a place in #2, a =E2=80=9CWWW-Authenticate: OAuth2 =E2=80=A6=E2= =80=9D response header.
=0A
 
=0A
Eran = said to Mike:
=0A
> Alternatively, if you = have use cases or requirements for introducing just the WWW-Authenticate si= de of an OAuth2 authorization scheme (your open issue), which includes an = =E2=80=98error=E2=80=99 attribute for=0A use with the proposed registry, pl= ease present those and explain how it will work alongside the Bearer and MA= C schemes (as currently drafted).
=0A
 
= =0A
The =E2=80=9Cdiscovery=E2=80=9D use-case in this email warrants the W= WW-Authenticate side of an OAuth2 scheme.
=0A
An error attri= bute (plus a registry) might help, but we need the rest of the details of t= he response header first.
=0A
It works well alongside Bearer= and MAC schemes: a =E2=80=9CWWW-Auth.: OAuth2=E2=80=9D response points to = OAuth2 flows the client can try; a =E2=80=9CWWW-Auth.: MAC/Bearer=E2=80=9D = response points to retrying a request with =E2=80=9CAuthz: MAC/Bearer=E2=80= =9D.=0A Even when a client is given multiple options it will know which to = choose based on its context (eg if it doesn=E2=80=99t have another Bearer t= oken it will ignore the =E2=80=9CWWW-Auth: Bearer=E2=80=9D response and fol= low the =E2=80=9CWWW-Auth: OAuth2=E2=80=9D response).
=0A
&= nbsp;
=0A
 
=0A
=0A
--
= =0A
James Manger
=0A
=0A
=0A =0A

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


--0-978235021-1302228053=:24403-- From eran@hueniverse.com Thu Apr 7 19:00:22 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097413A6828 for ; Thu, 7 Apr 2011 19:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3S45GIkzXzw for ; Thu, 7 Apr 2011 19:00:15 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 922A33A6824 for ; Thu, 7 Apr 2011 19:00:15 -0700 (PDT) Received: (qmail 20399 invoked from network); 8 Apr 2011 02:01:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Apr 2011 02:01:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 7 Apr 2011 19:01:58 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , OAuth WG Date: Thu, 7 Apr 2011 19:01:49 -0700 Thread-Topic: OAuth2 scheme Thread-Index: Acv0szxJR54h3FRORpezZ9L8nUeh+gAxRy2gAAXVW8A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E3B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664E11D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281CAB8DB@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11281CAB8DB@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664E3B1P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth2 scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 02:00:22 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E3B1P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chairs - see request inline. Hi James, The use case you proposed for an OAuth2 scheme is not about token authentic= ation at all but about relaying authorization server discovery information = only. This use case is completely within the realm of discovery, and that i= s out of scope. There is nothing to prevent another document from taking the time (as you i= ndicated is necessary) to figure out exactly what the requirements are for = such a scheme, and to thoroughly map them into the right set of attributes.= I believe discovery is still very much undefined and cannot be figured out= without significant deployment experience for OAuth 2.0, as well as some s= tabilization of new grant types and other extensions. Chairs - I would like to ask that you declare all discovery requirements an= d use cases out of scope for v2 and the working group at this point. --- As for the error code registry and the request Mike posted, I do not think = your use case has much to do with the goal Mike has with his registry propo= sal. Mike's proposal is for v2 to define an error registry for use with an = error attribute across different HTTP schemes such as Bearer and MAC, and f= or that to make sense, we need to define an OAuth2 scheme that *replaces* t= he Bearer and MAC schemes - something you agree we should not do. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Thursday, April 07, 2011 6:49 PM To: OAuth WG Subject: Re: [OAUTH-WG] OAuth2 scheme We should define a "WWW-Authenticate: OAuth2 ..." response header - not to = encompass the MAC, Bearer, and any other generic HTTP authentication scheme= , but as a way for a server to tell the client that it can perform an OAuth= 2 get-a-token flow to gain access. When the sort of OAuth2 flow depends on = the error with a current token (eg expired vs invalid) then the "WWW-Authen= ticate: OAuth2 ..." response header needs to reflect this. It could do so b= e including an error code. A better, more direct, approach is to explicitly= identify "refresh flow" and/or "user-delegation flow" and/or "assertion fl= ow" etc. Bearer or OAuth2 WWW-Authenticate response header? The rule should be: #1. If the client can fix an error by sending an "Authorization: Bearer ...= " request header (or the query or POST alternative) then the server should = return "WWW-Authenticate: Bearer ...". #2. If the client can fix an error by performing an OAuth2 flow at an autho= rization server then the resource server should return "WWW-Authenticate: O= Auth2 ...". The server can return both response headers if both options are possible. There is no point in re-presenting a rejected Bearer token so #1 isn't that= useful. It could be appropriate if no token was presented as the client mi= ght have a token, but didn't know this resource needed it. It might be appr= opriate if a client presented a token with insufficient scope as the client= might have another token with the right scope so "WWW-Authenticate: Bearer= scope=3D..." could help. #1 is not really necessary when a presented token= is invalid or expired as the client needs to get a new one (eg using an OA= uth2 flow that is outside the scope of the Bearer scheme). I don't think an error code in a "WWW-Authenticate: Bearer ..." response he= lps a client retry the request with a "Authorization: Bearer ..." header th= at will work. An error code might help a client choose the right OAuth2 flow (eg refresh = vs new user-delegation) so it might have a place in #2, a "WWW-Authenticate= : OAuth2 ..." response header. Eran said to Mike: > Alternatively, if you have use cases or requirements for introducing just= the WWW-Authenticate side of an OAuth2 authorization scheme (your open iss= ue), which includes an 'error' attribute for use with the proposed registry= , please present those and explain how it will work alongside the Bearer an= d MAC schemes (as currently drafted). The "discovery" use-case in this email warrants the WWW-Authenticate side o= f an OAuth2 scheme. An error attribute (plus a registry) might help, but we need the rest of th= e details of the response header first. It works well alongside Bearer and MAC schemes: a "WWW-Auth.: OAuth2" respo= nse points to OAuth2 flows the client can try; a "WWW-Auth.: MAC/Bearer" re= sponse points to retrying a request with "Authz: MAC/Bearer". Even when a c= lient is given multiple options it will know which to choose based on its c= ontext (eg if it doesn't have another Bearer token it will ignore the "WWW-= Auth: Bearer" response and follow the "WWW-Auth: OAuth2" response). -- James Manger --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E3B1P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chairs – see request inline.

 

<= p class=3DMsoNormal>Hi James,

 <= /span>

The use case y= ou proposed for an OAuth2 scheme is not about token authentication at all b= ut about relaying authorization server discovery information only. This use= case is completely within the realm of discovery, and that is out of scope= .

<= o:p> 

There is nothing to prevent another document from taking the time (as yo= u indicated is necessary) to figure out exactly what the requirements are f= or such a scheme, and to thoroughly map them into the right set of attribut= es. I believe discovery is still very much undefined and cannot be figured = out without significant deployment experience for OAuth 2.0, as well as som= e stabilization of new grant types and other extensions.<= /p>

 

Chairs – I = would like to ask that you declare all discovery requirements and use cases= out of scope for v2 and the working group at this point.=

 

---

 

As for the = error code registry and the request Mike posted, I do not think your use ca= se has much to do with the goal Mike has with his registry proposal. Mike&#= 8217;s proposal is for v2 to define an error registry for use with an error= attribute across different HTTP schemes such as Bearer and MAC, and for th= at to make sense, we need to define an OAuth2 scheme that *replaces*= the Bearer and MAC schemes – something you agree we should not do.

 

= EHL

 

 

= From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Manger, James H
Sent: Thursday, April 07, 2011 6:49 PM
= To: OAuth WG
Subject: Re: [OAUTH-WG] OAuth2 scheme=

 

We should define a = “WWW-Authenticate: OAuth2 …” response header – not = to encompass the MAC, Bearer, and any other generic HTTP authentication sch= eme, but as a way for a server to tell the client that it can perform an OA= uth2 get-a-token flow to gain access. When the sort of OAuth2 flow depends = on the error with a current token (eg expired vs invalid) then the “W= WW-Authenticate: OAuth2 …” response header needs to reflect thi= s. It could do so be including an error code. A better, more direct, approa= ch is to explicitly identify “refresh flow” and/or “user-= delegation flow” and/or “assertion flow” etc.<= /span>

<= o:p> 

Bearer or OAuth2 WWW-Authenticate response header?<= /o:p>

The rule should be:

#1. If the client can fix an error b= y sending an “Authorization: Bearer …” request header (or= the query or POST alternative) then the server should return “WWW-Au= thenticate: Bearer …”.

 

#2. If the cl= ient can fix an error by performing an OAuth2 flow at an authorization serv= er then the resource server should return “WWW-Authenticate: OAuth2 &= #8230;”.

 

<= span lang=3DEN-AU style=3D'color:#1F497D'>The server can return both respon= se headers if both options are possible.

 =

There i= s no point in re-presenting a rejected Bearer token so #1 isn’t that = useful. It could be appropriate if no token was presented as the client mig= ht have a token, but didn’t know this resource needed it. It might be= appropriate if a client presented a token with insufficient scope as the c= lient might have another token with the right scope so “WWW-Authentic= ate: Bearer scope=3D…” could help. #1 is not really necessary w= hen a presented token is invalid or expired as the client needs to get a ne= w one (eg using an OAuth2 flow that is outside the scope of the Bearer sche= me).

 

I don’t think an error code in a = 220;WWW-Authenticate: Bearer …” response helps a client retry t= he request with a “Authorization: Bearer …” header that w= ill work.

An error code might help a client choose the right OAut= h2 flow (eg refresh vs new user-delegation) so it might have a place in #2,= a “WWW-Authenticate: OAuth2 …” response header.

 

Eran said to Mike:

> Alternatively, if you have use case= s or requirements for introducing just the WWW-Authenticate side of an OAut= h2 authorization scheme (your open issue), which includes an ‘error&#= 8217; attribute for use with the proposed registry, please present those an= d explain how it will work alongside the Bearer and MAC schemes (as current= ly drafted).

 

The “discovery” use-cas= e in this email warrants the WWW-Authenticate side of an OAuth2 scheme.

An error attribute (plus a registry) might help, but we need the res= t of the details of the response header first.

It works well alon= gside Bearer and MAC schemes: a “WWW-Auth.: OAuth2” response po= ints to OAuth2 flows the client can try; a “WWW-Auth.: MAC/BearerR= 21; response points to retrying a request with “Authz: MAC/BearerR= 21;. Even when a client is given multiple options it will know which to cho= ose based on its context (eg if it doesn’t have another Bearer token = it will ignore the “WWW-Auth: Bearer” response and follow the &= #8220;WWW-Auth: OAuth2” response).

 =

&n= bsp;

--

James Manger

<= /div>= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E3B1P3PW5EX1MB01E_-- From eran@hueniverse.com Thu Apr 7 19:01:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C103A6828 for ; Thu, 7 Apr 2011 19:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urR96bRFuo1G for ; Thu, 7 Apr 2011 19:01:55 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 21B923A6824 for ; Thu, 7 Apr 2011 19:01:55 -0700 (PDT) Received: (qmail 3444 invoked from network); 8 Apr 2011 02:03:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Apr 2011 02:03:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 7 Apr 2011 19:03:39 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , "Manger, James H" , OAuth WG Date: Thu, 7 Apr 2011 19:03:30 -0700 Thread-Topic: [OAUTH-WG] OAuth2 scheme Thread-Index: Acv1kNC34sbetPHWRwidgxX3rNPfogAACTaw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E3B2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664E11D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281CAB8DB@WSMSG3153V.srv.dir.telstra.com> <249220.24403.qm@web32303.mail.mud.yahoo.com> In-Reply-To: <249220.24403.qm@web32303.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664E3B2P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth2 scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 02:01:57 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E3B2P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IExpbmsgaGVhZGVycyBhcmUgbXVjaCBiZXR0ZXIgZml0IGZvciByZWxheWlu ZyBkaXNjb3ZlcnkgaW5mb3JtYXRpb24gdGhhbiBhIGhhbGYgSFRUUCBhdXRoZW50aWNhdGlvbiBz Y2hlbWUuIE92ZXJhbGwsIEkgZmluZCBKYW1lc+KAmSBwcm9wb3NhbCB0byBiZSB0b28gY29tcGxl eCBhbmQgbm90IGludHVpdGl2ZSB0byBwZW9wbGUgZmFtaWxpYXIgd2l0aCBleGlzdGluZyBIVFRQ IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgKGl0IGlzIG5vdmVsIGFuZCB3ZWxsIHRob3VnaHQsIGFu ZCBpdCBkb2VzIHdvcmssIGp1c3Qgbm90IGFzIG1vc3QgcGVvcGxlIGV4cGVjdCBkaXNjb3Zlcnkg dG8pLg0KDQpFSEwNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXaWxsaWFtIEouIE1pbGxzDQpTZW50OiBU aHVyc2RheSwgQXByaWwgMDcsIDIwMTEgNzowMSBQTQ0KVG86IE1hbmdlciwgSmFtZXMgSDsgT0F1 dGggV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoMiBzY2hlbWUNCg0KSW4gdGhlIFNB U0wgbWVjaGFuaXNtIGRyYWZ0IHNwZWMgd2hlcmUgd2Ugd2VudCB3aXRoIHRoYXQgaXMgdG8gdXNl IExJTksgaGVhZGVycy4gIFNlZSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taWxs cy1raXR0ZW4tc2FzbC1vYXV0aC0wMSBpZiB5b3Ugd2FudCB0byB0YWtlIGEgbG9vay4gIFdXVy1B dXRoZW50aWNhdGUgaGVhZGVycyByZXR1cm4gdGhlIHN1cHBvcnRlZCBhdXRoZW50aWNhdGlvbiBz Y2hlbWVzIGFuZCBMSU5LIGhlYWRlcnMgdGVsbCB5b3UgdGhlcmUgYXJlIE9BdXRoIGVuZHBvaW50 cyB5b3UgY2FuIGludGVyYWN0IHdpdGguDQoNCkl0J3MgYSBzd2FnIGF0IGRpc2NvdmVyeSBpbiBi YW5kLCBtaWdodCB3b3JrIGhlcmUgdG9vLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogIk1hbmdlciwgSmFtZXMgSCIgPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3Ry YS5jb20+DQpUbzogT0F1dGggV0cgPG9hdXRoQGlldGYub3JnPg0KU2VudDogVGh1cnNkYXksIEFw cmlsIDcsIDIwMTEgNjo0OCBQTQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGgyIHNjaGVt ZQ0KDQoNCldlIHNob3VsZCBkZWZpbmUgYSDigJxXV1ctQXV0aGVudGljYXRlOiBPQXV0aDIg4oCm 4oCdIHJlc3BvbnNlIGhlYWRlciDigJMgbm90IHRvIGVuY29tcGFzcyB0aGUgTUFDLCBCZWFyZXIs IGFuZCBhbnkgb3RoZXIgZ2VuZXJpYyBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSwgYnV0IGFz IGEgd2F5IGZvciBhIHNlcnZlciB0byB0ZWxsIHRoZSBjbGllbnQgdGhhdCBpdCBjYW4gcGVyZm9y bSBhbiBPQXV0aDIgZ2V0LWEtdG9rZW4gZmxvdyB0byBnYWluIGFjY2Vzcy4gV2hlbiB0aGUgc29y dCBvZiBPQXV0aDIgZmxvdyBkZXBlbmRzIG9uIHRoZSBlcnJvciB3aXRoIGEgY3VycmVudCB0b2tl biAoZWcgZXhwaXJlZCB2cyBpbnZhbGlkKSB0aGVuIHRoZSDigJxXV1ctQXV0aGVudGljYXRlOiBP QXV0aDIg4oCm4oCdIHJlc3BvbnNlIGhlYWRlciBuZWVkcyB0byByZWZsZWN0IHRoaXMuIEl0IGNv dWxkIGRvIHNvIGJlIGluY2x1ZGluZyBhbiBlcnJvciBjb2RlLiBBIGJldHRlciwgbW9yZSBkaXJl Y3QsIGFwcHJvYWNoIGlzIHRvIGV4cGxpY2l0bHkgaWRlbnRpZnkg4oCccmVmcmVzaCBmbG934oCd IGFuZC9vciDigJx1c2VyLWRlbGVnYXRpb24gZmxvd+KAnSBhbmQvb3Ig4oCcYXNzZXJ0aW9uIGZs b3figJ0gZXRjLg0KDQpCZWFyZXIgb3IgT0F1dGgyIFdXVy1BdXRoZW50aWNhdGUgcmVzcG9uc2Ug aGVhZGVyPw0KVGhlIHJ1bGUgc2hvdWxkIGJlOg0KIzEuIElmIHRoZSBjbGllbnQgY2FuIGZpeCBh biBlcnJvciBieSBzZW5kaW5nIGFuIOKAnEF1dGhvcml6YXRpb246IEJlYXJlciDigKbigJ0gcmVx dWVzdCBoZWFkZXIgKG9yIHRoZSBxdWVyeSBvciBQT1NUIGFsdGVybmF0aXZlKSB0aGVuIHRoZSBz ZXJ2ZXIgc2hvdWxkIHJldHVybiDigJxXV1ctQXV0aGVudGljYXRlOiBCZWFyZXIg4oCm4oCdLg0K DQojMi4gSWYgdGhlIGNsaWVudCBjYW4gZml4IGFuIGVycm9yIGJ5IHBlcmZvcm1pbmcgYW4gT0F1 dGgyIGZsb3cgYXQgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdGhlbiB0aGUgcmVzb3VyY2Ugc2Vy dmVyIHNob3VsZCByZXR1cm4g4oCcV1dXLUF1dGhlbnRpY2F0ZTogT0F1dGgyIOKApuKAnS4NCg0K VGhlIHNlcnZlciBjYW4gcmV0dXJuIGJvdGggcmVzcG9uc2UgaGVhZGVycyBpZiBib3RoIG9wdGlv bnMgYXJlIHBvc3NpYmxlLg0KDQpUaGVyZSBpcyBubyBwb2ludCBpbiByZS1wcmVzZW50aW5nIGEg cmVqZWN0ZWQgQmVhcmVyIHRva2VuIHNvICMxIGlzbuKAmXQgdGhhdCB1c2VmdWwuIEl0IGNvdWxk IGJlIGFwcHJvcHJpYXRlIGlmIG5vIHRva2VuIHdhcyBwcmVzZW50ZWQgYXMgdGhlIGNsaWVudCBt aWdodCBoYXZlIGEgdG9rZW4sIGJ1dCBkaWRu4oCZdCBrbm93IHRoaXMgcmVzb3VyY2UgbmVlZGVk IGl0LiBJdCBtaWdodCBiZSBhcHByb3ByaWF0ZSBpZiBhIGNsaWVudCBwcmVzZW50ZWQgYSB0b2tl biB3aXRoIGluc3VmZmljaWVudCBzY29wZSBhcyB0aGUgY2xpZW50IG1pZ2h0IGhhdmUgYW5vdGhl ciB0b2tlbiB3aXRoIHRoZSByaWdodCBzY29wZSBzbyDigJxXV1ctQXV0aGVudGljYXRlOiBCZWFy ZXIgc2NvcGU94oCm4oCdIGNvdWxkIGhlbHAuICMxIGlzIG5vdCByZWFsbHkgbmVjZXNzYXJ5IHdo ZW4gYSBwcmVzZW50ZWQgdG9rZW4gaXMgaW52YWxpZCBvciBleHBpcmVkIGFzIHRoZSBjbGllbnQg bmVlZHMgdG8gZ2V0IGEgbmV3IG9uZSAoZWcgdXNpbmcgYW4gT0F1dGgyIGZsb3cgdGhhdCBpcyBv dXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgQmVhcmVyIHNjaGVtZSkuDQoNCkkgZG9u4oCZdCB0aGlu ayBhbiBlcnJvciBjb2RlIGluIGEg4oCcV1dXLUF1dGhlbnRpY2F0ZTogQmVhcmVyIOKApuKAnSBy ZXNwb25zZSBoZWxwcyBhIGNsaWVudCByZXRyeSB0aGUgcmVxdWVzdCB3aXRoIGEg4oCcQXV0aG9y aXphdGlvbjogQmVhcmVyIOKApuKAnSBoZWFkZXIgdGhhdCB3aWxsIHdvcmsuDQpBbiBlcnJvciBj b2RlIG1pZ2h0IGhlbHAgYSBjbGllbnQgY2hvb3NlIHRoZSByaWdodCBPQXV0aDIgZmxvdyAoZWcg cmVmcmVzaCB2cyBuZXcgdXNlci1kZWxlZ2F0aW9uKSBzbyBpdCBtaWdodCBoYXZlIGEgcGxhY2Ug aW4gIzIsIGEg4oCcV1dXLUF1dGhlbnRpY2F0ZTogT0F1dGgyIOKApuKAnSByZXNwb25zZSBoZWFk ZXIuDQoNCkVyYW4gc2FpZCB0byBNaWtlOg0KPiBBbHRlcm5hdGl2ZWx5LCBpZiB5b3UgaGF2ZSB1 c2UgY2FzZXMgb3IgcmVxdWlyZW1lbnRzIGZvciBpbnRyb2R1Y2luZyBqdXN0IHRoZSBXV1ctQXV0 aGVudGljYXRlIHNpZGUgb2YgYW4gT0F1dGgyIGF1dGhvcml6YXRpb24gc2NoZW1lICh5b3VyIG9w ZW4gaXNzdWUpLCB3aGljaCBpbmNsdWRlcyBhbiDigJhlcnJvcuKAmSBhdHRyaWJ1dGUgZm9yIHVz ZSB3aXRoIHRoZSBwcm9wb3NlZCByZWdpc3RyeSwgcGxlYXNlIHByZXNlbnQgdGhvc2UgYW5kIGV4 cGxhaW4gaG93IGl0IHdpbGwgd29yayBhbG9uZ3NpZGUgdGhlIEJlYXJlciBhbmQgTUFDIHNjaGVt ZXMgKGFzIGN1cnJlbnRseSBkcmFmdGVkKS4NCg0KVGhlIOKAnGRpc2NvdmVyeeKAnSB1c2UtY2Fz ZSBpbiB0aGlzIGVtYWlsIHdhcnJhbnRzIHRoZSBXV1ctQXV0aGVudGljYXRlIHNpZGUgb2YgYW4g T0F1dGgyIHNjaGVtZS4NCkFuIGVycm9yIGF0dHJpYnV0ZSAocGx1cyBhIHJlZ2lzdHJ5KSBtaWdo dCBoZWxwLCBidXQgd2UgbmVlZCB0aGUgcmVzdCBvZiB0aGUgZGV0YWlscyBvZiB0aGUgcmVzcG9u c2UgaGVhZGVyIGZpcnN0Lg0KSXQgd29ya3Mgd2VsbCBhbG9uZ3NpZGUgQmVhcmVyIGFuZCBNQUMg c2NoZW1lczogYSDigJxXV1ctQXV0aC46IE9BdXRoMuKAnSByZXNwb25zZSBwb2ludHMgdG8gT0F1 dGgyIGZsb3dzIHRoZSBjbGllbnQgY2FuIHRyeTsgYSDigJxXV1ctQXV0aC46IE1BQy9CZWFyZXLi gJ0gcmVzcG9uc2UgcG9pbnRzIHRvIHJldHJ5aW5nIGEgcmVxdWVzdCB3aXRoIOKAnEF1dGh6OiBN QUMvQmVhcmVy4oCdLiBFdmVuIHdoZW4gYSBjbGllbnQgaXMgZ2l2ZW4gbXVsdGlwbGUgb3B0aW9u cyBpdCB3aWxsIGtub3cgd2hpY2ggdG8gY2hvb3NlIGJhc2VkIG9uIGl0cyBjb250ZXh0IChlZyBp ZiBpdCBkb2VzbuKAmXQgaGF2ZSBhbm90aGVyIEJlYXJlciB0b2tlbiBpdCB3aWxsIGlnbm9yZSB0 aGUg4oCcV1dXLUF1dGg6IEJlYXJlcuKAnSByZXNwb25zZSBhbmQgZm9sbG93IHRoZSDigJxXV1ct QXV0aDogT0F1dGgy4oCdIHJlc3BvbnNlKS4NCg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E3B2P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYg OSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwg bGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczt9DQpwLnlpdjI2NTk5MzAwOG1zb3BsYWludGV4dCwgbGkueWl2MjY1OTkzMDA4bXNvcGxh aW50ZXh0LCBkaXYueWl2MjY1OTkzMDA4bXNvcGxhaW50ZXh0DQoJe21zby1zdHlsZS1uYW1lOnlp djI2NTk5MzAwOG1zb3BsYWludGV4dDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KcC55aXYyNjU5OTMwMDhtc29hY2V0YXRlLCBsaS55aXYyNjU5OTMwMDhtc29h Y2V0YXRlLCBkaXYueWl2MjY1OTkzMDA4bXNvYWNldGF0ZQ0KCXttc28tc3R5bGUtbmFtZTp5aXYy NjU5OTMwMDhtc29hY2V0YXRlOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLnlpdjI2NTk5MzAwOG1zb25vcm1hbCwgbGkueWl2MjY1OTkzMDA4bXNvbm9ybWFs LCBkaXYueWl2MjY1OTkzMDA4bXNvbm9ybWFsDQoJe21zby1zdHlsZS1uYW1lOnlpdjI2NTk5MzAw OG1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K cC55aXYyNjU5OTMwMDhtc29jaHBkZWZhdWx0LCBsaS55aXYyNjU5OTMwMDhtc29jaHBkZWZhdWx0 LCBkaXYueWl2MjY1OTkzMDA4bXNvY2hwZGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5 OTMwMDhtc29jaHBkZWZhdWx0Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpzcGFuLnlpdjI2NTk5MzAwOG1zb2h5cGVybGluaw0KCXttc28tc3R5bGUtbmFtZTp5 aXYyNjU5OTMwMDhtc29oeXBlcmxpbms7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhtc29oeXBlcmxpbmtm b2xsb3dlZA0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhtc29oeXBlcmxpbmtmb2xsb3dl ZDt9DQpzcGFuLnlpdjI2NTk5MzAwOGh0bWxwcmVmb3JtYXR0ZWRjaGFyDQoJe21zby1zdHlsZS1u YW1lOnlpdjI2NTk5MzAwOGh0bWxwcmVmb3JtYXR0ZWRjaGFyO30NCnNwYW4ueWl2MjY1OTkzMDA4 cGxhaW50ZXh0Y2hhcg0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhwbGFpbnRleHRjaGFy O30NCnNwYW4ueWl2MjY1OTkzMDA4YmFsbG9vbnRleHRjaGFyDQoJe21zby1zdHlsZS1uYW1lOnlp djI2NTk5MzAwOGJhbGxvb250ZXh0Y2hhcjt9DQpzcGFuLnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUy Mw0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhlbWFpbHN0eWxlMjM7fQ0Kc3Bhbi55aXYy NjU5OTMwMDhlbWFpbHN0eWxlMjQNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4ZW1haWxz dHlsZTI0O30NCnNwYW4ueWl2MjY1OTkzMDA4ZW1haWxzdHlsZTI1DQoJe21zby1zdHlsZS1uYW1l OnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUyNTt9DQpzcGFuLnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUy Ng0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhlbWFpbHN0eWxlMjY7fQ0Kc3Bhbi55aXYy NjU5OTMwMDhlbWFpbHN0eWxlMjcNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4ZW1haWxz dHlsZTI3O30NCnNwYW4ueWl2MjY1OTkzMDA4ZW1haWxzdHlsZTI4DQoJe21zby1zdHlsZS1uYW1l OnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUyODt9DQpzcGFuLnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUy OQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhlbWFpbHN0eWxlMjk7fQ0Kc3Bhbi55aXYy NjU5OTMwMDhlbWFpbHN0eWxlMzANCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4ZW1haWxz dHlsZTMwO30NCnAueWl2MjY1OTkzMDA4bXNvbm9ybWFsMSwgbGkueWl2MjY1OTkzMDA4bXNvbm9y bWFsMSwgZGl2LnlpdjI2NTk5MzAwOG1zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1 OTkzMDA4bXNvbm9ybWFsMTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30N CnNwYW4ueWl2MjY1OTkzMDA4bXNvaHlwZXJsaW5rMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5 OTMwMDhtc29oeXBlcmxpbmsxOw0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLnlpdjI2NTk5MzAwOG1zb2h5cGVybGlua2ZvbGxvd2VkMQ0KCXttc28tc3R5 bGUtbmFtZTp5aXYyNjU5OTMwMDhtc29oeXBlcmxpbmtmb2xsb3dlZDE7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC55aXYyNjU5OTMwMDhtc29wbGFpbnRl eHQxLCBsaS55aXYyNjU5OTMwMDhtc29wbGFpbnRleHQxLCBkaXYueWl2MjY1OTkzMDA4bXNvcGxh aW50ZXh0MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhtc29wbGFpbnRleHQxOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0KcC55aXYyNjU5OTMwMDhtc29hY2V0 YXRlMSwgbGkueWl2MjY1OTkzMDA4bXNvYWNldGF0ZTEsIGRpdi55aXYyNjU5OTMwMDhtc29hY2V0 YXRlMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhtc29hY2V0YXRlMTsNCgltYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhodG1scHJlZm9y bWF0dGVkY2hhcjENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4aHRtbHByZWZvcm1hdHRl ZGNoYXIxOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhw bGFpbnRleHRjaGFyMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhwbGFpbnRleHRjaGFy MTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLnlpdjI2NTk5MzAw OGJhbGxvb250ZXh0Y2hhcjENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4YmFsbG9vbnRl eHRjaGFyMTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLnlpdjI2 NTk5MzAwOGVtYWlsc3R5bGUyMzENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4ZW1haWxz dHlsZTIzMTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4ueWl2MjY1OTkzMDA4ZW1haWxzdHlsZTI0MQ0KCXttc28tc3R5bGUtbmFt ZTp5aXYyNjU5OTMwMDhlbWFpbHN0eWxlMjQxOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMwMDIwNjA7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhlbWFpbHN0eWxlMjUx DQoJe21zby1zdHlsZS1uYW1lOnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUyNTE7DQoJZm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLnlpdjI2NTk5 MzAwOGVtYWlsc3R5bGUyNjENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4ZW1haWxzdHls ZTI2MTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMDAyMDYw O30NCnNwYW4ueWl2MjY1OTkzMDA4ZW1haWxzdHlsZTI3MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYy NjU5OTMwMDhlbWFpbHN0eWxlMjcxOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhlbWFpbHN0eWxlMjgxDQoJe21z by1zdHlsZS1uYW1lOnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUyODE7DQoJZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLnlpdjI2NTk5MzAwOGVt YWlsc3R5bGUyOTENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4ZW1haWxzdHlsZTI5MTsN Cglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4ueWl2MjY1OTkzMDA4ZW1haWxzdHlsZTMwMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5OTMw MDhlbWFpbHN0eWxlMzAxOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KcC55aXYyNjU5OTMwMDhtc29jaHBkZWZhdWx0MSwgbGkueWl2MjY1OTkz MDA4bXNvY2hwZGVmYXVsdDEsIGRpdi55aXYyNjU5OTMwMDhtc29jaHBkZWZhdWx0MQ0KCXttc28t c3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhtc29jaHBkZWZhdWx0MTsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlNTMNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVl IHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGFncmVlIHRoYXQgTGluayBoZWFkZXJzIGFyZSBtdWNo IGJldHRlciBmaXQgZm9yIHJlbGF5aW5nIGRpc2NvdmVyeSBpbmZvcm1hdGlvbiB0aGFuIGEgaGFs ZiBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZS4gT3ZlcmFsbCwgSSBmaW5kIEphbWVz4oCZIHBy b3Bvc2FsIHRvIGJlIHRvbyBjb21wbGV4IGFuZCBub3QgaW50dWl0aXZlIHRvIHBlb3BsZSBmYW1p bGlhciB3aXRoIGV4aXN0aW5nIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcyAoaXQgaXMgbm92 ZWwgYW5kIHdlbGwgdGhvdWdodCwgYW5kIGl0IGRvZXMgd29yaywganVzdCBub3QgYXMgbW9zdCBw ZW9wbGUgZXhwZWN0IGRpc2NvdmVyeSB0bykuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FSEw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPldpbGxpYW0gSi4gTWlsbHM8 YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxMSA3OjAxIFBNPGJyPjxiPlRv OjwvYj4gTWFuZ2VyLCBKYW1lcyBIOyBPQXV0aCBXRzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtP QVVUSC1XR10gT0F1dGgyIHNjaGVtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPkluIHRoZSBTQVNMIG1lY2hhbmlzbSBkcmFm dCBzcGVjIHdoZXJlIHdlIHdlbnQgd2l0aCB0aGF0IGlzIHRvIHVzZSBMSU5LIGhlYWRlcnMuJm5i c3A7IFNlZSA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taWxscy1r aXR0ZW4tc2FzbC1vYXV0aC0wMSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWls bHMta2l0dGVuLXNhc2wtb2F1dGgtMDE8L2E+IGlmIHlvdSB3YW50IHRvIHRha2UgYSBsb29rLiZu YnNwOyBXV1ctQXV0aGVudGljYXRlIGhlYWRlcnMgcmV0dXJuIHRoZSBzdXBwb3J0ZWQgYXV0aGVu dGljYXRpb24gc2NoZW1lcyBhbmQgTElOSyBoZWFkZXJzIHRlbGwgeW91IHRoZXJlIGFyZSBPQXV0 aCBlbmRwb2ludHMgeW91IGNhbiBpbnRlcmFjdCB3aXRoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6YmxhY2snPkl0J3MgYSBzd2FnIGF0IGRpc2NvdmVyeSBpbiBiYW5kLCBtaWdodCB3b3Jr IGhlcmUgdG9vLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxkaXY+PGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0 LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PGhyIHNp emU9MSB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyPjwvc3Bhbj48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiAmcXVvdDtNYW5nZXIsIEphbWVzIEgmcXVv dDsgJmx0O0phbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20mZ3Q7PGJyPjxiPlRvOjwvYj4g T0F1dGggV0cgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXks IEFwcmlsIDcsIDIwMTEgNjo0OCBQTTxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10g T0F1dGgyIHNjaGVtZTxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YnI+PGJy PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2IGlkPXlpdjI2NTk5MzAwOD48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+V2Ugc2hvdWxkIGRlZmluZSBhIOKAnFdXVy1BdXRoZW50aWNhdGU6IE9BdXRo MiDigKbigJ0gcmVzcG9uc2UgaGVhZGVyIOKAkyBub3QgdG8gZW5jb21wYXNzIHRoZSBNQUMsIEJl YXJlciwgYW5kIGFueSBvdGhlciBnZW5lcmljIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lLCBi dXQgYXMgYSB3YXkgZm9yIGEgc2VydmVyIHRvIHRlbGwgdGhlIGNsaWVudCB0aGF0IGl0IGNhbiBw ZXJmb3JtIGFuIE9BdXRoMiBnZXQtYS10b2tlbiBmbG93IHRvIGdhaW4gYWNjZXNzLiBXaGVuIHRo ZSBzb3J0IG9mIE9BdXRoMiBmbG93IGRlcGVuZHMgb24gdGhlIGVycm9yIHdpdGggYSBjdXJyZW50 IHRva2VuIChlZyBleHBpcmVkIHZzIGludmFsaWQpIHRoZW4gdGhlIOKAnFdXVy1BdXRoZW50aWNh dGU6IE9BdXRoMiDigKbigJ0gcmVzcG9uc2UgaGVhZGVyIG5lZWRzIHRvIHJlZmxlY3QgdGhpcy4g SXQgY291bGQgZG8gc28gYmUgaW5jbHVkaW5nIGFuIGVycm9yIGNvZGUuIEEgYmV0dGVyLCBtb3Jl IGRpcmVjdCwgYXBwcm9hY2ggaXMgdG8gZXhwbGljaXRseSBpZGVudGlmeSDigJxyZWZyZXNoIGZs b3figJ0gYW5kL29yIOKAnHVzZXItZGVsZWdhdGlvbiBmbG934oCdIGFuZC9vciDigJxhc3NlcnRp b24gZmxvd+KAnSBldGMuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48Yj48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+QmVhcmVyIG9yIE9BdXRoMiBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNl IGhlYWRlcj88L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5k OndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhlIHJ1bGUgc2hvdWxkIGJlOjwv c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiMxLiBJZiB0aGUgY2xpZW50IGNhbiBmaXggYW4gZXJyb3Ig Ynkgc2VuZGluZyBhbiDigJxBdXRob3JpemF0aW9uOiBCZWFyZXIg4oCm4oCdIHJlcXVlc3QgaGVh ZGVyIChvciB0aGUgcXVlcnkgb3IgUE9TVCBhbHRlcm5hdGl2ZSkgdGhlbiB0aGUgc2VydmVyIHNo b3VsZCByZXR1cm4g4oCcV1dXLUF1dGhlbnRpY2F0ZTogQmVhcmVyIOKApuKAnS48L3NwYW4+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4jMi4gSWYgdGhlIGNs aWVudCBjYW4gZml4IGFuIGVycm9yIGJ5IHBlcmZvcm1pbmcgYW4gT0F1dGgyIGZsb3cgYXQgYW4g YXV0aG9yaXphdGlvbiBzZXJ2ZXIgdGhlbiB0aGUgcmVzb3VyY2Ugc2VydmVyIHNob3VsZCByZXR1 cm4g4oCcV1dXLUF1dGhlbnRpY2F0ZTogT0F1dGgyIOKApuKAnS48L3NwYW4+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5UaGUgc2VydmVyIGNhbiByZXR1cm4g Ym90aCByZXNwb25zZSBoZWFkZXJzIGlmIGJvdGggb3B0aW9ucyBhcmUgcG9zc2libGUuPC9zcGFu PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhlcmUgaXMg bm8gcG9pbnQgaW4gcmUtcHJlc2VudGluZyBhIHJlamVjdGVkIEJlYXJlciB0b2tlbiBzbyAjMSBp c27igJl0IHRoYXQgdXNlZnVsLiBJdCBjb3VsZCBiZSBhcHByb3ByaWF0ZSBpZiBubyB0b2tlbiB3 YXMgcHJlc2VudGVkIGFzIHRoZSBjbGllbnQgbWlnaHQgaGF2ZSBhIHRva2VuLCBidXQgZGlkbuKA mXQga25vdyB0aGlzIHJlc291cmNlIG5lZWRlZCBpdC4gSXQgbWlnaHQgYmUgYXBwcm9wcmlhdGUg aWYgYSBjbGllbnQgcHJlc2VudGVkIGEgdG9rZW4gd2l0aCBpbnN1ZmZpY2llbnQgc2NvcGUgYXMg dGhlIGNsaWVudCBtaWdodCBoYXZlIGFub3RoZXIgdG9rZW4gd2l0aCB0aGUgcmlnaHQgc2NvcGUg c28g4oCcV1dXLUF1dGhlbnRpY2F0ZTogQmVhcmVyIHNjb3BlPeKApuKAnSBjb3VsZCBoZWxwLiAj MSBpcyBub3QgcmVhbGx5IG5lY2Vzc2FyeSB3aGVuIGEgcHJlc2VudGVkIHRva2VuIGlzIGludmFs aWQgb3IgZXhwaXJlZCBhcyB0aGUgY2xpZW50IG5lZWRzIHRvIGdldCBhIG5ldyBvbmUgKGVnIHVz aW5nIGFuIE9BdXRoMiBmbG93IHRoYXQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIEJlYXJl ciBzY2hlbWUpLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPkkgZG9u4oCZdCB0aGluayBhbiBlcnJvciBjb2RlIGluIGEg4oCcV1dXLUF1dGhlbnRp Y2F0ZTogQmVhcmVyIOKApuKAnSByZXNwb25zZSBoZWxwcyBhIGNsaWVudCByZXRyeSB0aGUgcmVx dWVzdCB3aXRoIGEg4oCcQXV0aG9yaXphdGlvbjogQmVhcmVyIOKApuKAnSBoZWFkZXIgdGhhdCB3 aWxsIHdvcmsuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndo aXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+QW4gZXJyb3IgY29kZSBtaWdodCBoZWxw IGEgY2xpZW50IGNob29zZSB0aGUgcmlnaHQgT0F1dGgyIGZsb3cgKGVnIHJlZnJlc2ggdnMgbmV3 IHVzZXItZGVsZWdhdGlvbikgc28gaXQgbWlnaHQgaGF2ZSBhIHBsYWNlIGluICMyLCBhIOKAnFdX Vy1BdXRoZW50aWNhdGU6IE9BdXRoMiDigKbigJ0gcmVzcG9uc2UgaGVhZGVyLjwvc3Bhbj48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkVyYW4gc2FpZCB0byBN aWtlOjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZndDsgQWx0ZXJuYXRpdmVseSwgaWYgeW91IGhh dmUgdXNlIGNhc2VzIG9yIHJlcXVpcmVtZW50cyBmb3IgaW50cm9kdWNpbmcganVzdCB0aGUgV1dX LUF1dGhlbnRpY2F0ZSBzaWRlIG9mIGFuIE9BdXRoMiBhdXRob3JpemF0aW9uIHNjaGVtZSAoeW91 ciBvcGVuIGlzc3VlKSwgd2hpY2ggaW5jbHVkZXMgYW4g4oCYZXJyb3LigJkgYXR0cmlidXRlIGZv ciB1c2Ugd2l0aCB0aGUgcHJvcG9zZWQgcmVnaXN0cnksIHBsZWFzZSBwcmVzZW50IHRob3NlIGFu ZCBleHBsYWluIGhvdyBpdCB3aWxsIHdvcmsgYWxvbmdzaWRlIHRoZSBCZWFyZXIgYW5kIE1BQyBz Y2hlbWVzIChhcyBjdXJyZW50bHkgZHJhZnRlZCkuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhlIOKAnGRpc2NvdmVyeeKAnSB1c2UtY2FzZSBp biB0aGlzIGVtYWlsIHdhcnJhbnRzIHRoZSBXV1ctQXV0aGVudGljYXRlIHNpZGUgb2YgYW4gT0F1 dGgyIHNjaGVtZS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5BbiBlcnJvciBhdHRyaWJ1dGUgKHBs dXMgYSByZWdpc3RyeSkgbWlnaHQgaGVscCwgYnV0IHdlIG5lZWQgdGhlIHJlc3Qgb2YgdGhlIGRl dGFpbHMgb2YgdGhlIHJlc3BvbnNlIGhlYWRlciBmaXJzdC48L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz5JdCB3b3JrcyB3ZWxsIGFsb25nc2lkZSBCZWFyZXIgYW5kIE1BQyBzY2hlbWVzOiBhIOKAnFdX Vy1BdXRoLjogT0F1dGgy4oCdIHJlc3BvbnNlIHBvaW50cyB0byBPQXV0aDIgZmxvd3MgdGhlIGNs aWVudCBjYW4gdHJ5OyBhIOKAnFdXVy1BdXRoLjogTUFDL0JlYXJlcuKAnSByZXNwb25zZSBwb2lu dHMgdG8gcmV0cnlpbmcgYSByZXF1ZXN0IHdpdGgg4oCcQXV0aHo6IE1BQy9CZWFyZXLigJ0uIEV2 ZW4gd2hlbiBhIGNsaWVudCBpcyBnaXZlbiBtdWx0aXBsZSBvcHRpb25zIGl0IHdpbGwga25vdyB3 aGljaCB0byBjaG9vc2UgYmFzZWQgb24gaXRzIGNvbnRleHQgKGVnIGlmIGl0IGRvZXNu4oCZdCBo YXZlIGFub3RoZXIgQmVhcmVyIHRva2VuIGl0IHdpbGwgaWdub3JlIHRoZSDigJxXV1ctQXV0aDog QmVhcmVy4oCdIHJlc3BvbnNlIGFuZCBmb2xsb3cgdGhlIOKAnFdXVy1BdXRoOiBPQXV0aDLigJ0g cmVzcG9uc2UpLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNr Z3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+LS08L3NwYW4+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlJz48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPjxicj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRt bD4= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E3B2P3PW5EX1MB01E_-- From torsten@lodderstedt.net Thu Apr 7 23:25:06 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B9E3A6804 for ; Thu, 7 Apr 2011 23:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BTYWQm9pXba for ; Thu, 7 Apr 2011 23:25:01 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by core3.amsl.com (Postfix) with ESMTP id A2F493A687E for ; Thu, 7 Apr 2011 23:25:00 -0700 (PDT) Received: from [80.187.100.84] (helo=[192.168.43.164]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Q859X-0004l3-4M; Fri, 08 Apr 2011 08:26:43 +0200 Message-ID: <4D9EAAA2.9030809@lodderstedt.net> Date: Fri, 08 Apr 2011 08:26:42 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Skylar Woodward References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> In-Reply-To: <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 06:25:06 -0000 Hi Skylar, Am 06.04.2011 18:02, schrieb Skylar Woodward: > Well, I should elaborate. The method of authorization is open to the client, and in this case (Kiva), MAC tokens are being used. The client authenticates on the access_token request by presenting a MAC authentication header. Creating the MAC signature requires a secret. In the native client case, since there is no secret, it signs with the empty string. So, how would you interpret this mechanism? Are we using an empty string secret or signing without a secret? In terms of communicating to the developers, they are told they don't have a secret. For purposes of signing, they are instructed to sign with them empty string when they have no secret. You are talking about using the client secret to authenticate resource server request, correct? This is not in scope of the core spec. I was talking about authenticating the client with the authorization server. Apart from that, do you think singing with an empty string adds any security to your solution? Moreover as far as I understand the MAC-Spec, it recommends to use authorization server issued secrets to sign the request. So why do you need a client secret for request signing? > Alternatively, one could use Bearer token for client authentication in this case where the token is just the client ID. To me this is more confusing because they must authenticate with different token types for secret vs. non-secret. Other opinions? I'm confused now, why is the token the client id? A token is used by the authorization server and may contain (or refer to) any data you need to authorize access of the client to the resource server. > As to the question of interoperability, the fact that OAuth allows freedom of choice to the AS for method of authentication makes this point moot. Would you agree? (short of various providers could pooling together to standardize on an auth method outside of the spec). What authentication are you refering to? Who do you want to authenticate? regards, Torsten. > > > On Apr 4, 2011, at 10:15 PM, torsten@lodderstedt.net wrote: > >> Hi Skylar, >> >> Thank you for sharing this information with us. Some thougts: >> >> The empty string makes your implementation syntactically compliant but does obviously not comply with its semantics and the security considerations/expectations associated with a secret. Moreover, what about interoperability? >> >> I think not using secrets for such clients is the honest solution. We can just change the spec's text to express what we think is the right way. >> >> regards, >> Torsten. >> Gesendet mit BlackBerry® Webmail von Telekom Deutschland >> >> -----Original Message----- >> From: Skylar Woodward >> Date: Mon, 4 Apr 2011 19:14:53 >> To: Torsten Lodderstedt >> Cc: Zeltsan, Zachary (Zachary); Kris Selden; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >> >> In our implementation (not yet public) we accept the empty string ("") as the value for clients not issued secrets. While this was done to simplify the interface and implementation, it would make it compliant in my view. In this case, the authorization server is validating the credentials, which are the client ID and the empty string, which is equivalent security-wise to any other length of "secret" issued to a native client. >> >> Besides, for many providers, the client credentials will only be a client ID. They would plan to secure all exchanges over TLS and credentials serve just as a tracking device or at best, a weak form of identification. >> >> skylar >> >> On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote: >> >>> Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): >>>> According to section "6 Refreshing an Access Token" (-13.txt), client when making a request for exchanging a refresh token for an access token has to include its authentication credentials, and the "authorization server MUST validate the client credentials". >>>> How can this be done if a client is an application that can't have a client secret? >>>> The authorization code grant does require client authentication (per section 4.1): >>>> >>>> (D) The client requests an access token from the authorization >>>> server's token endpoint by authenticating using its client >>>> credentials, and includes the authorization code received in the >>>> previous step. >>>> >>>> It appears that the clients that cannot keep its secret cannot use (be issued) the refresh tokens. >>> In my opinion, this part of the spec is misleading. Authorization code MUST be possible without client authentication. Otherwise, OAuth is useless for native apps. >>> >>> http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-01#section-2.10 describes how the flow can be protected in such cases. >>> >>> regards, >>> Torsten. >>>> Zachary >>>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Marius Scurtescu >>>> Sent: Monday, April 04, 2011 2:30 PM >>>> To: Kris Selden >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>> >>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wrote: >>>>> A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once. >>>>> >>>>> What is the best profile to use for an app that can't have a client secret and needs a refresh token or a long lived access token? >>>> The authorization code grant, aka web server flow. >>>> >>>> The spec is misleading in this respect IMO. >>>> >>>> Marius >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Thu Apr 7 23:45:34 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBE53A6A4B for ; Thu, 7 Apr 2011 23:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi8hV-MU9wnb for ; Thu, 7 Apr 2011 23:45:32 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id EBC233A6A4D for ; Thu, 7 Apr 2011 23:45:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,322,1299416400"; d="scan'208,217";a="31843384" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 08 Apr 2011 16:47:15 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6309"; a="23239772" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbvi.tcif.telstra.com.au with ESMTP; 08 Apr 2011 16:47:15 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 8 Apr 2011 16:47:14 +1000 From: "Manger, James H" To: Eran Hammer-Lahav , "William J. Mills" , OAuth WG Date: Fri, 8 Apr 2011 16:47:12 +1000 Thread-Topic: [OAUTH-WG] OAuth2 scheme Thread-Index: Acv1kNC34sbetPHWRwidgxX3rNPfogAACTawAANZ6bA= Message-ID: <255B9BB34FB7D647A506DC292726F6E11281D30832@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465664E11D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281CAB8DB@WSMSG3153V.srv.dir.telstra.com> <249220.24403.qm@web32303.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E3B2@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664E3B2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11281D30832WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth2 scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 06:45:34 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11281D30832WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBXV1ctQXV0aCBoZWFkZXIgaXMgYSBzZXJ2ZXLigJlzIHNlY3VyaXR5IHN0YXRlbWVudCBhYm91 dCBob3cgdG8gZ2FpbiBhY2Nlc3MuDQoNCkEgTGluayBoZWFkZXIgaXMgYSBzZXJ2ZXLigJlzIHN0 YXRlbWVudCBvZiBhIHJlbGF0aW9uc2hpcCB0byBhbm90aGVyIFVSSS4NCg0KDQoNCkkgZmluZCB0 aGUgTGlua3MrV1dXLUF1dGggYXBwcm9hY2ggbW9yZSBjb21wbGV4LCBsZXNzIGludHVpdGl2ZSwg YW5kIG5vdCBhcyBnb29kIGEgbWF0Y2ggZm9yIEhUVFAgc2VtYW50aWNzLg0KDQpFYWNoIFdXVy1B dXRoIGhlYWRlciBpbiBteSBhcHByb2FjaCBpcyBhIHN0YW5kYWxvbmUgc3RhdGVtZW50IG9mIGEg cGF0aCB0aGUgY2xpZW50IGNhbiB0YWtlIHRvIGdhaW4gYWNjZXNzLiBXaGVuIGFuIE9BdXRoMiBm bG93IGlzIGEgcG9zc2libGUgcGF0aCwgaW5jbHVkZSBhIOKAnFdXVy1BdXRoOiBPQXV0aDIg4oCm 4oCdIHJlc3BvbnNlIGhlYWRlci4NCg0KVXNpbmcgTGlua3MrV1dXLUF1dGggcmVxdWlyZXMgaW50 ZXJwcmV0aW5nIGEgY29tYmluYXRpb24gb2YgaGVhZGVycy4NCg0KDQoNCmRyYWZ0LW1pbGxzLWtp dHRlbi1zYXNsLW9hdXRoLTAxI3NlY3Rpb24tNy4yIGhhcyBhbiBleGFtcGxlIG9mIGEgZXJyb3Ig cmVzcG9uc2U6DQoNCiAgIEhUVFAvMS4xIDQwMSBVbmF1dGhvcml6ZWQNCg0KICAgV1dXLUF1dGhl bnRpY2F0ZTogQkVBUkVSIHJlYWxtPSJleGFtcGxlLmNvbSINCg0KICAgTGluazogPGh0dHBzOi8v bG9naW4ueWFob28uY29tL29hdXRoPiByZWw9Im9hdXRoMi1hdXRoZW50aWNhdG9yIg0KDQogICBM aW5rOiA8aHR0cHM6Ly9sb2dpbi55YWhvby5jb20vb2F1dGg+IHJlbD0ib3VhdGgyLXRva2VuIg0K DQoNCg0KQSBMaW5rIGhlYWRlciBpcyBhIG5pY2UsIGNsZWFuLCBpbnR1aXRpdmUgYXBwcm9hY2gg Zm9yIGRlbGl2ZXJpbmcgYSBzdGF0aWMgdG9rZW4gZW5kcG9pbnQgVVJJLg0KDQpIb3dldmVyLCB0 aGF0IGlzIG5vdCBhY3R1YWxseSB3aGF0IGEgY2xpZW50IG5lZWRzIGluIGFuIEhUVFAgZXJyb3Ig cmVzcG9uc2UuIFRoZSBjbGllbnQgbmVlZHMgdG8ga25vdyB3aGF0IHRvIGRvIG5leHQsIGluIHRo ZSBjb250ZXh0IG9mIHRoaXMgcmVxdWVzdCBhbmQgdGhlIGNyZWRlbnRpYWxzIGl0IGluY2x1ZGVk LiBUaGF0IGlzIG1vcmUgZHluYW1pYy4NCg0KDQoNCkNvbnNpZGVyIHRoZSBlcnJvciBjb2RlcyB0 aGF0IE1pa2UgSm9uZXMgJiBvdGhlcnMgd2FudCB0byBzdGFuZGFyZGlzZS9yZWdpc3RlciBhY3Jv c3MgYXV0aGVudGljYXRpb24gc2NoZW1lcy4gVGhleSBhcmUgbmVlZGVkIHRvIGtub3cgd2hpY2gg T0F1dGgyIGZsb3cgdG8gcGVyZm9ybSAoZWcgdHJ5IGEgcmVmcmVzaCBpZiB0aGUgdG9rZW4gaGFz IGV4cGlyZWQ7IHJlZG8gdXNlciBkZWxlZ2F0aW9uIGlmIG1vcmUgc2NvcGUgaXMgbmVlZGVkKS4N Cg0KDQoNClNob3VsZCB0aGUgZXJyb3IgY29kZSBnbyBpbiBhbiBPQXV0aDIgTGluayBoZWFkZXI/ IFRoYXQgZmVlbHMgYSBiaXQgc3RyYW5nZS4gSXQgcmVxdWlyZXMgZXh0cmEgcGFyYW1ldGVycyB0 byBiZSBkZWZpbmVkIGZvciBzcGVjaWZpYyBMaW5rIHJlbGF0aW9ucyAocG9zc2libGUsIGJ1dCBu b3QgYXMgaW50dWl0aXZlKS4gTm8gb25lIGhhcyBzdWdnZXN0ZWQgdGhpcywgdGhvdWdoIEkgdGhp bmsgaXQgaXMgdGhlIGNvcnJlY3QgZGVzaWduIGlmIExpbmtzK1dXVy1BdXRoIGlzIHVzZWQuDQoN ClRoZSBvdGhlciBvcHRpb24gaXMgdG8gcHV0IHRoZSBlcnJvciBjb2RlIGluIHRoZSBXV1ctQXV0 aCBoZWFkZXIgZm9yIGEgc3BlY2lmaWMgc2NoZW1lLiBXaGljaCBzY2hlbWU/IEV2ZXJ5IHNjaGVt ZSBmb3Igd2hpY2ggT0F1dGgyIGNvdWxkIGRlbGl2ZXIgYSB0b2tlbiBub3cgbmVlZHMgdG8gYmUg bW9kaWZpZWQgc28gaXRzIGVycm9yIHJlc3BvbnNlIGNhbiBpbmNsdWRlIE9BdXRoMi1zcGVjaWZp YyBkZXRhaWxzLiBUaGF0IGlzIGZlYXNpYmxlIGZvciB0aGUgQmVhcmVyIHNjaGVtZSwgYnV0IG5v dCBnZW5lcmFsbHkuIFRoZXJlIGlzIG5vIFdXVy1BdXRoIGhlYWRlciB0byBwdXQgdGhlIGVycm9y IGNvZGUgaW4gaWYsIHNheSwgdGhlIFRMUyBsYXllciBpcyB1c2VkIGZvciBjbGllbnQgYXV0aGVu dGljYXRpb24gKGVnIFRMUy1QU0sgb3IgVExTLVNSUCBvciDigKYpLg0KDQpUaGlzIG1pZ2h0IGJl IGEgdHJpdmlhbCBpc3N1ZSBpZiBPQXV0aDIgaXMgb25seSBldmVyIHVzZWQgd2l0aCB0aGUgQmVh cmVyIEhUVFAgc2NoZW1lcyDigJMgYnV0IGl0IGRvZXMgaWxsdXN0cmF0ZSBhIGRlc2lnbiBmbGF3 OiBvbmUgbW9yZSB1bm5lY2Vzc2FyeSBzdHJvbmcgY291cGxpbmcgYmV0d2VlbiB0aGUgYXV0aGVu dGljYXRpb24gbWVjaGFuaXNtIGFuZCB0aGUgT0F1dGgyIGRlbGVnYXRpb24vYXV0aG9yaXphdGlv biBmbG93cy4NCg0KDQoNCg0KDQotLQ0KDQpKYW1lcyBNYW5nZXINCg0KDQoNCg0KDQpGcm9tOiBF cmFuIEhhbW1lci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dDQpTZW50OiBGcmlk YXksIDggQXByaWwgMjAxMSAxMjowNCBQTQ0KVG86IFdpbGxpYW0gSi4gTWlsbHM7IE1hbmdlciwg SmFtZXMgSDsgT0F1dGggV0cNClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIE9BdXRoMiBzY2hlbWUN Cg0KDQoNCkkgYWdyZWUgdGhhdCBMaW5rIGhlYWRlcnMgYXJlIG11Y2ggYmV0dGVyIGZpdCBmb3Ig cmVsYXlpbmcgZGlzY292ZXJ5IGluZm9ybWF0aW9uIHRoYW4gYSBoYWxmIEhUVFAgYXV0aGVudGlj YXRpb24gc2NoZW1lLiBPdmVyYWxsLCBJIGZpbmQgSmFtZXPigJkgcHJvcG9zYWwgdG8gYmUgdG9v IGNvbXBsZXggYW5kIG5vdCBpbnR1aXRpdmUgdG8gcGVvcGxlIGZhbWlsaWFyIHdpdGggZXhpc3Rp bmcgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIChpdCBpcyBub3ZlbCBhbmQgd2VsbCB0aG91 Z2h0LCBhbmQgaXQgZG9lcyB3b3JrLCBqdXN0IG5vdCBhcyBtb3N0IHBlb3BsZSBleHBlY3QgZGlz Y292ZXJ5IHRvKS4NCg0KDQoNCkVITA0KDQoNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXaWxsaWFtIEou IE1pbGxzDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTEgNzowMSBQTQ0KVG86IE1hbmdl ciwgSmFtZXMgSDsgT0F1dGggV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoMiBzY2hl bWUNCg0KDQoNCkluIHRoZSBTQVNMIG1lY2hhbmlzbSBkcmFmdCBzcGVjIHdoZXJlIHdlIHdlbnQg d2l0aCB0aGF0IGlzIHRvIHVzZSBMSU5LIGhlYWRlcnMuICBTZWUgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbWlsbHMta2l0dGVuLXNhc2wtb2F1dGgtMDEgaWYgeW91IHdhbnQgdG8g dGFrZSBhIGxvb2suICBXV1ctQXV0aGVudGljYXRlIGhlYWRlcnMgcmV0dXJuIHRoZSBzdXBwb3J0 ZWQgYXV0aGVudGljYXRpb24gc2NoZW1lcyBhbmQgTElOSyBoZWFkZXJzIHRlbGwgeW91IHRoZXJl IGFyZSBPQXV0aCBlbmRwb2ludHMgeW91IGNhbiBpbnRlcmFjdCB3aXRoLg0KDQoNCg0KSXQncyBh IHN3YWcgYXQgZGlzY292ZXJ5IGluIGJhbmQsIG1pZ2h0IHdvcmsgaGVyZSB0b28uDQoNCg0KDQog IF9fX19fDQoNCkZyb206ICJNYW5nZXIsIEphbWVzIEgiIDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRl bHN0cmEuY29tPg0KVG86IE9BdXRoIFdHIDxvYXV0aEBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5 LCBBcHJpbCA3LCAyMDExIDY6NDggUE0NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoMiBz Y2hlbWUNCg0KDQoNCldlIHNob3VsZCBkZWZpbmUgYSDigJxXV1ctQXV0aGVudGljYXRlOiBPQXV0 aDIg4oCm4oCdIHJlc3BvbnNlIGhlYWRlciDigJMgbm90IHRvIGVuY29tcGFzcyB0aGUgTUFDLCBC ZWFyZXIsIGFuZCBhbnkgb3RoZXIgZ2VuZXJpYyBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSwg YnV0IGFzIGEgd2F5IGZvciBhIHNlcnZlciB0byB0ZWxsIHRoZSBjbGllbnQgdGhhdCBpdCBjYW4g cGVyZm9ybSBhbiBPQXV0aDIgZ2V0LWEtdG9rZW4gZmxvdyB0byBnYWluIGFjY2Vzcy4gV2hlbiB0 aGUgc29ydCBvZiBPQXV0aDIgZmxvdyBkZXBlbmRzIG9uIHRoZSBlcnJvciB3aXRoIGEgY3VycmVu dCB0b2tlbiAoZWcgZXhwaXJlZCB2cyBpbnZhbGlkKSB0aGVuIHRoZSDigJxXV1ctQXV0aGVudGlj YXRlOiBPQXV0aDIg4oCm4oCdIHJlc3BvbnNlIGhlYWRlciBuZWVkcyB0byByZWZsZWN0IHRoaXMu IEl0IGNvdWxkIGRvIHNvIGJlIGluY2x1ZGluZyBhbiBlcnJvciBjb2RlLiBBIGJldHRlciwgbW9y ZSBkaXJlY3QsIGFwcHJvYWNoIGlzIHRvIGV4cGxpY2l0bHkgaWRlbnRpZnkg4oCccmVmcmVzaCBm bG934oCdIGFuZC9vciDigJx1c2VyLWRlbGVnYXRpb24gZmxvd+KAnSBhbmQvb3Ig4oCcYXNzZXJ0 aW9uIGZsb3figJ0gZXRjLg0KDQoNCg0KQmVhcmVyIG9yIE9BdXRoMiBXV1ctQXV0aGVudGljYXRl IHJlc3BvbnNlIGhlYWRlcj8NCg0KVGhlIHJ1bGUgc2hvdWxkIGJlOg0KDQojMS4gSWYgdGhlIGNs aWVudCBjYW4gZml4IGFuIGVycm9yIGJ5IHNlbmRpbmcgYW4g4oCcQXV0aG9yaXphdGlvbjogQmVh cmVyIOKApuKAnSByZXF1ZXN0IGhlYWRlciAob3IgdGhlIHF1ZXJ5IG9yIFBPU1QgYWx0ZXJuYXRp dmUpIHRoZW4gdGhlIHNlcnZlciBzaG91bGQgcmV0dXJuIOKAnFdXVy1BdXRoZW50aWNhdGU6IEJl YXJlciDigKbigJ0uDQoNCg0KDQojMi4gSWYgdGhlIGNsaWVudCBjYW4gZml4IGFuIGVycm9yIGJ5 IHBlcmZvcm1pbmcgYW4gT0F1dGgyIGZsb3cgYXQgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdGhl biB0aGUgcmVzb3VyY2Ugc2VydmVyIHNob3VsZCByZXR1cm4g4oCcV1dXLUF1dGhlbnRpY2F0ZTog T0F1dGgyIOKApuKAnS4NCg0KDQoNClRoZSBzZXJ2ZXIgY2FuIHJldHVybiBib3RoIHJlc3BvbnNl IGhlYWRlcnMgaWYgYm90aCBvcHRpb25zIGFyZSBwb3NzaWJsZS4NCg0KDQoNClRoZXJlIGlzIG5v IHBvaW50IGluIHJlLXByZXNlbnRpbmcgYSByZWplY3RlZCBCZWFyZXIgdG9rZW4gc28gIzEgaXNu 4oCZdCB0aGF0IHVzZWZ1bC4gSXQgY291bGQgYmUgYXBwcm9wcmlhdGUgaWYgbm8gdG9rZW4gd2Fz IHByZXNlbnRlZCBhcyB0aGUgY2xpZW50IG1pZ2h0IGhhdmUgYSB0b2tlbiwgYnV0IGRpZG7igJl0 IGtub3cgdGhpcyByZXNvdXJjZSBuZWVkZWQgaXQuIEl0IG1pZ2h0IGJlIGFwcHJvcHJpYXRlIGlm IGEgY2xpZW50IHByZXNlbnRlZCBhIHRva2VuIHdpdGggaW5zdWZmaWNpZW50IHNjb3BlIGFzIHRo ZSBjbGllbnQgbWlnaHQgaGF2ZSBhbm90aGVyIHRva2VuIHdpdGggdGhlIHJpZ2h0IHNjb3BlIHNv IOKAnFdXVy1BdXRoZW50aWNhdGU6IEJlYXJlciBzY29wZT3igKbigJ0gY291bGQgaGVscC4gIzEg aXMgbm90IHJlYWxseSBuZWNlc3Nhcnkgd2hlbiBhIHByZXNlbnRlZCB0b2tlbiBpcyBpbnZhbGlk IG9yIGV4cGlyZWQgYXMgdGhlIGNsaWVudCBuZWVkcyB0byBnZXQgYSBuZXcgb25lIChlZyB1c2lu ZyBhbiBPQXV0aDIgZmxvdyB0aGF0IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBCZWFyZXIg c2NoZW1lKS4NCg0KDQoNCkkgZG9u4oCZdCB0aGluayBhbiBlcnJvciBjb2RlIGluIGEg4oCcV1dX LUF1dGhlbnRpY2F0ZTogQmVhcmVyIOKApuKAnSByZXNwb25zZSBoZWxwcyBhIGNsaWVudCByZXRy eSB0aGUgcmVxdWVzdCB3aXRoIGEg4oCcQXV0aG9yaXphdGlvbjogQmVhcmVyIOKApuKAnSBoZWFk ZXIgdGhhdCB3aWxsIHdvcmsuDQoNCkFuIGVycm9yIGNvZGUgbWlnaHQgaGVscCBhIGNsaWVudCBj aG9vc2UgdGhlIHJpZ2h0IE9BdXRoMiBmbG93IChlZyByZWZyZXNoIHZzIG5ldyB1c2VyLWRlbGVn YXRpb24pIHNvIGl0IG1pZ2h0IGhhdmUgYSBwbGFjZSBpbiAjMiwgYSDigJxXV1ctQXV0aGVudGlj YXRlOiBPQXV0aDIg4oCm4oCdIHJlc3BvbnNlIGhlYWRlci4NCg0KDQoNCkVyYW4gc2FpZCB0byBN aWtlOg0KDQo+IEFsdGVybmF0aXZlbHksIGlmIHlvdSBoYXZlIHVzZSBjYXNlcyBvciByZXF1aXJl bWVudHMgZm9yIGludHJvZHVjaW5nIGp1c3QgdGhlIFdXVy1BdXRoZW50aWNhdGUgc2lkZSBvZiBh biBPQXV0aDIgYXV0aG9yaXphdGlvbiBzY2hlbWUgKHlvdXIgb3BlbiBpc3N1ZSksIHdoaWNoIGlu Y2x1ZGVzIGFuIOKAmGVycm9y4oCZIGF0dHJpYnV0ZSBmb3IgdXNlIHdpdGggdGhlIHByb3Bvc2Vk IHJlZ2lzdHJ5LCBwbGVhc2UgcHJlc2VudCB0aG9zZSBhbmQgZXhwbGFpbiBob3cgaXQgd2lsbCB3 b3JrIGFsb25nc2lkZSB0aGUgQmVhcmVyIGFuZCBNQUMgc2NoZW1lcyAoYXMgY3VycmVudGx5IGRy YWZ0ZWQpLg0KDQoNCg0KVGhlIOKAnGRpc2NvdmVyeeKAnSB1c2UtY2FzZSBpbiB0aGlzIGVtYWls IHdhcnJhbnRzIHRoZSBXV1ctQXV0aGVudGljYXRlIHNpZGUgb2YgYW4gT0F1dGgyIHNjaGVtZS4N Cg0KQW4gZXJyb3IgYXR0cmlidXRlIChwbHVzIGEgcmVnaXN0cnkpIG1pZ2h0IGhlbHAsIGJ1dCB3 ZSBuZWVkIHRoZSByZXN0IG9mIHRoZSBkZXRhaWxzIG9mIHRoZSByZXNwb25zZSBoZWFkZXIgZmly c3QuDQoNCkl0IHdvcmtzIHdlbGwgYWxvbmdzaWRlIEJlYXJlciBhbmQgTUFDIHNjaGVtZXM6IGEg 4oCcV1dXLUF1dGguOiBPQXV0aDLigJ0gcmVzcG9uc2UgcG9pbnRzIHRvIE9BdXRoMiBmbG93cyB0 aGUgY2xpZW50IGNhbiB0cnk7IGEg4oCcV1dXLUF1dGguOiBNQUMvQmVhcmVy4oCdIHJlc3BvbnNl IHBvaW50cyB0byByZXRyeWluZyBhIHJlcXVlc3Qgd2l0aCDigJxBdXRoejogTUFDL0JlYXJlcuKA nS4gRXZlbiB3aGVuIGEgY2xpZW50IGlzIGdpdmVuIG11bHRpcGxlIG9wdGlvbnMgaXQgd2lsbCBr bm93IHdoaWNoIHRvIGNob29zZSBiYXNlZCBvbiBpdHMgY29udGV4dCAoZWcgaWYgaXQgZG9lc27i gJl0IGhhdmUgYW5vdGhlciBCZWFyZXIgdG9rZW4gaXQgd2lsbCBpZ25vcmUgdGhlIOKAnFdXVy1B dXRoOiBCZWFyZXLigJ0gcmVzcG9uc2UgYW5kIGZvbGxvdyB0aGUg4oCcV1dXLUF1dGg6IE9BdXRo MuKAnSByZXNwb25zZSkuDQoNCg0KDQoNCg0KLS0NCg0KSmFtZXMgTWFuZ2VyDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E11281D30832WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9c Oioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHls ZT4NCjwhW2VuZGlmXS0tPjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQog QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29s YXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRp b25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0KcC55aXYyNjU5OTMwMDhtc29wbGFpbnRleHQsIGxpLnlpdjI2NTk5 MzAwOG1zb3BsYWludGV4dCwgZGl2LnlpdjI2NTk5MzAwOG1zb3BsYWludGV4dA0KCXttc28tc3R5 bGUtbmFtZTp5aXYyNjU5OTMwMDhtc29wbGFpbnRleHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2MjY1OTkzMDA4bXNvYWNldGF0ZSwgbGkueWl2MjY1 OTkzMDA4bXNvYWNldGF0ZSwgZGl2LnlpdjI2NTk5MzAwOG1zb2FjZXRhdGUNCgl7bXNvLXN0eWxl LW5hbWU6eWl2MjY1OTkzMDA4bXNvYWNldGF0ZTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KcC55aXYyNjU5OTMwMDhtc29ub3JtYWwsIGxpLnlpdjI2NTk5MzAw OG1zb25vcm1hbCwgZGl2LnlpdjI2NTk5MzAwOG1zb25vcm1hbA0KCXttc28tc3R5bGUtbmFtZTp5 aXYyNjU5OTMwMDhtc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnAueWl2MjY1OTkzMDA4bXNvY2hwZGVmYXVsdCwgbGkueWl2MjY1OTkzMDA4bXNv Y2hwZGVmYXVsdCwgZGl2LnlpdjI2NTk5MzAwOG1zb2NocGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5h bWU6eWl2MjY1OTkzMDA4bXNvY2hwZGVmYXVsdDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KcC55aXYyNjU5OTMwMDhtc29ub3JtYWwxLCBsaS55aXYyNjU5OTMw MDhtc29ub3JtYWwxLCBkaXYueWl2MjY1OTkzMDA4bXNvbm9ybWFsMQ0KCXttc28tc3R5bGUtbmFt ZTp5aXYyNjU5OTMwMDhtc29ub3JtYWwxOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7fQ0KcC55aXYyNjU5OTMwMDhtc29wbGFpbnRleHQxLCBsaS55aXYyNjU5OTMwMDhtc29w bGFpbnRleHQxLCBkaXYueWl2MjY1OTkzMDA4bXNvcGxhaW50ZXh0MQ0KCXttc28tc3R5bGUtbmFt ZTp5aXYyNjU5OTMwMDhtc29wbGFpbnRleHQxOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7fQ0KcC55aXYyNjU5OTMwMDhtc29hY2V0YXRlMSwgbGkueWl2MjY1OTkzMDA4bXNv YWNldGF0ZTEsIGRpdi55aXYyNjU5OTMwMDhtc29hY2V0YXRlMQ0KCXttc28tc3R5bGUtbmFtZTp5 aXYyNjU5OTMwMDhtc29hY2V0YXRlMTsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7fQ0KcC55aXYyNjU5OTMwMDhtc29jaHBkZWZhdWx0MSwgbGkueWl2MjY1OTkzMDA4bXNvY2hw ZGVmYXVsdDEsIGRpdi55aXYyNjU5OTMwMDhtc29jaHBkZWZhdWx0MQ0KCXttc28tc3R5bGUtbmFt ZTp5aXYyNjU5OTMwMDhtc29jaHBkZWZhdWx0MTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhtc29oeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLW5hbWU6eWl2MjY1OTkzMDA4bXNvaHlwZXJsaW5rO30NCnNwYW4ueWl2MjY1OTkzMDA4bXNv aHlwZXJsaW5rZm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4bXNvaHlwZXJs aW5rZm9sbG93ZWQ7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhodG1scHJlZm9ybWF0dGVkY2hhcg0KCXtt c28tc3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhodG1scHJlZm9ybWF0dGVkY2hhcjt9DQpzcGFuLnlp djI2NTk5MzAwOHBsYWludGV4dGNoYXINCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4cGxh aW50ZXh0Y2hhcjt9DQpzcGFuLnlpdjI2NTk5MzAwOGJhbGxvb250ZXh0Y2hhcg0KCXttc28tc3R5 bGUtbmFtZTp5aXYyNjU5OTMwMDhiYWxsb29udGV4dGNoYXI7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhl bWFpbHN0eWxlMjMNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4ZW1haWxzdHlsZTIzO30N CnNwYW4ueWl2MjY1OTkzMDA4ZW1haWxzdHlsZTI0DQoJe21zby1zdHlsZS1uYW1lOnlpdjI2NTk5 MzAwOGVtYWlsc3R5bGUyNDt9DQpzcGFuLnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUyNQ0KCXttc28t c3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhlbWFpbHN0eWxlMjU7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhl bWFpbHN0eWxlMjYNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4ZW1haWxzdHlsZTI2O30N CnNwYW4ueWl2MjY1OTkzMDA4ZW1haWxzdHlsZTI3DQoJe21zby1zdHlsZS1uYW1lOnlpdjI2NTk5 MzAwOGVtYWlsc3R5bGUyNzt9DQpzcGFuLnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUyOA0KCXttc28t c3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhlbWFpbHN0eWxlMjg7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhl bWFpbHN0eWxlMjkNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4ZW1haWxzdHlsZTI5O30N CnNwYW4ueWl2MjY1OTkzMDA4ZW1haWxzdHlsZTMwDQoJe21zby1zdHlsZS1uYW1lOnlpdjI2NTk5 MzAwOGVtYWlsc3R5bGUzMDt9DQpzcGFuLnlpdjI2NTk5MzAwOG1zb2h5cGVybGluazENCgl7bXNv LXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4bXNvaHlwZXJsaW5rMTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhtc29oeXBlcmxpbmtm b2xsb3dlZDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4bXNvaHlwZXJsaW5rZm9sbG93 ZWQxOw0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u eWl2MjY1OTkzMDA4aHRtbHByZWZvcm1hdHRlZGNoYXIxDQoJe21zby1zdHlsZS1uYW1lOnlpdjI2 NTk5MzAwOGh0bWxwcmVmb3JtYXR0ZWRjaGFyMTsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnNwYW4ueWl2MjY1OTkzMDA4cGxhaW50ZXh0Y2hhcjENCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MjY1OTkzMDA4cGxhaW50ZXh0Y2hhcjE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhiYWxsb29udGV4dGNoYXIxDQoJe21zby1zdHlsZS1uYW1l OnlpdjI2NTk5MzAwOGJhbGxvb250ZXh0Y2hhcjE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhlbWFpbHN0eWxlMjMxDQoJe21zby1zdHlsZS1u YW1lOnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUyMzE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLnlpdjI2NTk5MzAwOGVtYWlsc3R5 bGUyNDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4ZW1haWxzdHlsZTI0MTsNCglmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4ueWl2 MjY1OTkzMDA4ZW1haWxzdHlsZTI1MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhlbWFp bHN0eWxlMjUxOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi55aXYyNjU5OTMwMDhlbWFpbHN0eWxlMjYxDQoJe21zby1zdHlsZS1uYW1l OnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUyNjE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUyNzEN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4ZW1haWxzdHlsZTI3MTsNCglmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4ueWl2MjY1OTkz MDA4ZW1haWxzdHlsZTI4MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjU5OTMwMDhlbWFpbHN0eWxl MjgxOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMwMDIwNjA7 fQ0Kc3Bhbi55aXYyNjU5OTMwMDhlbWFpbHN0eWxlMjkxDQoJe21zby1zdHlsZS1uYW1lOnlpdjI2 NTk5MzAwOGVtYWlsc3R5bGUyOTE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLnlpdjI2NTk5MzAwOGVtYWlsc3R5bGUzMDENCgl7bXNv LXN0eWxlLW5hbWU6eWl2MjY1OTkzMDA4ZW1haWxzdHlsZTMwMTsNCglmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTU1DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGU1Ng0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1BVSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+QSBXV1ctQXV0aCBoZWFkZXIgaXMgYSBz ZXJ2ZXLigJlzIHNlY3VyaXR5IHN0YXRlbWVudCBhYm91dCBob3cgdG8gZ2FpbiBhY2Nlc3MuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+QSBMaW5rIGhlYWRlciBpcyBhIHNlcnZlcuKA mXMgc3RhdGVtZW50IG9mIGEgcmVsYXRpb25zaGlwIHRvIGFub3RoZXIgVVJJLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5 N0QiPkkgZmluZCB0aGUgTGlua3MmIzQzO1dXVy1BdXRoIGFwcHJvYWNoIG1vcmUgY29tcGxleCwg bGVzcyBpbnR1aXRpdmUsIGFuZCBub3QgYXMgZ29vZCBhIG1hdGNoIGZvciBIVFRQIHNlbWFudGlj cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5FYWNoIFdXVy1BdXRoIGhlYWRlciBp biBteSBhcHByb2FjaCBpcyBhIHN0YW5kYWxvbmUgc3RhdGVtZW50IG9mIGEgcGF0aCB0aGUgY2xp ZW50IGNhbiB0YWtlIHRvIGdhaW4gYWNjZXNzLiBXaGVuIGFuIE9BdXRoMiBmbG93IGlzIGEgcG9z c2libGUgcGF0aCwgaW5jbHVkZQ0KIGEg4oCcV1dXLUF1dGg6IE9BdXRoMiDigKbigJ0gcmVzcG9u c2UgaGVhZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlVzaW5nIExpbmtzJiM0 MztXV1ctQXV0aCByZXF1aXJlcyBpbnRlcnByZXRpbmcgYSBjb21iaW5hdGlvbiBvZiBoZWFkZXJz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPmRyYWZ0LW1pbGxzLWtpdHRlbi1zYXNsLW9hdXRoLTAxI3NlY3Rpb24t Ny4yIGhhcyBhbiBleGFtcGxlIG9mIGEgZXJyb3IgcmVzcG9uc2U6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBIVFRQLzEu MSA0MDEgVW5hdXRob3JpemVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBXV1ctQXV0aGVudGljYXRlOiBCRUFSRVIgcmVh bG09JnF1b3Q7ZXhhbXBsZS5jb20mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IExpbms6ICZsdDs8YSBocmVmPSJo dHRwczovL2xvZ2luLnlhaG9vLmNvbS9vYXV0aCI+aHR0cHM6Ly9sb2dpbi55YWhvby5jb20vb2F1 dGg8L2E+Jmd0OyByZWw9JnF1b3Q7b2F1dGgyLWF1dGhlbnRpY2F0b3ImcXVvdDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 IExpbms6ICZsdDs8YSBocmVmPSJodHRwczovL2xvZ2luLnlhaG9vLmNvbS9vYXV0aCI+aHR0cHM6 Ly9sb2dpbi55YWhvby5jb20vb2F1dGg8L2E+Jmd0OyByZWw9JnF1b3Q7b3VhdGgyLXRva2VuJnF1 b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+QSBMaW5rIGhlYWRlciBpcyBhIG5pY2UsIGNsZWFuLCBpbnR1aXRp dmUgYXBwcm9hY2ggZm9yIGRlbGl2ZXJpbmcgYSBzdGF0aWMgdG9rZW4gZW5kcG9pbnQgVVJJLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIHRoYXQgaXMgbm90IGFjdHVh bGx5IHdoYXQgYSBjbGllbnQgbmVlZHMgaW4gYW4gSFRUUCBlcnJvciByZXNwb25zZS4gVGhlIGNs aWVudCBuZWVkcyB0byBrbm93IHdoYXQgdG8gZG8gbmV4dCwgaW4gdGhlIGNvbnRleHQgb2YgdGhp cyByZXF1ZXN0IGFuZA0KIHRoZSBjcmVkZW50aWFscyBpdCBpbmNsdWRlZC4gVGhhdCBpcyBtb3Jl IGR5bmFtaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Q29uc2lkZXIgdGhlIGVycm9yIGNvZGVzIHRoYXQgTWlr ZSBKb25lcyAmYW1wOyBvdGhlcnMgd2FudCB0byBzdGFuZGFyZGlzZS9yZWdpc3RlciBhY3Jvc3Mg YXV0aGVudGljYXRpb24gc2NoZW1lcy4gVGhleSBhcmUgbmVlZGVkIHRvIGtub3cgd2hpY2ggT0F1 dGgyIGZsb3cgdG8NCiBwZXJmb3JtIChlZyB0cnkgYSByZWZyZXNoIGlmIHRoZSB0b2tlbiBoYXMg ZXhwaXJlZDsgcmVkbyB1c2VyIGRlbGVnYXRpb24gaWYgbW9yZSBzY29wZSBpcyBuZWVkZWQpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPlNob3VsZCB0aGUgZXJyb3IgY29kZSBnbyBpbiBhbiBPQXV0aDIgTGluayBo ZWFkZXI/IFRoYXQgZmVlbHMgYSBiaXQgc3RyYW5nZS4gSXQgcmVxdWlyZXMgZXh0cmEgcGFyYW1l dGVycyB0byBiZSBkZWZpbmVkIGZvciBzcGVjaWZpYyBMaW5rIHJlbGF0aW9ucyAocG9zc2libGUs DQogYnV0IG5vdCBhcyBpbnR1aXRpdmUpLiBObyBvbmUgaGFzIHN1Z2dlc3RlZCB0aGlzLCB0aG91 Z2ggSSB0aGluayBpdCBpcyB0aGUgY29ycmVjdCBkZXNpZ24gaWYgTGlua3MmIzQzO1dXVy1BdXRo IGlzIHVzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+VGhlIG90aGVyIG9wdGlv biBpcyB0byBwdXQgdGhlIGVycm9yIGNvZGUgaW4gdGhlIFdXVy1BdXRoIGhlYWRlciBmb3IgYSBz cGVjaWZpYyBzY2hlbWUuIFdoaWNoIHNjaGVtZT8gRXZlcnkgc2NoZW1lIGZvciB3aGljaCBPQXV0 aDIgY291bGQgZGVsaXZlciBhIHRva2VuDQogbm93IG5lZWRzIHRvIGJlIG1vZGlmaWVkIHNvIGl0 cyBlcnJvciByZXNwb25zZSBjYW4gaW5jbHVkZSBPQXV0aDItc3BlY2lmaWMgZGV0YWlscy4gVGhh dCBpcyBmZWFzaWJsZSBmb3IgdGhlIEJlYXJlciBzY2hlbWUsIGJ1dCBub3QgZ2VuZXJhbGx5LiBU aGVyZSBpcyBubyBXV1ctQXV0aCBoZWFkZXIgdG8gcHV0IHRoZSBlcnJvciBjb2RlIGluIGlmLCBz YXksIHRoZSBUTFMgbGF5ZXIgaXMgdXNlZCBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIChlZw0K IFRMUy1QU0sgb3IgVExTLVNSUCBvciDigKYpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5 N0QiPlRoaXMgbWlnaHQgYmUgYSB0cml2aWFsIGlzc3VlIGlmIE9BdXRoMiBpcyBvbmx5IGV2ZXIg dXNlZCB3aXRoIHRoZSBCZWFyZXIgSFRUUCBzY2hlbWVzIOKAkyBidXQgaXQgZG9lcyBpbGx1c3Ry YXRlIGEgZGVzaWduIGZsYXc6IG9uZSBtb3JlIHVubmVjZXNzYXJ5IHN0cm9uZw0KIGNvdXBsaW5n IGJldHdlZW4gdGhlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBhbmQgdGhlIE9BdXRoMiBkZWxl Z2F0aW9uL2F1dGhvcml6YXRpb24gZmxvd3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5Og0KJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IEVyYW4gSGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIDggQXByaWwgMjAxMSAxMjowNCBQTTxicj4NCjxiPlRv OjwvYj4gV2lsbGlhbSBKLiBNaWxsczsgTWFuZ2VyLCBKYW1lcyBIOyBPQXV0aCBXRzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdHXSBPQXV0aDIgc2NoZW1lPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCBMaW5rIGhlYWRl cnMgYXJlIG11Y2ggYmV0dGVyIGZpdCBmb3IgcmVsYXlpbmcgZGlzY292ZXJ5IGluZm9ybWF0aW9u IHRoYW4gYSBoYWxmIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lLiBPdmVyYWxsLCBJIGZpbmQg SmFtZXPigJkNCiBwcm9wb3NhbCB0byBiZSB0b28gY29tcGxleCBhbmQgbm90IGludHVpdGl2ZSB0 byBwZW9wbGUgZmFtaWxpYXIgd2l0aCBleGlzdGluZyBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVt ZXMgKGl0IGlzIG5vdmVsIGFuZCB3ZWxsIHRob3VnaHQsIGFuZCBpdCBkb2VzIHdvcmssIGp1c3Qg bm90IGFzIG1vc3QgcGVvcGxlIGV4cGVjdCBkaXNjb3ZlcnkgdG8pLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+RUhMPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5Og0KJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7DQpmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5XaWxsaWFtIEouIE1pbGxzPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxMSA3OjAxIFBNPGJyPg0KPGI+VG86PC9iPiBNYW5nZXIs IEphbWVzIEg7IE9BdXRoIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9B dXRoMiBzY2hlbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6DQomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SW4gdGhlIFNBU0wgbWVjaGFuaXNtIGRyYWZ0 IHNwZWMgd2hlcmUgd2Ugd2VudCB3aXRoIHRoYXQgaXMgdG8gdXNlIExJTksgaGVhZGVycy4mbmJz cDsgU2VlDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taWxscy1r aXR0ZW4tc2FzbC1vYXV0aC0wMSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWls bHMta2l0dGVuLXNhc2wtb2F1dGgtMDE8L2E+IGlmIHlvdSB3YW50IHRvIHRha2UgYSBsb29rLiZu YnNwOyBXV1ctQXV0aGVudGljYXRlIGhlYWRlcnMgcmV0dXJuIHRoZSBzdXBwb3J0ZWQgYXV0aGVu dGljYXRpb24gc2NoZW1lcyBhbmQgTElOSyBoZWFkZXJzIHRlbGwgeW91DQogdGhlcmUgYXJlIE9B dXRoIGVuZHBvaW50cyB5b3UgY2FuIGludGVyYWN0IHdpdGguPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6DQomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6DQomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+SXQncyBhIHN3YWcgYXQgZGlzY292ZXJ5IGluIGJhbmQs IG1pZ2h0IHdvcmsgaGVyZSB0b28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6DQomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBh bGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiAmcXVv dDtNYW5nZXIsIEphbWVzIEgmcXVvdDsgJmx0O0phbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5j b20mZ3Q7PGJyPg0KPGI+VG86PC9iPiBPQXV0aCBXRyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCA3LCAyMDExIDY6NDggUE08YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGgyIHNjaGVtZTxicj4NCjxicj4NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IGlkPSJ5aXYyNjU5OTMwMDgiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5XZSBzaG91bGQgZGVmaW5lIGEg4oCcV1dXLUF1dGhlbnRpY2F0 ZTogT0F1dGgyIOKApuKAnSByZXNwb25zZSBoZWFkZXIg4oCTIG5vdCB0byBlbmNvbXBhc3MgdGhl IE1BQywgQmVhcmVyLCBhbmQgYW55IG90aGVyIGdlbmVyaWMgSFRUUCBhdXRoZW50aWNhdGlvbiBz Y2hlbWUsIGJ1dCBhcyBhIHdheSBmb3IgYSBzZXJ2ZXINCiB0byB0ZWxsIHRoZSBjbGllbnQgdGhh dCBpdCBjYW4gcGVyZm9ybSBhbiBPQXV0aDIgZ2V0LWEtdG9rZW4gZmxvdyB0byBnYWluIGFjY2Vz cy4gV2hlbiB0aGUgc29ydCBvZiBPQXV0aDIgZmxvdyBkZXBlbmRzIG9uIHRoZSBlcnJvciB3aXRo IGEgY3VycmVudCB0b2tlbiAoZWcgZXhwaXJlZCB2cyBpbnZhbGlkKSB0aGVuIHRoZSDigJxXV1ct QXV0aGVudGljYXRlOiBPQXV0aDIg4oCm4oCdIHJlc3BvbnNlIGhlYWRlciBuZWVkcyB0byByZWZs ZWN0IHRoaXMuIEl0DQogY291bGQgZG8gc28gYmUgaW5jbHVkaW5nIGFuIGVycm9yIGNvZGUuIEEg YmV0dGVyLCBtb3JlIGRpcmVjdCwgYXBwcm9hY2ggaXMgdG8gZXhwbGljaXRseSBpZGVudGlmeSDi gJxyZWZyZXNoIGZsb3figJ0gYW5kL29yIOKAnHVzZXItZGVsZWdhdGlvbiBmbG934oCdIGFuZC9v ciDigJxhc3NlcnRpb24gZmxvd+KAnSBldGMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CZWFyZXIgb3IgT0F1dGgyIFdX Vy1BdXRoZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyPzwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIHJ1bGUgc2hvdWxkIGJlOjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4j MS4gSWYgdGhlIGNsaWVudCBjYW4gZml4IGFuIGVycm9yIGJ5IHNlbmRpbmcgYW4g4oCcQXV0aG9y aXphdGlvbjogQmVhcmVyIOKApuKAnSByZXF1ZXN0IGhlYWRlciAob3IgdGhlIHF1ZXJ5IG9yIFBP U1QgYWx0ZXJuYXRpdmUpIHRoZW4gdGhlIHNlcnZlciBzaG91bGQgcmV0dXJuIOKAnFdXVy1BdXRo ZW50aWNhdGU6DQogQmVhcmVyIOKApuKAnS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiMyLiBJZiB0aGUgY2xpZW50IGNhbiBm aXggYW4gZXJyb3IgYnkgcGVyZm9ybWluZyBhbiBPQXV0aDIgZmxvdyBhdCBhbiBhdXRob3JpemF0 aW9uIHNlcnZlciB0aGVuIHRoZSByZXNvdXJjZSBzZXJ2ZXIgc2hvdWxkIHJldHVybiDigJxXV1ct QXV0aGVudGljYXRlOiBPQXV0aDIg4oCm4oCdLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIHNlcnZlciBjYW4gcmV0dXJu IGJvdGggcmVzcG9uc2UgaGVhZGVycyBpZiBib3RoIG9wdGlvbnMgYXJlIHBvc3NpYmxlLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+VGhlcmUgaXMgbm8gcG9pbnQgaW4gcmUtcHJlc2VudGluZyBhIHJlamVjdGVkIEJlYXJlciB0 b2tlbiBzbyAjMSBpc27igJl0IHRoYXQgdXNlZnVsLiBJdCBjb3VsZCBiZSBhcHByb3ByaWF0ZSBp ZiBubyB0b2tlbiB3YXMgcHJlc2VudGVkIGFzIHRoZSBjbGllbnQgbWlnaHQgaGF2ZSBhIHRva2Vu LCBidXQNCiBkaWRu4oCZdCBrbm93IHRoaXMgcmVzb3VyY2UgbmVlZGVkIGl0LiBJdCBtaWdodCBi ZSBhcHByb3ByaWF0ZSBpZiBhIGNsaWVudCBwcmVzZW50ZWQgYSB0b2tlbiB3aXRoIGluc3VmZmlj aWVudCBzY29wZSBhcyB0aGUgY2xpZW50IG1pZ2h0IGhhdmUgYW5vdGhlciB0b2tlbiB3aXRoIHRo ZSByaWdodCBzY29wZSBzbyDigJxXV1ctQXV0aGVudGljYXRlOiBCZWFyZXIgc2NvcGU94oCm4oCd IGNvdWxkIGhlbHAuICMxIGlzIG5vdCByZWFsbHkgbmVjZXNzYXJ5IHdoZW4NCiBhIHByZXNlbnRl ZCB0b2tlbiBpcyBpbnZhbGlkIG9yIGV4cGlyZWQgYXMgdGhlIGNsaWVudCBuZWVkcyB0byBnZXQg YSBuZXcgb25lIChlZyB1c2luZyBhbiBPQXV0aDIgZmxvdyB0aGF0IGlzIG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoZSBCZWFyZXIgc2NoZW1lKS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayBhbiBlcnJv ciBjb2RlIGluIGEg4oCcV1dXLUF1dGhlbnRpY2F0ZTogQmVhcmVyIOKApuKAnSByZXNwb25zZSBo ZWxwcyBhIGNsaWVudCByZXRyeSB0aGUgcmVxdWVzdCB3aXRoIGEg4oCcQXV0aG9yaXphdGlvbjog QmVhcmVyIOKApuKAnSBoZWFkZXIgdGhhdCB3aWxsIHdvcmsuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFuIGVycm9yIGNvZGUgbWlnaHQg aGVscCBhIGNsaWVudCBjaG9vc2UgdGhlIHJpZ2h0IE9BdXRoMiBmbG93IChlZyByZWZyZXNoIHZz IG5ldyB1c2VyLWRlbGVnYXRpb24pIHNvIGl0IG1pZ2h0IGhhdmUgYSBwbGFjZSBpbiAjMiwgYSDi gJxXV1ctQXV0aGVudGljYXRlOiBPQXV0aDIg4oCm4oCdIHJlc3BvbnNlDQogaGVhZGVyLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+RXJhbiBzYWlkIHRvIE1pa2U6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDsgQWx0ZXJuYXRpdmVseSwgaWYgeW91IGhhdmUgdXNl IGNhc2VzIG9yIHJlcXVpcmVtZW50cyBmb3IgaW50cm9kdWNpbmcganVzdCB0aGUgV1dXLUF1dGhl bnRpY2F0ZSBzaWRlIG9mIGFuIE9BdXRoMiBhdXRob3JpemF0aW9uIHNjaGVtZSAoeW91ciBvcGVu IGlzc3VlKSwgd2hpY2ggaW5jbHVkZXMNCiBhbiDigJhlcnJvcuKAmSBhdHRyaWJ1dGUgZm9yIHVz ZSB3aXRoIHRoZSBwcm9wb3NlZCByZWdpc3RyeSwgcGxlYXNlIHByZXNlbnQgdGhvc2UgYW5kIGV4 cGxhaW4gaG93IGl0IHdpbGwgd29yayBhbG9uZ3NpZGUgdGhlIEJlYXJlciBhbmQgTUFDIHNjaGVt ZXMgKGFzIGN1cnJlbnRseSBkcmFmdGVkKS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSDigJxkaXNjb3ZlcnnigJ0gdXNl LWNhc2UgaW4gdGhpcyBlbWFpbCB3YXJyYW50cyB0aGUgV1dXLUF1dGhlbnRpY2F0ZSBzaWRlIG9m IGFuIE9BdXRoMiBzY2hlbWUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkFuIGVycm9yIGF0dHJpYnV0ZSAocGx1cyBhIHJlZ2lzdHJ5KSBt aWdodCBoZWxwLCBidXQgd2UgbmVlZCB0aGUgcmVzdCBvZiB0aGUgZGV0YWlscyBvZiB0aGUgcmVz cG9uc2UgaGVhZGVyIGZpcnN0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5JdCB3b3JrcyB3ZWxsIGFsb25nc2lkZSBCZWFyZXIgYW5kIE1B QyBzY2hlbWVzOiBhIOKAnFdXVy1BdXRoLjogT0F1dGgy4oCdIHJlc3BvbnNlIHBvaW50cyB0byBP QXV0aDIgZmxvd3MgdGhlIGNsaWVudCBjYW4gdHJ5OyBhIOKAnFdXVy1BdXRoLjogTUFDL0JlYXJl cuKAnSByZXNwb25zZSBwb2ludHMgdG8gcmV0cnlpbmcNCiBhIHJlcXVlc3Qgd2l0aCDigJxBdXRo ejogTUFDL0JlYXJlcuKAnS4gRXZlbiB3aGVuIGEgY2xpZW50IGlzIGdpdmVuIG11bHRpcGxlIG9w dGlvbnMgaXQgd2lsbCBrbm93IHdoaWNoIHRvIGNob29zZSBiYXNlZCBvbiBpdHMgY29udGV4dCAo ZWcgaWYgaXQgZG9lc27igJl0IGhhdmUgYW5vdGhlciBCZWFyZXIgdG9rZW4gaXQgd2lsbCBpZ25v cmUgdGhlIOKAnFdXVy1BdXRoOiBCZWFyZXLigJ0gcmVzcG9uc2UgYW5kIGZvbGxvdyB0aGUg4oCc V1dXLUF1dGg6IE9BdXRoMuKAnQ0KIHJlc3BvbnNlKS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LS08 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ SmFtZXMgTWFuZ2VyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_255B9BB34FB7D647A506DC292726F6E11281D30832WSMSG3153Vsrv_-- From wmills@yahoo-inc.com Thu Apr 7 23:56:03 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8156A3A6989 for ; Thu, 7 Apr 2011 23:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEioof-o7dMm for ; Thu, 7 Apr 2011 23:56:01 -0700 (PDT) Received: from web32303.mail.mud.yahoo.com (web32303.mail.mud.yahoo.com [68.142.207.151]) by core3.amsl.com (Postfix) with SMTP id C15233A6889 for ; Thu, 7 Apr 2011 23:56:00 -0700 (PDT) Received: (qmail 47231 invoked by uid 60001); 8 Apr 2011 06:57:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302245859; bh=FvsAo0RNbVQlPcQAJGSLrwG29hENCBQW7DHAqOY0r94=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=I88pLLXUHIrwopK9y4T8Ykmvok0N75eAon4j+VVwoerfAbShJEXmaIJWHpnJ9IwhVyAYDoAosw9msYovc+RiVNLnlnR6mMWYIlZK55bBI5uh6+mZEEd71y8xS+j2IlRRS1x677TB7PTxIcc5R0m19yxsby+gRQ/gR/L6UoV0zzU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=EzpnbDpLFXt5XIr3sSNzeeYZhdCRvkcNBbu9uWXefx8qZcainELOMmNfmuE9rWMBWue+aeCfpADk6gG+c8zZK8qMAQBNNy94gcn8OS8efc5ZhgQsV4RQ12oH1sakZmQK2yOjnHRW/C4itdeuUOsUXXpZuZt9+n9aeOiJwrIAIuw=; Message-ID: <864433.29776.qm@web32303.mail.mud.yahoo.com> X-YMail-OSG: kKVG2isVM1meKuiJlFmxKPFYm3Ckz.t9TbdnfGPQr4qn74T CCFZo94UBA4WeXPv3vPNpjKPvjuNYceSlFZ1nexFQzovUGkrvRInfsfzCHpE TQaKHPqtwv6kQjkgES5bPq3JlBTcx1AR9ln6whrnnQLnHX._sHpOjx_GR0tk cueusNnuQQ7uM0NHC5xqLzh3LPf.zF.fJIYpjfmJooIQQshJDazaRRMEEL4h UYZabuRYzn6q1Y_UlD_7s7OPkoGUJHz.R2bj53T4kKAGfiMSU_Y2bguopYj8 dGNyyTgWeIuYmRizATTP5hRW2tN0FLCs5YuxPm1SycETpOAHNDROLlYZozR2 0baWW_84BEHiz5cfbumOq.GiusJe1QOKn8dgnBJcffumHur1fXLA3kQ-- Received: from [209.131.62.115] by web32303.mail.mud.yahoo.com via HTTP; Thu, 07 Apr 2011 23:57:39 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <90C41DD21FB7C64BB94121FBBC2E7234465664E11D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281CAB8DB@WSMSG3153V.srv.dir.telstra.com> <249220.24403.qm@web32303.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E3B2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281D30832@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 7 Apr 2011 23:57:39 -0700 (PDT) From: "William J. Mills" To: "Manger, James H" , Eran Hammer-Lahav , OAuth WG In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11281D30832@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1871004363-1302245859=:29776" Subject: Re: [OAUTH-WG] OAuth2 scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 06:56:03 -0000 --0-1871004363-1302245859=:29776 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I found when I started trying to put this into WWW-Authenticate header it e= nded up with a lot of extensions and parsing.=C2=A0 Link headers make sense= to me in that the client that needs to know where the authenticator for a = site is can look at the linking relationships, and a registry already exist= s for defining them because we're extending the current model that pretty m= uch fits.=0A=0AWe need to convey the same information no matter what we do.= =0A=0AAs for error codes, I think that's orthogonal to the discovery inform= ation.=C2=A0=C2=A0=0A=0A-bill=0A=0A=0A=0A________________________________= =0AFrom: "Manger, James H" =0ATo: Eran Ham= mer-Lahav ; William J. Mills ; O= Auth WG =0ASent: Thursday, April 7, 2011 11:47 PM=0ASubject= : RE: [OAUTH-WG] OAuth2 scheme=0A=0A=0A =0AA WWW-Auth header is a server=E2= =80=99s security statement about how to gain access.=0AA Link header is a s= erver=E2=80=99s statement of a relationship to another URI.=0A=C2=A0=0AI fi= nd the Links+WWW-Auth approach more complex, less intuitive, and not as goo= d a match for HTTP semantics.=0AEach WWW-Auth header in my approach is a st= andalone statement of a path the client can take to gain access. When an OA= uth2 flow is a possible path, include a =E2=80=9CWWW-Auth: OAuth2 =E2=80=A6= =E2=80=9D response header.=0AUsing Links+WWW-Auth requires interpreting a c= ombination of headers.=0A=C2=A0=0Adraft-mills-kitten-sasl-oauth-01#section-= 7.2 has an example of a error response:=0A=C2=A0=C2=A0 HTTP/1.1 401 Unautho= rized=0A=C2=A0=C2=A0 WWW-Authenticate: BEARER realm=3D"example.com"=0A=C2= =A0=C2=A0 Link: rel=3D"oauth2-authenticator= "=0A=C2=A0=C2=A0 Link: rel=3D"ouath2-token"= =0A=C2=A0=0AA Link header is a nice, clean, intuitive approach for deliveri= ng a static token endpoint URI.=0AHowever, that is not actually what a clie= nt needs in an HTTP error response. The client needs to know what to do nex= t, in the context of this request and the credentials it included. That is = more dynamic.=0A=C2=A0=0AConsider the error codes that Mike Jones & others = want to standardise/register across authentication schemes. They are needed= to know which OAuth2 flow to perform (eg try a refresh if the token has ex= pired; redo user delegation if more scope is needed).=0A=C2=A0=0AShould the= error code go in an OAuth2 Link header? That feels a bit strange. It requi= res extra parameters to be defined for specific Link relations (possible, b= ut not as intuitive). No one has suggested this, though I think it is the c= orrect design if Links+WWW-Auth is used.=0AThe other option is to put the e= rror code in the WWW-Auth header for a specific scheme. Which scheme? Every= scheme for which OAuth2 could deliver a token now needs to be modified so = its error response can include OAuth2-specific details. That is feasible fo= r the Bearer scheme, but not generally. There is no WWW-Auth header to put = the error code in if, say, the TLS layer is used for client authentication = (eg TLS-PSK or TLS-SRP or =E2=80=A6).=0AThis might be a trivial issue if OA= uth2 is only ever used with the Bearer HTTP schemes =E2=80=93 but it does i= llustrate a design flaw: one more unnecessary strong coupling between the a= uthentication mechanism and the OAuth2 delegation/authorization flows.=0A= =C2=A0=0A=C2=A0=0A--=0AJames Manger=0A=C2=A0=0A=C2=A0=0AFrom:Eran Hammer-La= hav [mailto:eran@hueniverse.com] =0ASent: Friday, 8 April 2011 12:04 PM=0AT= o: William J. Mills; Manger, James H; OAuth WG=0ASubject: RE: [OAUTH-WG] OA= uth2 scheme=0A=C2=A0=0AI agree that Link headers are much better fit for re= laying discovery information than a half HTTP authentication scheme. Overal= l, I find James=E2=80=99 proposal to be too complex and not intuitive to pe= ople familiar with existing HTTP authentication schemes (it is novel and we= ll thought, and it does work, just not as most people expect discovery to).= =0A=C2=A0=0AEHL=0A=C2=A0=0AFrom:oauth-bounces@ietf.org [mailto:oauth-bounce= s@ietf.org] On Behalf Of William J. Mills=0ASent: Thursday, April 07, 2011 = 7:01 PM=0ATo: Manger, James H; OAuth WG=0ASubject: Re: [OAUTH-WG] OAuth2 sc= heme=0A=C2=A0=0AIn the SASL mechanism draft spec where we went with that is= to use LINK headers.=C2=A0 See=0Ahttp://tools.ietf.org/html/draft-mills-ki= tten-sasl-oauth-01 if you want to take a look.=C2=A0 WWW-Authenticate heade= rs return the supported authentication schemes and LINK headers tell you th= ere are OAuth endpoints you can interact with.=0A=C2=A0=0AIt's a swag at di= scovery in band, might work here too.=0A=C2=A0=0A=0A_______________________= _________=0A =0AFrom:"Manger, James H" =0A= To: OAuth WG =0ASent: Thursday, April 7, 2011 6:48 PM=0ASub= ject: Re: [OAUTH-WG] OAuth2 scheme=0A=0A=0AWe should define a =E2=80=9CWWW-= Authenticate: OAuth2 =E2=80=A6=E2=80=9D response header =E2=80=93 not to en= compass the MAC, Bearer, and any other generic HTTP authentication scheme, = but as a way for a server to tell the client that it can perform an OAuth2 = get-a-token flow to gain access. When the sort of OAuth2 flow depends on th= e error with a current token (eg expired vs invalid) then the =E2=80=9CWWW-= Authenticate: OAuth2 =E2=80=A6=E2=80=9D response header needs to reflect th= is. It could do so be including an error code. A better, more direct, appro= ach is to explicitly identify =E2=80=9Crefresh flow=E2=80=9D and/or =E2=80= =9Cuser-delegation flow=E2=80=9D and/or =E2=80=9Cassertion flow=E2=80=9D et= c.=0A=C2=A0=0ABearer or OAuth2 WWW-Authenticate response header?=0AThe rule= should be:=0A#1. If the client can fix an error by sending an =E2=80=9CAut= horization: Bearer =E2=80=A6=E2=80=9D request header (or the query or POST = alternative) then the server should return =E2=80=9CWWW-Authenticate: Beare= r =E2=80=A6=E2=80=9D.=0A=C2=A0=0A#2. If the client can fix an error by perf= orming an OAuth2 flow at an authorization server then the resource server s= hould return =E2=80=9CWWW-Authenticate: OAuth2 =E2=80=A6=E2=80=9D.=0A=C2=A0= =0AThe server can return both response headers if both options are possible= .=0A=C2=A0=0AThere is no point in re-presenting a rejected Bearer token so = #1 isn=E2=80=99t that useful. It could be appropriate if no token was prese= nted as the client might have a token, but didn=E2=80=99t know this resourc= e needed it. It might be appropriate if a client presented a token with ins= ufficient scope as the client might have another token with the right scope= so =E2=80=9CWWW-Authenticate: Bearer scope=3D=E2=80=A6=E2=80=9D could help= . #1 is not really necessary when a presented token is invalid or expired a= s the client needs to get a new one (eg using an OAuth2 flow that is outsid= e the scope of the Bearer scheme).=0A=C2=A0=0AI don=E2=80=99t think an erro= r code in a =E2=80=9CWWW-Authenticate: Bearer =E2=80=A6=E2=80=9D response h= elps a client retry the request with a =E2=80=9CAuthorization: Bearer =E2= =80=A6=E2=80=9D header that will work.=0AAn error code might help a client = choose the right OAuth2 flow (eg refresh vs new user-delegation) so it migh= t have a place in #2, a =E2=80=9CWWW-Authenticate: OAuth2 =E2=80=A6=E2=80= =9D response header.=0A=C2=A0=0AEran said to Mike:=0A> Alternatively, if yo= u have use cases or requirements for introducing just the WWW-Authenticate = side of an OAuth2 authorization scheme (your open issue), which includes an= =E2=80=98error=E2=80=99 attribute for use with the proposed registry, plea= se present those and explain how it will work alongside the Bearer and MAC = schemes (as currently drafted).=0A=C2=A0=0AThe =E2=80=9Cdiscovery=E2=80=9D = use-case in this email warrants the WWW-Authenticate side of an OAuth2 sche= me.=0AAn error attribute (plus a registry) might help, but we need the rest= of the details of the response header first.=0AIt works well alongside Bea= rer and MAC schemes: a =E2=80=9CWWW-Auth.: OAuth2=E2=80=9D response points = to OAuth2 flows the client can try; a =E2=80=9CWWW-Auth.: MAC/Bearer=E2=80= =9D response points to retrying a request with =E2=80=9CAuthz: MAC/Bearer= =E2=80=9D. Even when a client is given multiple options it will know which = to choose based on its context (eg if it doesn=E2=80=99t have another Beare= r token it will ignore the =E2=80=9CWWW-Auth: Bearer=E2=80=9D response and = follow the =E2=80=9CWWW-Auth: OAuth2=E2=80=9D response).=0A=C2=A0=0A=C2=A0= =0A--=0AJames Manger=0A=0A_______________________________________________= =0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listi= nfo/oauth --0-1871004363-1302245859=:29776 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I found when I started trying to put this into WWW-Authenticate header it= ended up with a lot of extensions and parsing.  Link headers make sen= se to me in that the client that needs to know where the authenticator for = a site is can look at the linking relationships, and a registry already exi= sts for defining them because we're extending the current model that pretty= much fits.

We need to c= onvey the same information no matter what we do.

As for error codes, I think that's orthogonal to t= he discovery information.  

-bill

From: "Manger, James H" <James.H.Ma= nger@team.telstra.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>; William J. Mills <= wmills@yahoo-inc.com>; OAuth WG <oauth@ietf.org>
Sent: Thursday, April 7, 2011 11:47 PMSubject: RE: [OAUTH-WG] = OAuth2 scheme

=0A
=0A=0A =0A =0A=0A=0A=0A=0A
A WWW-Auth hea= der is a server=E2=80=99s security statement about how to gain access.
=0A
A Link header is a server=E2=80=99s statem= ent of a relationship to another URI.
=0A
=  
=0A
I find the Links+WWW-Auth ap= proach more complex, less intuitive, and not as good a match for HTTP seman= tics.
=0A
Each WWW-Auth header in my appro= ach is a standalone statement of a path the client can take to gain access.= When an OAuth2 flow is a possible path, include=0A a =E2=80=9CWWW-Auth: OA= uth2 =E2=80=A6=E2=80=9D response header.
=0A
Using Links+WWW-Auth requires interpreting a combination of headers.
=0A
 
=0A
draft-mills-kitten-sasl-oauth-01#section-7.2 has an example of a error = response:
=0A
   HTTP/1.1 401 Unauthorized
= =0A
&= nbsp;  WWW-Authenticate: BEARER realm=3D"example.com"
=0A
   Link: <h= ttps://login.yahoo.com/oauth> rel=3D"oauth2-authenticator" =0A
   Link: <https://login.yahoo.com/oauth> rel=3D"ou= ath2-token"
=0A
 
=0AA Link header is a nice, clean, intuitive approach for d= elivering a static token endpoint URI.
=0A
However, that is not actually what a client needs in an HTTP error respons= e. The client needs to know what to do next, in the context of this request= and=0A the credentials it included. That is more dynamic.
=0A=
 
=0A
Consider = the error codes that Mike Jones & others want to standardise/register a= cross authentication schemes. They are needed to know which OAuth2 flow to= =0A perform (eg try a refresh if the token has expired; redo user delegatio= n if more scope is needed).
=0A
 
=0A
Should the error code go in an OAuth2 Li= nk header? That feels a bit strange. It requires extra parameters to be def= ined for specific Link relations (possible,=0A but not as intuitive). No on= e has suggested this, though I think it is the correct design if Links+WWW-= Auth is used.
=0A
The other option is to p= ut the error code in the WWW-Auth header for a specific scheme. Which schem= e? Every scheme for which OAuth2 could deliver a token=0A now needs to be m= odified so its error response can include OAuth2-specific details. That is = feasible for the Bearer scheme, but not generally. There is no WWW-Auth hea= der to put the error code in if, say, the TLS layer is used for client auth= entication (eg=0A TLS-PSK or TLS-SRP or =E2=80=A6).
=0A
This might be a trivial issue if OAuth2 is only ever used wit= h the Bearer HTTP schemes =E2=80=93 but it does illustrate a design flaw: o= ne more unnecessary strong=0A coupling between the authentication mechanism= and the OAuth2 delegation/authorization flows.
=0A
 
=0A
  =0A
=0A
--
=0A
J= ames Manger
=0A
 
=0A=0A
 
=0A
=0A
=0A
From: Eran Hammer-Lahav [mailto:eran@= hueniverse.com]=0A
=0ASent: Friday, 8 April 2011 12:04 PM
=0A<= b>To: William J. Mills; Manger, James H; OAuth WG
=0ASubject:= RE: [OAUTH-WG] OAuth2 scheme
=0A
=0A
=0A
 
=0A
I agree that Link headers are much better fit for relaying discovery = information than a half HTTP authentication scheme. Overall, I find James= =E2=80=99=0A proposal to be too complex and not intuitive to people familia= r with existing HTTP authentication schemes (it is novel and well thought, = and it does work, just not as most people expect discovery to). =0A
 
=0A
EHL
=0A
 
=0A
=0A
=0A
=0AFrom:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=0AOn Behalf Of <= /b>William J. Mills
=0ASent: Thursday, April 07, 2011 7:01 PM
= =0ATo: Manger, James H; OAuth WG
=0ASubject: Re: [OAUTH-WG= ] OAuth2 scheme
=0A
=0A
=0A
 
=0A
=0A
=0A<= div class=3D"yiv1680976166MsoNormal" style=3D"background: none repeat scrol= l 0% 0% white;">In the SASL me= chanism draft spec where we went with that is to use LINK headers.  Se= e=0Ahttp://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-01 if you want= to take a look.  WWW-Authenticate headers return the supported authen= tication schemes and LINK headers tell you=0A there are OAuth endpoints you= can interact with.
=0A
=0A
=0A
 
=0A
=0A=0A
It's a = swag at discovery in band, might work here too.
=0A
=0A=0A
 =
=0A
=0A
=0A
=0A
=0A=0A
=0A=0A
From:=0A "Manger, James H" <James.H.Mange= r@team.telstra.com>
=0ATo: OAuth WG <oauth@ietf.org>
= =0ASent: Thursday, April 7, 2011 6:48 PM
=0ASubject: Re: [= OAUTH-WG] OAuth2 scheme
=0A
=0A
=0A
=0A
=0A
= =0A
We should define a =E2=80=9CWWW-Authenticate: OAuth2 =E2=80=A6=E2=80=9D re= sponse header =E2=80=93 not to encompass the MAC, Bearer, and any other gen= eric HTTP authentication scheme, but as a way for a server=0A to tell the c= lient that it can perform an OAuth2 get-a-token flow to gain access. When t= he sort of OAuth2 flow depends on the error with a current token (eg expire= d vs invalid) then the =E2=80=9CWWW-Authenticate: OAuth2 =E2=80=A6=E2=80=9D= response header needs to reflect this. It=0A could do so be including an e= rror code. A better, more direct, approach is to explicitly identify =E2=80= =9Crefresh flow=E2=80=9D and/or =E2=80=9Cuser-delegation flow=E2=80=9D and/= or =E2=80=9Cassertion flow=E2=80=9D etc.
=0A
=0A
=0A
 
=0A
=0A
=0A
Bearer= or OAuth2 WWW-Authenticate response header?
=0A
=0A
=0A
The rule should be= :
=0A=0A
=0A
#1. If the client can fix an error by sending an =E2=80=9CAuthor= ization: Bearer =E2=80=A6=E2=80=9D request header (or the query or POST alt= ernative) then the server should return =E2=80=9CWWW-Authenticate:=0A Beare= r =E2=80=A6=E2=80=9D.
=0A
=0A
=0A
 
=0A
=0A
=0A
#2. If the client can fix an e= rror by performing an OAuth2 flow at an authorization server then the resou= rce server should return =E2=80=9CWWW-Authenticate: OAuth2 =E2=80=A6=E2=80= =9D.
=0A=0A
=0A
 
=0A
=0A
=0A
The server can return both response headers i= f both options are possible.
=0A
=0A
=0A
 
=0A
=0A
=0A
There is no point in re= -presenting a rejected Bearer token so #1 isn=E2=80=99t that useful. It cou= ld be appropriate if no token was presented as the client might have a toke= n, but=0A didn=E2=80=99t know this resource needed it. It might be appropri= ate if a client presented a token with insufficient scope as the client mig= ht have another token with the right scope so =E2=80=9CWWW-Authenticate: Be= arer scope=3D=E2=80=A6=E2=80=9D could help. #1 is not really necessary when= =0A a presented token is invalid or expired as the client needs to get a ne= w one (eg using an OAuth2 flow that is outside the scope of the Bearer sche= me).
=0A=0A
=0A
 
=0A
=0A
=0A
I don=E2=80=99t think an error code in a =E2= =80=9CWWW-Authenticate: Bearer =E2=80=A6=E2=80=9D response helps a client r= etry the request with a =E2=80=9CAuthorization: Bearer =E2=80=A6=E2=80=9D h= eader that will work.
=0A
=0A
=0A
An error code might help a client choose the = right OAuth2 flow (eg refresh vs new user-delegation) so it might have a pl= ace in #2, a =E2=80=9CWWW-Authenticate: OAuth2 =E2=80=A6=E2=80=9D response= =0A header. =0A
=0A
=0A
 
=0A
=0A
=0A
Eran said to Mike:
=0A
=0A
=0A
> Alterna= tively, if you have use cases or requirements for introducing just the WWW-= Authenticate side of an OAuth2 authorization scheme (your open issue), whic= h includes=0A an =E2=80=98error=E2=80=99 attribute for use with the propose= d registry, please present those and explain how it will work alongside the= Bearer and MAC schemes (as currently drafted).
=0A
=0A
=0A
=  
=0A
=0A
=0AThe = =E2=80=9Cdiscovery=E2=80=9D use-case in this email warrants the WWW-Authent= icate side of an OAuth2 scheme.
=0A
=0A
=0A
An error attribute (plus a registry= ) might help, but we need the rest of the details of the response header fi= rst.
=0A=0A
=0A
It works well alongside Bearer and MAC schemes: a =E2=80=9CWWW= -Auth.: OAuth2=E2=80=9D response points to OAuth2 flows the client can try;= a =E2=80=9CWWW-Auth.: MAC/Bearer=E2=80=9D response points to retrying=0A a= request with =E2=80=9CAuthz: MAC/Bearer=E2=80=9D. Even when a client is gi= ven multiple options it will know which to choose based on its context (eg = if it doesn=E2=80=99t have another Bearer token it will ignore the =E2=80= =9CWWW-Auth: Bearer=E2=80=9D response and follow the =E2=80=9CWWW-Auth: OAu= th2=E2=80=9D=0A response).
=0A
=0A
=0A
 
=0A
=0A
=0A
 
=0A
=0A
=0A
= =0A
--
=0A=0A
=0A
James Manger
=0A
=0A
=0A
=0A
=0A

=0A______= _________________________________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps:/= /www.ietf.org/mailman/listinfo/oauth
=0A
=0A
=0A=
=0A
=0A
=0A =0A


--0-1871004363-1302245859=:29776-- From skylar@kiva.org Fri Apr 8 00:08:22 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1373B3A6A4C for ; Fri, 8 Apr 2011 00:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BS2lTu6ummh for ; Fri, 8 Apr 2011 00:08:20 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by core3.amsl.com (Postfix) with SMTP id 836423A6889 for ; Fri, 8 Apr 2011 00:08:20 -0700 (PDT) Received: from mail-iw0-f180.google.com ([209.85.214.180]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKTZ60zJQ6ngH4UZu2Aw86u4BKr9OIxHGw@postini.com; Fri, 08 Apr 2011 00:10:06 PDT Received: by iwn6 with SMTP id 6so4537587iwn.39 for ; Fri, 08 Apr 2011 00:10:04 -0700 (PDT) Received: by 10.231.199.77 with SMTP id er13mr1813269ibb.52.1302246604419; Fri, 08 Apr 2011 00:10:04 -0700 (PDT) Received: from [10.0.1.4] (c-24-5-80-5.hsd1.ca.comcast.net [24.5.80.5]) by mx.google.com with ESMTPS id i20sm1679147iby.48.2011.04.08.00.10.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2011 00:10:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Skylar Woodward In-Reply-To: <4D9EAAA2.9030809@lodderstedt.net> Date: Fri, 8 Apr 2011 00:10:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> <4D9EAAA2.9030809@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1084) Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 07:08:22 -0000 Yes, I can see how this might seem confusing. Actually, we're = authenticating the client with authorization server - not a resource = request. On the MAC threads we discussed how the token can be used for = both. Hopefully that clears everything up, but I'll briefly address = some of the questions inline. On Apr 7, 2011, at 11:26 PM, Torsten Lodderstedt wrote: > Hi Skylar, >=20 > Am 06.04.2011 18:02, schrieb Skylar Woodward: >> Well, I should elaborate. The method of authorization is open to the = client, and in this case (Kiva), MAC tokens are being used. The client = authenticates on the access_token request by presenting a MAC = authentication header. Creating the MAC signature requires a secret. In = the native client case, since there is no secret, it signs with the = empty string. So, how would you interpret this mechanism? Are we using = an empty string secret or signing without a secret? In terms of = communicating to the developers, they are told they don't have a secret. = For purposes of signing, they are instructed to sign with them empty = string when they have no secret. >=20 > You are talking about using the client secret to authenticate resource = server request, correct? This is not in scope of the core spec. I was = talking about authenticating the client with the authorization server. >=20 > Apart from that, do you think singing with an empty string adds any = security to your solution? No. It's about congruence at this point. Also, a MAC token by definition = is signed so it has to be some other assertion if it is not signed. > Moreover as far as I understand the MAC-Spec, it recommends to use = authorization server issued secrets to sign the request. So why do you = need a client secret for request signing? >=20 >> Alternatively, one could use Bearer token for client authentication = in this case where the token is just the client ID. To me this is more = confusing because they must authenticate with different token types for = secret vs. non-secret. Other opinions? >=20 > I'm confused now, why is the token the client id? A token is used by = the authorization server and may contain (or refer to) any data you need = to authorize access of the client to the resource server. Right, you're confusing the spec with the use. I'm considering the case = of a simple Bearer assertion in cases of client authentication where = clients have no secret since an ID/password assertion would imply an = empty-string password or secret. As Marius said, we're splitting hairs = at this point. Section 3.1 makes no notes on the possible value of = client_secret for clients w/o secrets, so the assumption was that a = value of "client_secret=3D&..." would be ignored resulting in an invalid = Client Password submission. >=20 >> As to the question of interoperability, the fact that OAuth allows = freedom of choice to the AS for method of authentication makes this = point moot. Would you agree? (short of various providers could pooling = together to standardize on an auth method outside of the spec). >=20 > What authentication are you refering to? Who do you want to = authenticate? Client authentication. Section 3.2. >=20 > regards, > Torsten. >=20 >>=20 >>=20 >> On Apr 4, 2011, at 10:15 PM, torsten@lodderstedt.net wrote: >>=20 >>> Hi Skylar, >>>=20 >>> Thank you for sharing this information with us. Some thougts: >>>=20 >>> The empty string makes your implementation syntactically compliant = but does obviously not comply with its semantics and the security = considerations/expectations associated with a secret. Moreover, what = about interoperability? >>>=20 >>> I think not using secrets for such clients is the honest solution. = We can just change the spec's text to express what we think is the right = way. >>>=20 >>> regards, >>> Torsten. >>> Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland >>>=20 >>> -----Original Message----- >>> From: Skylar Woodward >>> Date: Mon, 4 Apr 2011 19:14:53 >>> To: Torsten Lodderstedt >>> Cc: Zeltsan, Zachary (Zachary); = Kris Selden; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>=20 >>> In our implementation (not yet public) we accept the empty string = ("") as the value for clients not issued secrets. While this was done to = simplify the interface and implementation, it would make it compliant in = my view. In this case, the authorization server is validating the = credentials, which are the client ID and the empty string, which is = equivalent security-wise to any other length of "secret" issued to a = native client. >>>=20 >>> Besides, for many providers, the client credentials will only be a = client ID. They would plan to secure all exchanges over TLS and = credentials serve just as a tracking device or at best, a weak form of = identification. >>>=20 >>> skylar >>>=20 >>> On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote: >>>=20 >>>> Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): >>>>> According to section "6 Refreshing an Access Token" (-13.txt), = client when making a request for exchanging a refresh token for an = access token has to include its authentication credentials, and the = "authorization server MUST validate the client credentials". >>>>> How can this be done if a client is an application that can't have = a client secret? >>>>> The authorization code grant does require client authentication = (per section 4.1): >>>>>=20 >>>>> (D) The client requests an access token from the authorization >>>>> server's token endpoint by authenticating using its client >>>>> credentials, and includes the authorization code received = in the >>>>> previous step. >>>>>=20 >>>>> It appears that the clients that cannot keep its secret cannot use = (be issued) the refresh tokens. >>>> In my opinion, this part of the spec is misleading. Authorization = code MUST be possible without client authentication. Otherwise, OAuth is = useless for native apps. >>>>=20 >>>> = http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-= 01#section-2.10 describes how the flow can be protected in such cases. >>>>=20 >>>> regards, >>>> Torsten. >>>>> Zachary >>>>>=20 >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Marius Scurtescu >>>>> Sent: Monday, April 04, 2011 2:30 PM >>>>> To: Kris Selden >>>>> Cc: oauth@ietf.org >>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>>>=20 >>>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris = Selden wrote: >>>>>> A typical iPhone app cannot be shipped with a client secret and = rightly or wrongly users expect to only have to enter their credentials = once. >>>>>>=20 >>>>>> What is the best profile to use for an app that can't have a = client secret and needs a refresh token or a long lived access token? >>>>> The authorization code grant, aka web server flow. >>>>>=20 >>>>> The spec is misleading in this respect IMO. >>>>>=20 >>>>> Marius >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Fri Apr 8 00:15:50 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98053A6A4F for ; Fri, 8 Apr 2011 00:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzCidEbO2dV3 for ; Fri, 8 Apr 2011 00:15:46 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id DF5753A688F for ; Fri, 8 Apr 2011 00:15:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,322,1299416400"; d="scan'208,217";a="30252892" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 08 Apr 2011 17:17:30 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6309"; a="23241812" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbvi.tcif.telstra.com.au with ESMTP; 08 Apr 2011 17:17:30 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 8 Apr 2011 17:17:29 +1000 From: "Manger, James H" To: Eran Hammer-Lahav , OAuth WG Date: Fri, 8 Apr 2011 17:17:28 +1000 Thread-Topic: OAuth2 scheme Thread-Index: Acv0szxJR54h3FRORpezZ9L8nUeh+gAxRy2gAAXVW8AACmyNEA== Message-ID: <255B9BB34FB7D647A506DC292726F6E11281D308B0@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465664E11D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281CAB8DB@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E3B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664E3B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11281D308B0WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth2 scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 07:15:50 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11281D308B0WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Sorry, I didn't see this email before I sent my last one] > Chairs - I would like to ask that you declare all discovery requirements = and use cases out of scope for v2 and the working group at this point. > > --- > > As for the error code registry and the request Mike posted, I do not thin= k your use case has much to do with the goal Mike has with his registry pro= posal. Mike's proposal is for v2 to define an error registry for use with a= n error attribute across different HTTP schemes such as Bearer and MAC, and= for that to make sense, we need to define an OAuth2 scheme that *replaces*= the Bearer and MAC schemes - something you agree we should not do. An error code is part of discovery - it lets a client app "discover" what i= t needs to do next to gain access. We can have separate discovery of fairly static server capabilities and end= points and call that out of scope for v2. However, we still need dynamic discovery of which OAuth2 flow a client shou= ld do after a particular HTTP resource request fails. This is related to er= ror codes so needs to be as in-scope as error codes are. Indicating which O= Auth2 flow to perform should be OAuth2-specific, not kludged onto every (in= dependent) authentication scheme. P.S. I still absolutely agree that we should NOT define one OAuth2 scheme t= hat replaces Bearer and MAC. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E11281D308B0WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Sorry, I didn’t= see this email before I sent my last one]

 

> Chairs – I would li= ke to ask that you declare all discovery requirements and use cases out of = scope for v2 and the working group at this point.

> 

> ---

> 

> As for the error code reg= istry and the request Mike posted, I do not think your use case has much to= do with the goal Mike has with his registry proposal. Mike’s proposal is for v2 to define an error registry for = use with an error attribute across different HTTP schemes such as Bearer an= d MAC, and for that to make sense, we need to define an OAuth2 scheme that = *replaces* the Bearer and MAC schemes – something you agree we should not do.

&n= bsp;

&n= bsp;

An erro= r code is part of discovery – it lets a client app “discover= 221; what it needs to do next to gain access.

&n= bsp;

We can = have separate discovery of fairly static server capabilities and endpoints = and call that out of scope for v2.

However= , we still need dynamic discovery of which OAuth2 flow a client should do a= fter a particular HTTP resource request fails. This is related to error cod= es so needs to be as in-scope as error codes are. Indicating which OAuth2 flow to perform should be OAuth2-specif= ic, not kludged onto every (independent) authentication scheme.<= /span>

&n= bsp;

P.S. I = still absolutely agree that we should NOT define one OAuth2 scheme that rep= laces Bearer and MAC.

&n= bsp;

--=

James M= anger

--_000_255B9BB34FB7D647A506DC292726F6E11281D308B0WSMSG3153Vsrv_-- From skylar@kiva.org Fri Apr 8 00:33:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021573A6972 for ; Fri, 8 Apr 2011 00:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MngIst9ZrdWT for ; Fri, 8 Apr 2011 00:33:55 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by core3.amsl.com (Postfix) with SMTP id 0910F3A681B for ; Fri, 8 Apr 2011 00:33:54 -0700 (PDT) Received: from mail-iy0-f169.google.com ([209.85.210.169]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKTZ66y7fsaMGQ/v/LlmJr4kPNwQ47bZBN@postini.com; Fri, 08 Apr 2011 00:35:40 PDT Received: by iyf13 with SMTP id 13so4317342iyf.0 for ; Fri, 08 Apr 2011 00:35:39 -0700 (PDT) Received: by 10.42.238.140 with SMTP id ks12mr3078995icb.414.1302248139303; Fri, 08 Apr 2011 00:35:39 -0700 (PDT) Received: from [10.0.1.4] (c-24-5-80-5.hsd1.ca.comcast.net [24.5.80.5]) by mx.google.com with ESMTPS id o3sm1695010ibd.44.2011.04.08.00.35.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2011 00:35:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Fri, 8 Apr 2011 00:35:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0E263187-FC21-4F76-9973-E78939A799AA@kiva.org> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net> <38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> To: Marius Scurtescu X-Mailer: Apple Mail (2.1084) Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 07:33:56 -0000 I think I see the confusion now between this and Torsten's questions. = The assumption is that if the client has no secret, no assertion would = be made. No client authentication is performed. The app is essentially = anonymous. That's how folks interpret this? So while I agree in theory, I propose that many providers still want to = know the proposed identity of client, primarily for statistics or = record-tracking purposes. There is barely an incentive for a malicious = client to forge that of a secret-less client other than to skew the = statistics of that client. What's more, the Kiva system, as many others, = allow developers to revoke or disable all tokens associated with their = client. This would not be possible w/o some proposal of client ID during = authorization. Native clients are clients without secrets, but the don't = fall into the category of fully "anonymous" apps as I understand this = term to be used in the spec. So, perhaps this explains why we would allow password-less or = secret-less identity to be passed during authorization. Rather than = invent a new way to suggest identity in these cases, we simply use the = same mechanism (MAC) with no secret. It's a valid argument that we = should use another mechanism such as a provider-specific field or = Bearer. For what it's worth, we use the terminology VERIFIABLE and FORGEABLE in = our documentation to refer to clients with secrets and those without, = respectively. Forgeable clients are neither privileged nor punished (as = it were) for their spoof-able nature - native clients are an important = part of the ecosystem. skylar On Apr 4, 2011, at 5:08 PM, Marius Scurtescu wrote: > On Mon, Apr 4, 2011 at 4:14 PM, Skylar Woodward = wrote: >> In our implementation (not yet public) we accept the empty string = ("") as the value for clients not issued secrets. While this was done to = simplify the interface and implementation, it would make it compliant in = my view. In this case, the authorization server is validating the = credentials, which are the client ID and the empty string, which is = equivalent security-wise to any other length of "secret" issued to a = native client. >=20 > I am splitting hairs now, but according to the spec an empty parameter > value should be treated the same as if the parameter was not sent at > all. So, empty secret violates the requirement for the parameter to be > present. >=20 > Marius From andrewarnott@gmail.com Fri Apr 8 08:03:04 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 783A13A68DB for ; Fri, 8 Apr 2011 08:03:04 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuO8Cz5M5RJw for ; Fri, 8 Apr 2011 08:03:03 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 7C99C3A6876 for ; Fri, 8 Apr 2011 08:03:03 -0700 (PDT) Received: by qwc23 with SMTP id 23so2645640qwc.31 for ; Fri, 08 Apr 2011 08:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=wWeM3pRH1xP9+htfsatVgV0jkc4wjnnlOffxj/hKfig=; b=TSrkPvPcOUkouTzzqkKrb2N3NowhNRJaErRBa0Cr/IYAYR+TWQNTA+U4FKrXONSeJn aSDjBx9wmuvR1LNwjp40bm/TfO4aQYGVE+nGYWRSAt1ti3ImHVzarcMUFjbwf1a/XUZ6 YdvCFObI461g1Vl1ABcKveHLQX3MMRxLOCqSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ByaGlBA2dpQmtz4TxZfAaJ8mUAVN7FF3mKSjV0DMwU5jqpcW/qDiTpWNUOwLcO+l0/ 0xBd9aO59FBavMgGKZx3N7m46qhjr4NDaFvewhdp12iboTqvlfggwXVdsL5syOdX5cpz fPI88n9e4cmnRaOV+kZ3RvO3SPbIZSKcrrJ5o= MIME-Version: 1.0 Received: by 10.229.71.205 with SMTP id i13mr1843908qcj.279.1302275088665; Fri, 08 Apr 2011 08:04:48 -0700 (PDT) Received: by 10.229.224.70 with HTTP; Fri, 8 Apr 2011 08:04:48 -0700 (PDT) Date: Fri, 8 Apr 2011 08:04:48 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=0016e64fcc5a0f4e7304a0698c9b Subject: [OAUTH-WG] Confusing wording in section 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:03:04 -0000 --0016e64fcc5a0f4e7304a0698c9b Content-Type: text/plain; charset=ISO-8859-1 Draft 15, section 2.1 Since requests to the authorization endpoint result in user > authentication and the transmission of clear-text credentials (in the > HTTP response), the authorization server MUST require the use of a > transport-layer security mechanism when sending requests to the token > endpoints. The authorization server MUST support TLS 1.2 as defined > in [RFC5246], and MAY support additional transport-layer mechanisms > meeting its security requirements. > > I'm confused by the fact that token endpoints must use HTTPS due to a trait of the authorization endpoint. Am I missing something here, or is this perhaps a misprint? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo --0016e64fcc5a0f4e7304a0698c9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Draft 15, section 2.1

 Since requests to the authorization endpoint res=
ult in user
   authentication and the transmission of clear-text credentials (in the
   HTTP response), the authorization server MUST require the use of a
   transport-layer security mechanism when sending requests to the toke=
n
   endpoints.  The authorization server MUST support TLS 1.2 as defi=
ned
   in [RFC5246], and MAY support additional transport-layer mechanisms
   meeting its security requirements.
I'm= confused by the fact that token endpoints must use HTTPS due to a trait of= the authorization endpoint. =A0Am I missing something here, or is this per= haps a misprint?

--
Andrew Arnott
"I [may] not agree with what you= have to say, but I'll defend to the death your right to say it." = - S. G. Tallentyre=20
We're hiring! My team= at Microsoft has 7 open slots.=A0http://bit.ly/fZBVUo

--0016e64fcc5a0f4e7304a0698c9b-- From torsten@lodderstedt.net Fri Apr 8 09:11:51 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192533A680A for ; Fri, 8 Apr 2011 09:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjfv8ICFk-hK for ; Fri, 8 Apr 2011 09:11:50 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by core3.amsl.com (Postfix) with ESMTP id 6A2F328C0CE for ; Fri, 8 Apr 2011 09:11:49 -0700 (PDT) Received: from [80.187.101.179] (helo=[192.168.43.164]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Q8EJP-0000ae-H2; Fri, 08 Apr 2011 18:13:31 +0200 Message-ID: <4D9F3425.1030405@lodderstedt.net> Date: Fri, 08 Apr 2011 18:13:25 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Skylar Woodward References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> <4D9EAAA2.9030809@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 16:11:51 -0000 >>> As to the question of interoperability, the fact that OAuth allows freedom of choice to the AS for method of authentication makes this point moot. Would you agree? (short of various providers could pooling together to standardize on an auth method outside of the spec). One possible standard for clients without the capability to protect secrets would be to just omit secrets. Do you agree? And the spec itself could (should in my opinion) set this standard. regards, Torsten. From phil.hunt@oracle.com Fri Apr 8 09:20:45 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2313A28C0D7 for ; Fri, 8 Apr 2011 09:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PenuPBYuaGjw for ; Fri, 8 Apr 2011 09:20:43 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 36E5A3A69D2 for ; Fri, 8 Apr 2011 09:20:43 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p38GMNkB003160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 16:22:24 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p38GMLuM008824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2011 16:22:22 GMT Received: from abhmt021.oracle.com (abhmt021.oracle.com [141.146.116.30]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p38GMLh5020705; Fri, 8 Apr 2011 11:22:21 -0500 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Apr 2011 09:22:21 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Phil Hunt In-Reply-To: Date: Fri, 8 Apr 2011 09:22:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <17C3457F-22A3-42F9-BA0A-80CEDED9DF70@oracle.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> <4D9EAAA2.9030809@lodderstedt.net> To: Skylar Woodward X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4D9F363E.012B:SCFSTAT5015188,ss=1,fgs=0 Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 16:20:45 -0000 Why not have the client app generate a random text string to be used as = a request secret. The random text string would be matched during all = subsequent requests by the client surrounding a particular = authorization. Assuming the endpoints all require TLS for request side = operations it would prevent interception issues and bind the authz code = to a particular client instance even when matching client credentials = are used by an intercepting hacker. Would this help to satisfy at least some of the client app instance = identification issues? Note: it had also occurred to me that client apps should have static = client_instance identifiers. In practical terms this might be tied to an = IMEI number for example on a smart phone or other static information. = However, I don't think it would solve this security issue since it would = be easy to imitate. The above solution suggests a changing random string = instead. Phil phil.hunt@oracle.com On 2011-04-08, at 12:10 AM, Skylar Woodward wrote: > Yes, I can see how this might seem confusing. Actually, we're = authenticating the client with authorization server - not a resource = request. On the MAC threads we discussed how the token can be used for = both. Hopefully that clears everything up, but I'll briefly address = some of the questions inline. >=20 > On Apr 7, 2011, at 11:26 PM, Torsten Lodderstedt wrote: >=20 >> Hi Skylar, >>=20 >> Am 06.04.2011 18:02, schrieb Skylar Woodward: >>> Well, I should elaborate. The method of authorization is open to the = client, and in this case (Kiva), MAC tokens are being used. The client = authenticates on the access_token request by presenting a MAC = authentication header. Creating the MAC signature requires a secret. In = the native client case, since there is no secret, it signs with the = empty string. So, how would you interpret this mechanism? Are we using = an empty string secret or signing without a secret? In terms of = communicating to the developers, they are told they don't have a secret. = For purposes of signing, they are instructed to sign with them empty = string when they have no secret. >>=20 >> You are talking about using the client secret to authenticate = resource server request, correct? This is not in scope of the core spec. = I was talking about authenticating the client with the authorization = server. >>=20 >> Apart from that, do you think singing with an empty string adds any = security to your solution? >=20 > No. It's about congruence at this point. Also, a MAC token by = definition is signed so it has to be some other assertion if it is not = signed. >=20 >> Moreover as far as I understand the MAC-Spec, it recommends to use = authorization server issued secrets to sign the request. So why do you = need a client secret for request signing? >>=20 >>> Alternatively, one could use Bearer token for client authentication = in this case where the token is just the client ID. To me this is more = confusing because they must authenticate with different token types for = secret vs. non-secret. Other opinions? >>=20 >> I'm confused now, why is the token the client id? A token is used by = the authorization server and may contain (or refer to) any data you need = to authorize access of the client to the resource server. >=20 > Right, you're confusing the spec with the use. I'm considering the = case of a simple Bearer assertion in cases of client authentication = where clients have no secret since an ID/password assertion would imply = an empty-string password or secret. As Marius said, we're splitting = hairs at this point. Section 3.1 makes no notes on the possible value = of client_secret for clients w/o secrets, so the assumption was that a = value of "client_secret=3D&..." would be ignored resulting in an invalid = Client Password submission. >=20 >>=20 >>> As to the question of interoperability, the fact that OAuth allows = freedom of choice to the AS for method of authentication makes this = point moot. Would you agree? (short of various providers could pooling = together to standardize on an auth method outside of the spec). >>=20 >> What authentication are you refering to? Who do you want to = authenticate? >=20 > Client authentication. Section 3.2. >=20 >>=20 >> regards, >> Torsten. >>=20 >>>=20 >>>=20 >>> On Apr 4, 2011, at 10:15 PM, torsten@lodderstedt.net wrote: >>>=20 >>>> Hi Skylar, >>>>=20 >>>> Thank you for sharing this information with us. Some thougts: >>>>=20 >>>> The empty string makes your implementation syntactically compliant = but does obviously not comply with its semantics and the security = considerations/expectations associated with a secret. Moreover, what = about interoperability? >>>>=20 >>>> I think not using secrets for such clients is the honest solution. = We can just change the spec's text to express what we think is the right = way. >>>>=20 >>>> regards, >>>> Torsten. >>>> Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland >>>>=20 >>>> -----Original Message----- >>>> From: Skylar Woodward >>>> Date: Mon, 4 Apr 2011 19:14:53 >>>> To: Torsten Lodderstedt >>>> Cc: Zeltsan, Zachary (Zachary); = Kris Selden; oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>>=20 >>>> In our implementation (not yet public) we accept the empty string = ("") as the value for clients not issued secrets. While this was done to = simplify the interface and implementation, it would make it compliant in = my view. In this case, the authorization server is validating the = credentials, which are the client ID and the empty string, which is = equivalent security-wise to any other length of "secret" issued to a = native client. >>>>=20 >>>> Besides, for many providers, the client credentials will only be a = client ID. They would plan to secure all exchanges over TLS and = credentials serve just as a tracking device or at best, a weak form of = identification. >>>>=20 >>>> skylar >>>>=20 >>>> On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote: >>>>=20 >>>>> Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): >>>>>> According to section "6 Refreshing an Access Token" (-13.txt), = client when making a request for exchanging a refresh token for an = access token has to include its authentication credentials, and the = "authorization server MUST validate the client credentials". >>>>>> How can this be done if a client is an application that can't = have a client secret? >>>>>> The authorization code grant does require client authentication = (per section 4.1): >>>>>>=20 >>>>>> (D) The client requests an access token from the authorization >>>>>> server's token endpoint by authenticating using its client >>>>>> credentials, and includes the authorization code received = in the >>>>>> previous step. >>>>>>=20 >>>>>> It appears that the clients that cannot keep its secret cannot = use (be issued) the refresh tokens. >>>>> In my opinion, this part of the spec is misleading. Authorization = code MUST be possible without client authentication. Otherwise, OAuth is = useless for native apps. >>>>>=20 >>>>> = http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-= 01#section-2.10 describes how the flow can be protected in such cases. >>>>>=20 >>>>> regards, >>>>> Torsten. >>>>>> Zachary >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Marius Scurtescu >>>>>> Sent: Monday, April 04, 2011 2:30 PM >>>>>> To: Kris Selden >>>>>> Cc: oauth@ietf.org >>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>>>>=20 >>>>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris = Selden wrote: >>>>>>> A typical iPhone app cannot be shipped with a client secret and = rightly or wrongly users expect to only have to enter their credentials = once. >>>>>>>=20 >>>>>>> What is the best profile to use for an app that can't have a = client secret and needs a refresh token or a long lived access token? >>>>>> The authorization code grant, aka web server flow. >>>>>>=20 >>>>>> The spec is misleading in this respect IMO. >>>>>>=20 >>>>>> Marius >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Apr 8 09:20:46 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C725A28C0ED for ; Fri, 8 Apr 2011 09:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk4i66hed0ig for ; Fri, 8 Apr 2011 09:20:45 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 40A303A69D2 for ; Fri, 8 Apr 2011 09:20:45 -0700 (PDT) Received: (qmail 29135 invoked from network); 8 Apr 2011 16:22:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Apr 2011 16:22:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 8 Apr 2011 09:22:13 -0700 From: Eran Hammer-Lahav To: Andrew Arnott Date: Fri, 8 Apr 2011 09:22:04 -0700 Thread-Topic: [OAUTH-WG] Confusing wording in section 2.1 Thread-Index: Acv2CR4ygdZZHLZXSQ6JAGymoXk9Uw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A761E2128F85492DBB4F6EA743B5AFABhueniversecom_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Confusing wording in section 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 16:20:46 -0000 --_000_A761E2128F85492DBB4F6EA743B5AFABhueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VHlwby4NCg0KT24gQXByIDgsIDIwMTEsIGF0IDg6MDQsICJBbmRyZXcgQXJub3R0IiA8YW5kcmV3 YXJub3R0QGdtYWlsLmNvbTxtYWlsdG86YW5kcmV3YXJub3R0QGdtYWlsLmNvbT4+IHdyb3RlOg0K DQpEcmFmdCAxNSwgc2VjdGlvbiAyLjENCg0KDQogU2luY2UgcmVxdWVzdHMgdG8gdGhlIGF1dGhv cml6YXRpb24gZW5kcG9pbnQgcmVzdWx0IGluIHVzZXINCiAgIGF1dGhlbnRpY2F0aW9uIGFuZCB0 aGUgdHJhbnNtaXNzaW9uIG9mIGNsZWFyLXRleHQgY3JlZGVudGlhbHMgKGluIHRoZQ0KICAgSFRU UCByZXNwb25zZSksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlIHVz ZSBvZiBhDQogICB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkgbWVjaGFuaXNtIHdoZW4gc2VuZGlu ZyByZXF1ZXN0cyB0byB0aGUgdG9rZW4NCiAgIGVuZHBvaW50cy4gIFRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBNVVNUIHN1cHBvcnQgVExTIDEuMiBhcyBkZWZpbmVkDQogICBpbiBbUkZDNTI0Nl0s IGFuZCBNQVkgc3VwcG9ydCBhZGRpdGlvbmFsIHRyYW5zcG9ydC1sYXllciBtZWNoYW5pc21zDQog ICBtZWV0aW5nIGl0cyBzZWN1cml0eSByZXF1aXJlbWVudHMuDQoNCkknbSBjb25mdXNlZCBieSB0 aGUgZmFjdCB0aGF0IHRva2VuIGVuZHBvaW50cyBtdXN0IHVzZSBIVFRQUyBkdWUgdG8gYSB0cmFp dCBvZiB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gIEFtIEkgbWlzc2luZyBzb21ldGhpbmcg aGVyZSwgb3IgaXMgdGhpcyBwZXJoYXBzIGEgbWlzcHJpbnQ/DQoNCi0tDQpBbmRyZXcgQXJub3R0 DQoiSSBbbWF5XSBub3QgYWdyZWUgd2l0aCB3aGF0IHlvdSBoYXZlIHRvIHNheSwgYnV0IEknbGwg ZGVmZW5kIHRvIHRoZSBkZWF0aCB5b3VyIHJpZ2h0IHRvIHNheSBpdC4iIC0gUy4gRy4gVGFsbGVu dHlyZQ0KV2UncmUgaGlyaW5nISBNeSB0ZWFtIGF0IE1pY3Jvc29mdCBoYXMgNyBvcGVuIHNsb3Rz LiA8aHR0cDovL2JpdC5seS9mWkJWVW8+IGh0dHA6Ly9iaXQubHkvZlpCVlVvDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_A761E2128F85492DBB4F6EA743B5AFABhueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5UeXBvLiZuYnNwOzxicj48YnI+T24g QXByIDgsIDIwMTEsIGF0IDg6MDQsICJBbmRyZXcgQXJub3R0IiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmFuZHJld2Fybm90dEBnbWFpbC5jb20iPmFuZHJld2Fybm90dEBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRp dj5EcmFmdCAxNSwgc2VjdGlvbiAyLjE8ZGl2Pjxicj48L2Rpdj48ZGl2PjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAw cHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDAuOGV4OyBib3JkZXItbGVmdC13 aWR0aDogMXB4OyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBib3JkZXIt bGVmdC1zdHlsZTogc29saWQ7IHBhZGRpbmctbGVmdDogMWV4OyAiPg0KPHNwYW4gY2xhc3M9IkFw cGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGZv bnQtc2l6ZTogbWVkaXVtOyAiPjxwcmUgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgd2hp dGUtc3BhY2U6IHByZS13cmFwOyAiPiBTaW5jZSByZXF1ZXN0cyB0byB0aGUgPHNwYW4gY2xhc3M9 IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUs IDApOyI+YXV0aG9yaXphdGlvbiBlbmRwb2ludDwvc3Bhbj4gcmVzdWx0IGluIHVzZXINCiAgIGF1 dGhlbnRpY2F0aW9uIGFuZCB0aGUgdHJhbnNtaXNzaW9uIG9mIGNsZWFyLXRleHQgY3JlZGVudGlh bHMgKGluIHRoZQ0KICAgSFRUUCByZXNwb25zZSksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN VVNUIHJlcXVpcmUgdGhlIHVzZSBvZiBhDQogICB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkgbWVj aGFuaXNtIHdoZW4gc2VuZGluZyByZXF1ZXN0cyB0byB0aGUgPHNwYW4gY2xhc3M9IkFwcGxlLXN0 eWxlLXNwYW4iIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDApOyI+dG9r ZW4NCiAgIGVuZHBvaW50czwvc3Bhbj4uICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBz dXBwb3J0IFRMUyAxLjIgYXMgZGVmaW5lZA0KICAgaW4gW1JGQzUyNDZdLCBhbmQgTUFZIHN1cHBv cnQgYWRkaXRpb25hbCB0cmFuc3BvcnQtbGF5ZXIgbWVjaGFuaXNtcw0KICAgbWVldGluZyBpdHMg c2VjdXJpdHkgcmVxdWlyZW1lbnRzLjwvcHJlPjwvc3Bhbj48L2Jsb2NrcXVvdGU+PGRpdj5JJ20g Y29uZnVzZWQgYnkgdGhlIGZhY3QgdGhhdCB0b2tlbiBlbmRwb2ludHMgbXVzdCB1c2UgSFRUUFMg ZHVlIHRvIGEgdHJhaXQgb2YgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuICZuYnNwO0FtIEkg bWlzc2luZyBzb21ldGhpbmcgaGVyZSwgb3IgaXMgdGhpcyBwZXJoYXBzIGEgbWlzcHJpbnQ/PC9k aXY+DQo8ZGl2Pjxicj48L2Rpdj4tLTxicj5BbmRyZXcgQXJub3R0PGJyPiJJIFttYXldIG5vdCBh Z3JlZSB3aXRoIHdoYXQgeW91IGhhdmUgdG8gc2F5LCBidXQgSSdsbCBkZWZlbmQgdG8gdGhlIGRl YXRoIHlvdXIgcmlnaHQgdG8gc2F5IGl0LiIgLSBTLiBHLiBUYWxsZW50eXJlIA0KPGRpdj48c3Bh biBzdHlsZT0ibGluZS1oZWlnaHQ6MTRweDtmb250LWZhbWlseTonbHVjaWRhIGdyYW5kZScsIHRh aG9tYSwgdmVyZGFuYSwgYXJpYWwsIHNhbnMtc2VyaWY7Zm9udC1zaXplOjEzcHgiPldlJ3JlIGhp cmluZyEgTXkgdGVhbSBhdCBNaWNyb3NvZnQgaGFzIDcgb3BlbiBzbG90cy4mbmJzcDs8YSBocmVm PSJodHRwOi8vYml0Lmx5L2ZaQlZVbyIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9Imh0dHA6Ly9i aXQubHkvZlpCVlVvIj5odHRwOi8vYml0Lmx5L2ZaQlZVbzwvYT48L2E+PC9zcGFuPjwvZGl2Pg0K PGJyPg0KPC9kaXY+DQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzwvc3Bhbj48YnI+PHNwYW4+T0F1dGggbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+ PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+ PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --_000_A761E2128F85492DBB4F6EA743B5AFABhueniversecom_-- From SRS0=2TtAFe=XA=lodderstedt.net=torsten@srs.bis7.eu.blackberry.com Fri Apr 8 09:35:31 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8DB3A6937 for ; Fri, 8 Apr 2011 09:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.643 X-Spam-Level: X-Spam-Status: No, score=-4.643 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJc16dOo6ozX for ; Fri, 8 Apr 2011 09:35:29 -0700 (PDT) Received: from smtp10.bis7.eu.blackberry.com (smtp10.bis7.eu.blackberry.com [178.239.85.15]) by core3.amsl.com (Postfix) with ESMTP id A808D3A6889 for ; Fri, 8 Apr 2011 09:35:28 -0700 (PDT) Received: from b1.c11.bise7.blackberry ([192.168.0.101]) by srs.bis7.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p38GbCaG010197; Fri, 8 Apr 2011 16:37:12 GMT Received: from ups31.c11.bise7.blackberry (cmp31.c11.bise7.blackberry [172.18.204.201]) by b1.c11.bise7.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p38GbCDJ031237; Fri, 8 Apr 2011 16:37:12 GMT X-rim-org-msg-ref-id: 859122783 Message-ID: <859122783-1302280631-cardhu_decombobulator_blackberry.rim.net-1217985074-@b1.c11.bise7.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> <4D9EAAA2.9030809@lodderstedt.net> <17C3457F-22A3-42F9-BA0A-80CEDED9DF70@oracle.com> In-Reply-To: <17C3457F-22A3-42F9-BA0A-80CEDED9DF70@oracle.com> Sensitivity: Normal Importance: Normal To: "Phil Hunt" , "Skylar Woodward" From: torsten@lodderstedt.net Date: Fri, 8 Apr 2011 16:36:30 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 16:36:01 -0000 VGhpcyB3b3VsZCBiZSBhbm90aGVyIHBvc3NpYmxlIHN0YW5kYXJkIG9wdGlvbi4gQXMgeW91IHBv aW50ZWQgb3V0LCBpdCB3b3VsZCBoZWxwIHRvIGRldGVjdCBhdXRoeiBjb2RlIHRoZWZ0IGV2ZW4g Zm9yIG5hdGl2ZSBhcHBzLiBJdCB3b3VsZCBub3QgaGVscCB3cnQgY2xpZW50IGF1dGhvcml6YXRp b24gc2luY2UgdGhlcmUgYXJlIG5vIHByb3BlcnRpZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBuZXcg Y3JlZGVudGlhbC4NCg0KVGhlIGtleSBpczogaG93IGRvZXMgdGhlIGF1dGh6IHNlcnZlciBnZXQg dG8ga25vdyB0aGlzIHNlY3JldD8gQXMgdGhlIHJlZGlyZWN0cyBhcmUgbm90IGZ1bGx5IHByb3Rl Y3RlZCBhZ2FpbnN0IGxlYWtzIChoaXN0b3J5LCByZWZlcmVycykgSSB3b3VsZCBub3QgcGFzcyBp dCBpbiBhcyBhIHBhcmFtZXRlciB0byB0aGUgYXV0aHogcmVxdWVzdC4gDQoNClJlZ2FyZHMsDQpU b3JzdGVuLg0KR2VzZW5kZXQgbWl0IEJsYWNrQmVycnmuIFdlYm1haWwgdm9uIFRlbGVrb20gRGV1 dHNjaGxhbmQgIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGhpbCBIdW50 IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCkRhdGU6IEZyaSwgOCBBcHIgMjAxMSAwOToyMjoxOCAN ClRvOiBTa3lsYXIgV29vZHdhcmQ8c2t5bGFyQGtpdmEub3JnPg0KQ2M6IFRvcnN0ZW4gTG9kZGVy c3RlZHQ8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+OyBLcmlzIFNlbGRlbjxrcmlzLnNlbGRlbkBn bWFpbC5jb20+OyBaZWx0c2FuLCBaYWNoYXJ5IFwoWmFjaGFyeVwpPHphY2hhcnkuemVsdHNhbkBh bGNhdGVsLWx1Y2VudC5jb20+OyBvYXV0aEBpZXRmLm9yZzxvYXV0aEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIEZsb3djaGFydCBmb3IgbGVncyBvZiBPQXV0aA0KDQpXaHkgbm90 IGhhdmUgdGhlIGNsaWVudCBhcHAgZ2VuZXJhdGUgYSByYW5kb20gdGV4dCBzdHJpbmcgdG8gYmUg dXNlZCBhcyBhIHJlcXVlc3Qgc2VjcmV0LiAgVGhlIHJhbmRvbSB0ZXh0IHN0cmluZyB3b3VsZCBi ZSBtYXRjaGVkIGR1cmluZyBhbGwgc3Vic2VxdWVudCByZXF1ZXN0cyBieSB0aGUgY2xpZW50IHN1 cnJvdW5kaW5nIGEgcGFydGljdWxhciBhdXRob3JpemF0aW9uLiAgQXNzdW1pbmcgdGhlIGVuZHBv aW50cyBhbGwgcmVxdWlyZSBUTFMgZm9yIHJlcXVlc3Qgc2lkZSBvcGVyYXRpb25zIGl0IHdvdWxk IHByZXZlbnQgaW50ZXJjZXB0aW9uIGlzc3VlcyBhbmQgYmluZCB0aGUgYXV0aHogY29kZSB0byBh IHBhcnRpY3VsYXIgY2xpZW50IGluc3RhbmNlIGV2ZW4gd2hlbiBtYXRjaGluZyBjbGllbnQgY3Jl ZGVudGlhbHMgYXJlIHVzZWQgYnkgYW4gaW50ZXJjZXB0aW5nIGhhY2tlci4NCg0KV291bGQgdGhp cyBoZWxwIHRvIHNhdGlzZnkgYXQgbGVhc3Qgc29tZSBvZiB0aGUgY2xpZW50IGFwcCBpbnN0YW5j ZSBpZGVudGlmaWNhdGlvbiBpc3N1ZXM/DQoNCk5vdGU6IGl0IGhhZCBhbHNvIG9jY3VycmVkIHRv IG1lIHRoYXQgY2xpZW50IGFwcHMgc2hvdWxkIGhhdmUgc3RhdGljIGNsaWVudF9pbnN0YW5jZSBp ZGVudGlmaWVycy4gSW4gcHJhY3RpY2FsIHRlcm1zIHRoaXMgbWlnaHQgYmUgdGllZCB0byBhbiBJ TUVJIG51bWJlciBmb3IgZXhhbXBsZSBvbiBhIHNtYXJ0IHBob25lIG9yIG90aGVyIHN0YXRpYyBp bmZvcm1hdGlvbi4gSG93ZXZlciwgSSBkb24ndCB0aGluayBpdCB3b3VsZCBzb2x2ZSB0aGlzIHNl Y3VyaXR5IGlzc3VlIHNpbmNlIGl0IHdvdWxkIGJlIGVhc3kgdG8gaW1pdGF0ZS4gVGhlIGFib3Zl IHNvbHV0aW9uIHN1Z2dlc3RzIGEgY2hhbmdpbmcgcmFuZG9tIHN0cmluZyBpbnN0ZWFkLg0KDQpQ aGlsDQpwaGlsLmh1bnRAb3JhY2xlLmNvbQ0KDQoNCg0KDQpPbiAyMDExLTA0LTA4LCBhdCAxMjox MCBBTSwgU2t5bGFyIFdvb2R3YXJkIHdyb3RlOg0KDQo+IFllcywgSSBjYW4gc2VlIGhvdyB0aGlz IG1pZ2h0IHNlZW0gY29uZnVzaW5nLiBBY3R1YWxseSwgd2UncmUgYXV0aGVudGljYXRpbmcgdGhl IGNsaWVudCB3aXRoIGF1dGhvcml6YXRpb24gc2VydmVyIC0gbm90IGEgcmVzb3VyY2UgcmVxdWVz dC4gIE9uIHRoZSBNQUMgdGhyZWFkcyB3ZSBkaXNjdXNzZWQgaG93IHRoZSB0b2tlbiBjYW4gYmUg dXNlZCBmb3IgYm90aC4gIEhvcGVmdWxseSB0aGF0IGNsZWFycyBldmVyeXRoaW5nIHVwLCBidXQg SSdsbCBicmllZmx5IGFkZHJlc3Mgc29tZSBvZiB0aGUgcXVlc3Rpb25zIGlubGluZS4NCj4gDQo+ IE9uIEFwciA3LCAyMDExLCBhdCAxMToyNiBQTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90ZToN Cj4gDQo+PiBIaSBTa3lsYXIsDQo+PiANCj4+IEFtIDA2LjA0LjIwMTEgMTg6MDIsIHNjaHJpZWIg U2t5bGFyIFdvb2R3YXJkOg0KPj4+IFdlbGwsIEkgc2hvdWxkIGVsYWJvcmF0ZS4gVGhlIG1ldGhv ZCBvZiBhdXRob3JpemF0aW9uIGlzIG9wZW4gdG8gdGhlIGNsaWVudCwgYW5kIGluIHRoaXMgY2Fz ZSAoS2l2YSksIE1BQyB0b2tlbnMgYXJlIGJlaW5nIHVzZWQuIFRoZSBjbGllbnQgYXV0aGVudGlj YXRlcyBvbiB0aGUgYWNjZXNzX3Rva2VuIHJlcXVlc3QgYnkgcHJlc2VudGluZyBhIE1BQyBhdXRo ZW50aWNhdGlvbiBoZWFkZXIuIENyZWF0aW5nIHRoZSBNQUMgc2lnbmF0dXJlIHJlcXVpcmVzIGEg c2VjcmV0LiBJbiB0aGUgbmF0aXZlIGNsaWVudCBjYXNlLCBzaW5jZSB0aGVyZSBpcyBubyBzZWNy ZXQsIGl0IHNpZ25zIHdpdGggdGhlIGVtcHR5IHN0cmluZy4gU28sIGhvdyB3b3VsZCB5b3UgaW50 ZXJwcmV0IHRoaXMgbWVjaGFuaXNtPyBBcmUgd2UgdXNpbmcgYW4gZW1wdHkgc3RyaW5nIHNlY3Jl dCBvciBzaWduaW5nIHdpdGhvdXQgYSBzZWNyZXQ/IEluIHRlcm1zIG9mIGNvbW11bmljYXRpbmcg dG8gdGhlIGRldmVsb3BlcnMsIHRoZXkgYXJlIHRvbGQgdGhleSBkb24ndCBoYXZlIGEgc2VjcmV0 LiBGb3IgcHVycG9zZXMgb2Ygc2lnbmluZywgdGhleSBhcmUgaW5zdHJ1Y3RlZCB0byBzaWduIHdp dGggdGhlbSBlbXB0eSBzdHJpbmcgd2hlbiB0aGV5IGhhdmUgbm8gc2VjcmV0Lg0KPj4gDQo+PiBZ b3UgYXJlIHRhbGtpbmcgYWJvdXQgdXNpbmcgdGhlIGNsaWVudCBzZWNyZXQgdG8gYXV0aGVudGlj YXRlIHJlc291cmNlIHNlcnZlciByZXF1ZXN0LCBjb3JyZWN0PyBUaGlzIGlzIG5vdCBpbiBzY29w ZSBvZiB0aGUgY29yZSBzcGVjLiBJIHdhcyB0YWxraW5nIGFib3V0IGF1dGhlbnRpY2F0aW5nIHRo ZSBjbGllbnQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuDQo+PiANCj4+IEFwYXJ0IGZy b20gdGhhdCwgZG8geW91IHRoaW5rIHNpbmdpbmcgd2l0aCBhbiBlbXB0eSBzdHJpbmcgYWRkcyBh bnkgc2VjdXJpdHkgdG8geW91ciBzb2x1dGlvbj8NCj4gDQo+IE5vLiBJdCdzIGFib3V0IGNvbmdy dWVuY2UgYXQgdGhpcyBwb2ludC4gQWxzbywgYSBNQUMgdG9rZW4gYnkgZGVmaW5pdGlvbiBpcyBz aWduZWQgc28gaXQgaGFzIHRvIGJlIHNvbWUgb3RoZXIgYXNzZXJ0aW9uIGlmIGl0IGlzIG5vdCBz aWduZWQuDQo+IA0KPj4gTW9yZW92ZXIgYXMgZmFyIGFzIEkgdW5kZXJzdGFuZCB0aGUgTUFDLVNw ZWMsIGl0IHJlY29tbWVuZHMgdG8gdXNlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlZCBzZWNy ZXRzIHRvIHNpZ24gdGhlIHJlcXVlc3QuIFNvIHdoeSBkbyB5b3UgbmVlZCBhIGNsaWVudCBzZWNy ZXQgZm9yIHJlcXVlc3Qgc2lnbmluZz8NCj4+IA0KPj4+IEFsdGVybmF0aXZlbHksIG9uZSBjb3Vs ZCB1c2UgQmVhcmVyIHRva2VuIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gaW4gdGhpcyBjYXNl IHdoZXJlIHRoZSB0b2tlbiBpcyBqdXN0IHRoZSBjbGllbnQgSUQuIFRvIG1lIHRoaXMgaXMgbW9y ZSBjb25mdXNpbmcgYmVjYXVzZSB0aGV5IG11c3QgYXV0aGVudGljYXRlIHdpdGggZGlmZmVyZW50 IHRva2VuIHR5cGVzIGZvciBzZWNyZXQgdnMuIG5vbi1zZWNyZXQuICBPdGhlciBvcGluaW9ucz8N Cj4+IA0KPj4gSSdtIGNvbmZ1c2VkIG5vdywgd2h5IGlzIHRoZSB0b2tlbiB0aGUgY2xpZW50IGlk PyBBIHRva2VuIGlzIHVzZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCBtYXkgY29u dGFpbiAob3IgcmVmZXIgdG8pIGFueSBkYXRhIHlvdSBuZWVkIHRvIGF1dGhvcml6ZSBhY2Nlc3Mg b2YgdGhlIGNsaWVudCB0byB0aGUgcmVzb3VyY2Ugc2VydmVyLg0KPiANCj4gUmlnaHQsIHlvdSdy ZSBjb25mdXNpbmcgdGhlIHNwZWMgd2l0aCB0aGUgdXNlLiBJJ20gY29uc2lkZXJpbmcgdGhlIGNh c2Ugb2YgYSBzaW1wbGUgQmVhcmVyIGFzc2VydGlvbiBpbiBjYXNlcyBvZiBjbGllbnQgYXV0aGVu dGljYXRpb24gd2hlcmUgY2xpZW50cyBoYXZlIG5vIHNlY3JldCBzaW5jZSBhbiBJRC9wYXNzd29y ZCBhc3NlcnRpb24gd291bGQgaW1wbHkgYW4gZW1wdHktc3RyaW5nIHBhc3N3b3JkIG9yIHNlY3Jl dC4gQXMgTWFyaXVzIHNhaWQsIHdlJ3JlIHNwbGl0dGluZyBoYWlycyBhdCB0aGlzIHBvaW50LiAg U2VjdGlvbiAzLjEgbWFrZXMgbm8gbm90ZXMgb24gdGhlIHBvc3NpYmxlIHZhbHVlIG9mIGNsaWVu dF9zZWNyZXQgZm9yIGNsaWVudHMgdy9vIHNlY3JldHMsIHNvIHRoZSBhc3N1bXB0aW9uIHdhcyB0 aGF0IGEgdmFsdWUgb2YgImNsaWVudF9zZWNyZXQ9Ji4uLiIgd291bGQgYmUgaWdub3JlZCByZXN1 bHRpbmcgaW4gYW4gaW52YWxpZCBDbGllbnQgUGFzc3dvcmQgc3VibWlzc2lvbi4NCj4gDQo+PiAN Cj4+PiBBcyB0byB0aGUgcXVlc3Rpb24gb2YgaW50ZXJvcGVyYWJpbGl0eSwgdGhlIGZhY3QgdGhh dCBPQXV0aCBhbGxvd3MgZnJlZWRvbSBvZiBjaG9pY2UgdG8gdGhlIEFTIGZvciBtZXRob2Qgb2Yg YXV0aGVudGljYXRpb24gbWFrZXMgdGhpcyBwb2ludCBtb290LiBXb3VsZCB5b3UgYWdyZWU/IChz aG9ydCBvZiB2YXJpb3VzIHByb3ZpZGVycyBjb3VsZCBwb29saW5nIHRvZ2V0aGVyIHRvIHN0YW5k YXJkaXplIG9uIGFuIGF1dGggbWV0aG9kIG91dHNpZGUgb2YgdGhlIHNwZWMpLg0KPj4gDQo+PiBX aGF0IGF1dGhlbnRpY2F0aW9uIGFyZSB5b3UgcmVmZXJpbmcgdG8/IFdobyBkbyB5b3Ugd2FudCB0 byBhdXRoZW50aWNhdGU/DQo+IA0KPiBDbGllbnQgYXV0aGVudGljYXRpb24uIFNlY3Rpb24gMy4y Lg0KPiANCj4+IA0KPj4gcmVnYXJkcywNCj4+IFRvcnN0ZW4uDQo+PiANCj4+PiANCj4+PiANCj4+ PiBPbiBBcHIgNCwgMjAxMSwgYXQgMTA6MTUgUE0sIHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IHdy b3RlOg0KPj4+IA0KPj4+PiBIaSBTa3lsYXIsDQo+Pj4+IA0KPj4+PiBUaGFuayB5b3UgZm9yIHNo YXJpbmcgdGhpcyBpbmZvcm1hdGlvbiB3aXRoIHVzLiBTb21lIHRob3VndHM6DQo+Pj4+IA0KPj4+ PiBUaGUgZW1wdHkgc3RyaW5nIG1ha2VzIHlvdXIgaW1wbGVtZW50YXRpb24gc3ludGFjdGljYWxs eSBjb21wbGlhbnQgYnV0IGRvZXMgb2J2aW91c2x5IG5vdCBjb21wbHkgd2l0aCBpdHMgc2VtYW50 aWNzIGFuZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMvZXhwZWN0YXRpb25zIGFzc29jaWF0 ZWQgd2l0aCBhIHNlY3JldC4gTW9yZW92ZXIsIHdoYXQgYWJvdXQgaW50ZXJvcGVyYWJpbGl0eT8N Cj4+Pj4gDQo+Pj4+IEkgdGhpbmsgbm90IHVzaW5nIHNlY3JldHMgZm9yIHN1Y2ggY2xpZW50cyBp cyB0aGUgaG9uZXN0IHNvbHV0aW9uLiBXZSBjYW4ganVzdCBjaGFuZ2UgdGhlIHNwZWMncyB0ZXh0 IHRvIGV4cHJlc3Mgd2hhdCB3ZSB0aGluayBpcyB0aGUgcmlnaHQgd2F5Lg0KPj4+PiANCj4+Pj4g cmVnYXJkcywNCj4+Pj4gVG9yc3Rlbi4NCj4+Pj4gR2VzZW5kZXQgbWl0IEJsYWNrQmVycnmuIFdl Ym1haWwgdm9uIFRlbGVrb20gRGV1dHNjaGxhbmQNCj4+Pj4gDQo+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IFNreWxhciBXb29kd2FyZDxza3lsYXJAa2l2YS5vcmc+ DQo+Pj4+IERhdGU6IE1vbiwgNCBBcHIgMjAxMSAxOToxNDo1Mw0KPj4+PiBUbzogVG9yc3RlbiBM b2RkZXJzdGVkdDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCj4+Pj4gQ2M6IFplbHRzYW4sIFph Y2hhcnkgKFphY2hhcnkpPHphY2hhcnkuemVsdHNhbkBhbGNhdGVsLWx1Y2VudC5jb20+OyBLcmlz IFNlbGRlbjxrcmlzLnNlbGRlbkBnbWFpbC5jb20+OyBvYXV0aEBpZXRmLm9yZzxvYXV0aEBpZXRm Lm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRmxvd2NoYXJ0IGZvciBsZWdzIG9m IE9BdXRoDQo+Pj4+IA0KPj4+PiBJbiBvdXIgaW1wbGVtZW50YXRpb24gKG5vdCB5ZXQgcHVibGlj KSB3ZSBhY2NlcHQgdGhlIGVtcHR5IHN0cmluZyAoIiIpIGFzIHRoZSB2YWx1ZSBmb3IgY2xpZW50 cyBub3QgaXNzdWVkIHNlY3JldHMuIFdoaWxlIHRoaXMgd2FzIGRvbmUgdG8gc2ltcGxpZnkgdGhl IGludGVyZmFjZSBhbmQgaW1wbGVtZW50YXRpb24sIGl0IHdvdWxkIG1ha2UgaXQgY29tcGxpYW50 IGluIG15IHZpZXcuICBJbiB0aGlzIGNhc2UsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpcyB2 YWxpZGF0aW5nIHRoZSBjcmVkZW50aWFscywgd2hpY2ggYXJlIHRoZSBjbGllbnQgSUQgYW5kIHRo ZSBlbXB0eSBzdHJpbmcsIHdoaWNoIGlzIGVxdWl2YWxlbnQgc2VjdXJpdHktd2lzZSB0byBhbnkg b3RoZXIgbGVuZ3RoIG9mICJzZWNyZXQiIGlzc3VlZCB0byBhIG5hdGl2ZSBjbGllbnQuDQo+Pj4+ IA0KPj4+PiBCZXNpZGVzLCBmb3IgbWFueSBwcm92aWRlcnMsIHRoZSBjbGllbnQgY3JlZGVudGlh bHMgd2lsbCBvbmx5IGJlIGEgY2xpZW50IElELiBUaGV5IHdvdWxkIHBsYW4gdG8gc2VjdXJlIGFs bCBleGNoYW5nZXMgb3ZlciBUTFMgYW5kIGNyZWRlbnRpYWxzIHNlcnZlIGp1c3QgYXMgYSB0cmFj a2luZyBkZXZpY2Ugb3IgYXQgYmVzdCwgYSB3ZWFrIGZvcm0gb2YgaWRlbnRpZmljYXRpb24uDQo+ Pj4+IA0KPj4+PiBza3lsYXINCj4+Pj4gDQo+Pj4+IE9uIEFwciA0LCAyMDExLCBhdCA1OjAxIFBN LCBUb3JzdGVuIExvZGRlcnN0ZWR0IHdyb3RlOg0KPj4+PiANCj4+Pj4+IEFtIDA0LjA0LjIwMTEg MjE6MzgsIHNjaHJpZWIgWmVsdHNhbiwgWmFjaGFyeSAoWmFjaGFyeSk6DQo+Pj4+Pj4gQWNjb3Jk aW5nIHRvIHNlY3Rpb24gIjYgUmVmcmVzaGluZyBhbiBBY2Nlc3MgVG9rZW4iICgtMTMudHh0KSwg Y2xpZW50IHdoZW4gbWFraW5nIGEgcmVxdWVzdCBmb3IgZXhjaGFuZ2luZyBhIHJlZnJlc2ggdG9r ZW4gZm9yIGFuIGFjY2VzcyB0b2tlbiBoYXMgdG8gaW5jbHVkZSBpdHMgYXV0aGVudGljYXRpb24g Y3JlZGVudGlhbHMsIGFuZCB0aGUgImF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgdmFsaWRhdGUg dGhlIGNsaWVudCBjcmVkZW50aWFscyIuDQo+Pj4+Pj4gSG93IGNhbiB0aGlzIGJlIGRvbmUgaWYg YSBjbGllbnQgaXMgYW4gYXBwbGljYXRpb24gdGhhdCBjYW4ndCBoYXZlIGEgY2xpZW50IHNlY3Jl dD8NCj4+Pj4+PiBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IGRvZXMgcmVxdWlyZSBjbGll bnQgYXV0aGVudGljYXRpb24gKHBlciBzZWN0aW9uIDQuMSk6DQo+Pj4+Pj4gDQo+Pj4+Pj4gKEQp ICBUaGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0 aW9uDQo+Pj4+Pj4gICAgICAgc2VydmVyJ3MgdG9rZW4gZW5kcG9pbnQgYnkgYXV0aGVudGljYXRp bmcgdXNpbmcgaXRzIGNsaWVudA0KPj4+Pj4+ICAgICAgIGNyZWRlbnRpYWxzLCBhbmQgaW5jbHVk ZXMgdGhlIGF1dGhvcml6YXRpb24gY29kZSByZWNlaXZlZCBpbiB0aGUNCj4+Pj4+PiAgICAgICBw cmV2aW91cyBzdGVwLg0KPj4+Pj4+IA0KPj4+Pj4+IEl0IGFwcGVhcnMgdGhhdCB0aGUgY2xpZW50 cyB0aGF0IGNhbm5vdCBrZWVwIGl0cyBzZWNyZXQgY2Fubm90IHVzZSAoYmUgaXNzdWVkKSB0aGUg cmVmcmVzaCB0b2tlbnMuDQo+Pj4+PiBJbiBteSBvcGluaW9uLCB0aGlzIHBhcnQgb2YgdGhlIHNw ZWMgaXMgbWlzbGVhZGluZy4gQXV0aG9yaXphdGlvbiBjb2RlIE1VU1QgYmUgcG9zc2libGUgd2l0 aG91dCBjbGllbnQgYXV0aGVudGljYXRpb24uIE90aGVyd2lzZSwgT0F1dGggaXMgdXNlbGVzcyBm b3IgbmF0aXZlIGFwcHMuDQo+Pj4+PiANCj4+Pj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXNlY3VyaXR5Y29uc2lkZXJhdGlvbnMtMDEjc2VjdGlv bi0yLjEwIGRlc2NyaWJlcyBob3cgdGhlIGZsb3cgY2FuIGJlIHByb3RlY3RlZCBpbiBzdWNoIGNh c2VzLg0KPj4+Pj4gDQo+Pj4+PiByZWdhcmRzLA0KPj4+Pj4gVG9yc3Rlbi4NCj4+Pj4+PiBaYWNo YXJ5DQo+Pj4+Pj4gDQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBG cm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE1hcml1cyBTY3VydGVzY3UNCj4+Pj4+PiBTZW50OiBNb25kYXksIEFw cmlsIDA0LCAyMDExIDI6MzAgUE0NCj4+Pj4+PiBUbzogS3JpcyBTZWxkZW4NCj4+Pj4+PiBDYzog b2F1dGhAaWV0Zi5vcmcNCj4+Pj4+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBGbG93Y2hhcnQg Zm9yIGxlZ3Mgb2YgT0F1dGgNCj4+Pj4+PiANCj4+Pj4+PiBPbiBNb24sIEFwciA0LCAyMDExIGF0 IDEwOjQ3IEFNLCBLcmlzIFNlbGRlbjxrcmlzLnNlbGRlbkBnbWFpbC5jb20+ICAgd3JvdGU6DQo+ Pj4+Pj4+IEEgdHlwaWNhbCBpUGhvbmUgYXBwIGNhbm5vdCBiZSBzaGlwcGVkIHdpdGggYSBjbGll bnQgc2VjcmV0IGFuZCByaWdodGx5IG9yIHdyb25nbHkgdXNlcnMgZXhwZWN0IHRvIG9ubHkgaGF2 ZSB0byBlbnRlciB0aGVpciBjcmVkZW50aWFscyBvbmNlLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gV2hh dCBpcyB0aGUgYmVzdCBwcm9maWxlIHRvIHVzZSBmb3IgYW4gYXBwIHRoYXQgY2FuJ3QgaGF2ZSBh IGNsaWVudCBzZWNyZXQgYW5kIG5lZWRzIGEgcmVmcmVzaCB0b2tlbiBvciBhIGxvbmcgbGl2ZWQg YWNjZXNzIHRva2VuPw0KPj4+Pj4+IFRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQsIGFrYSB3 ZWIgc2VydmVyIGZsb3cuDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhlIHNwZWMgaXMgbWlzbGVhZGluZyBp biB0aGlzIHJlc3BlY3QgSU1PLg0KPj4+Pj4+IA0KPj4+Pj4+IE1hcml1cw0KPj4+Pj4+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBPQXV0aCBt YWlsaW5nIGxpc3QNCj4+Pj4+PiBPQXV0aEBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4+Pj4+Pl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ Pj4+Pj4gT0F1dGhAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQo+Pj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4+IE9BdXRoQGlldGYu b3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ IA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9B dXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== From phil.hunt@oracle.com Fri Apr 8 09:47:54 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D44E3A6937 for ; Fri, 8 Apr 2011 09:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6mkSICjB7wj for ; Fri, 8 Apr 2011 09:47:52 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 69A7A3A690B for ; Fri, 8 Apr 2011 09:47:52 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p38GnX9E018638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 16:49:34 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p38GnW7b011949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2011 16:49:32 GMT Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p38GnVIL009934; Fri, 8 Apr 2011 11:49:31 -0500 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Apr 2011 09:49:31 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Phil Hunt X-Priority: Normal In-Reply-To: <859122783-1302280631-cardhu_decombobulator_blackberry.rim.net-1217985074-@b1.c11.bise7.blackberry> Date: Fri, 8 Apr 2011 09:49:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> <4D9EAAA2.9030809@lodderstedt.net> <17C3457F-22A3-42F9-BA0A-80CEDED9DF70@oracle.com> <859122783-1302280631-cardhu_decombobulator_blackberry.rim.net-1217985074-@b1.c11.bise7.blackberry> To: torsten@lodderstedt.net X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4D9F3C9D.006D:SCFSTAT5015188,ss=1,fgs=0 Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 16:47:54 -0000 I am assuming the outbound requests are secured by TLS, but for various = reasons the return path (e.g. the redirect) might not be. Thus, one = restriction would be that the server never returns the code to the = client. Thus, you could submit a secret simply for the purpose of verifying the = same specific requestor for each operation. Phil phil.hunt@oracle.com On 2011-04-08, at 9:36 AM, torsten@lodderstedt.net wrote: > This would be another possible standard option. As you pointed out, it = would help to detect authz code theft even for native apps. It would not = help wrt client authorization since there are no properties associated = with the new credential. >=20 > The key is: how does the authz server get to know this secret? As the = redirects are not fully protected against leaks (history, referers) I = would not pass it in as a parameter to the authz request.=20 >=20 > Regards, > Torsten. > Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland =20 >=20 > -----Original Message----- > From: Phil Hunt > Date: Fri, 8 Apr 2011 09:22:18=20 > To: Skylar Woodward > Cc: Torsten Lodderstedt; Kris = Selden; Zeltsan, Zachary = \(Zachary\); = oauth@ietf.org > Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >=20 > Why not have the client app generate a random text string to be used = as a request secret. The random text string would be matched during all = subsequent requests by the client surrounding a particular = authorization. Assuming the endpoints all require TLS for request side = operations it would prevent interception issues and bind the authz code = to a particular client instance even when matching client credentials = are used by an intercepting hacker. >=20 > Would this help to satisfy at least some of the client app instance = identification issues? >=20 > Note: it had also occurred to me that client apps should have static = client_instance identifiers. In practical terms this might be tied to an = IMEI number for example on a smart phone or other static information. = However, I don't think it would solve this security issue since it would = be easy to imitate. The above solution suggests a changing random string = instead. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-04-08, at 12:10 AM, Skylar Woodward wrote: >=20 >> Yes, I can see how this might seem confusing. Actually, we're = authenticating the client with authorization server - not a resource = request. On the MAC threads we discussed how the token can be used for = both. Hopefully that clears everything up, but I'll briefly address = some of the questions inline. >>=20 >> On Apr 7, 2011, at 11:26 PM, Torsten Lodderstedt wrote: >>=20 >>> Hi Skylar, >>>=20 >>> Am 06.04.2011 18:02, schrieb Skylar Woodward: >>>> Well, I should elaborate. The method of authorization is open to = the client, and in this case (Kiva), MAC tokens are being used. The = client authenticates on the access_token request by presenting a MAC = authentication header. Creating the MAC signature requires a secret. In = the native client case, since there is no secret, it signs with the = empty string. So, how would you interpret this mechanism? Are we using = an empty string secret or signing without a secret? In terms of = communicating to the developers, they are told they don't have a secret. = For purposes of signing, they are instructed to sign with them empty = string when they have no secret. >>>=20 >>> You are talking about using the client secret to authenticate = resource server request, correct? This is not in scope of the core spec. = I was talking about authenticating the client with the authorization = server. >>>=20 >>> Apart from that, do you think singing with an empty string adds any = security to your solution? >>=20 >> No. It's about congruence at this point. Also, a MAC token by = definition is signed so it has to be some other assertion if it is not = signed. >>=20 >>> Moreover as far as I understand the MAC-Spec, it recommends to use = authorization server issued secrets to sign the request. So why do you = need a client secret for request signing? >>>=20 >>>> Alternatively, one could use Bearer token for client authentication = in this case where the token is just the client ID. To me this is more = confusing because they must authenticate with different token types for = secret vs. non-secret. Other opinions? >>>=20 >>> I'm confused now, why is the token the client id? A token is used by = the authorization server and may contain (or refer to) any data you need = to authorize access of the client to the resource server. >>=20 >> Right, you're confusing the spec with the use. I'm considering the = case of a simple Bearer assertion in cases of client authentication = where clients have no secret since an ID/password assertion would imply = an empty-string password or secret. As Marius said, we're splitting = hairs at this point. Section 3.1 makes no notes on the possible value = of client_secret for clients w/o secrets, so the assumption was that a = value of "client_secret=3D&..." would be ignored resulting in an invalid = Client Password submission. >>=20 >>>=20 >>>> As to the question of interoperability, the fact that OAuth allows = freedom of choice to the AS for method of authentication makes this = point moot. Would you agree? (short of various providers could pooling = together to standardize on an auth method outside of the spec). >>>=20 >>> What authentication are you refering to? Who do you want to = authenticate? >>=20 >> Client authentication. Section 3.2. >>=20 >>>=20 >>> regards, >>> Torsten. >>>=20 >>>>=20 >>>>=20 >>>> On Apr 4, 2011, at 10:15 PM, torsten@lodderstedt.net wrote: >>>>=20 >>>>> Hi Skylar, >>>>>=20 >>>>> Thank you for sharing this information with us. Some thougts: >>>>>=20 >>>>> The empty string makes your implementation syntactically compliant = but does obviously not comply with its semantics and the security = considerations/expectations associated with a secret. Moreover, what = about interoperability? >>>>>=20 >>>>> I think not using secrets for such clients is the honest solution. = We can just change the spec's text to express what we think is the right = way. >>>>>=20 >>>>> regards, >>>>> Torsten. >>>>> Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland >>>>>=20 >>>>> -----Original Message----- >>>>> From: Skylar Woodward >>>>> Date: Mon, 4 Apr 2011 19:14:53 >>>>> To: Torsten Lodderstedt >>>>> Cc: Zeltsan, Zachary = (Zachary); Kris = Selden; oauth@ietf.org >>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>>>=20 >>>>> In our implementation (not yet public) we accept the empty string = ("") as the value for clients not issued secrets. While this was done to = simplify the interface and implementation, it would make it compliant in = my view. In this case, the authorization server is validating the = credentials, which are the client ID and the empty string, which is = equivalent security-wise to any other length of "secret" issued to a = native client. >>>>>=20 >>>>> Besides, for many providers, the client credentials will only be a = client ID. They would plan to secure all exchanges over TLS and = credentials serve just as a tracking device or at best, a weak form of = identification. >>>>>=20 >>>>> skylar >>>>>=20 >>>>> On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote: >>>>>=20 >>>>>> Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): >>>>>>> According to section "6 Refreshing an Access Token" (-13.txt), = client when making a request for exchanging a refresh token for an = access token has to include its authentication credentials, and the = "authorization server MUST validate the client credentials". >>>>>>> How can this be done if a client is an application that can't = have a client secret? >>>>>>> The authorization code grant does require client authentication = (per section 4.1): >>>>>>>=20 >>>>>>> (D) The client requests an access token from the authorization >>>>>>> server's token endpoint by authenticating using its client >>>>>>> credentials, and includes the authorization code received = in the >>>>>>> previous step. >>>>>>>=20 >>>>>>> It appears that the clients that cannot keep its secret cannot = use (be issued) the refresh tokens. >>>>>> In my opinion, this part of the spec is misleading. Authorization = code MUST be possible without client authentication. Otherwise, OAuth is = useless for native apps. >>>>>>=20 >>>>>> = http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-= 01#section-2.10 describes how the flow can be protected in such cases. >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>>> Zachary >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Marius Scurtescu >>>>>>> Sent: Monday, April 04, 2011 2:30 PM >>>>>>> To: Kris Selden >>>>>>> Cc: oauth@ietf.org >>>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>>>>>=20 >>>>>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris = Selden wrote: >>>>>>>> A typical iPhone app cannot be shipped with a client secret and = rightly or wrongly users expect to only have to enter their credentials = once. >>>>>>>>=20 >>>>>>>> What is the best profile to use for an app that can't have a = client secret and needs a refresh token or a long lived access token? >>>>>>> The authorization code grant, aka web server flow. >>>>>>>=20 >>>>>>> The spec is misleading in this respect IMO. >>>>>>>=20 >>>>>>> Marius >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From skylar@kiva.org Fri Apr 8 11:16:23 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D86F3A69F4 for ; Fri, 8 Apr 2011 11:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18-9P3nnW8gl for ; Fri, 8 Apr 2011 11:16:22 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by core3.amsl.com (Postfix) with SMTP id B02C03A69D6 for ; Fri, 8 Apr 2011 11:16:21 -0700 (PDT) Received: from mail-pz0-f46.google.com ([209.85.210.46]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKTZ9RXjUWJXhwn13+eBd6w2kvFNYC2NDk@postini.com; Fri, 08 Apr 2011 11:18:07 PDT Received: by pzk9 with SMTP id 9so1694634pzk.5 for ; Fri, 08 Apr 2011 11:18:06 -0700 (PDT) Received: by 10.142.224.11 with SMTP id w11mr2086578wfg.136.1302286685930; Fri, 08 Apr 2011 11:18:05 -0700 (PDT) Received: from [10.0.1.9] (c-24-5-80-5.hsd1.ca.comcast.net [24.5.80.5]) by mx.google.com with ESMTPS id x11sm3944953wfd.1.2011.04.08.11.18.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2011 11:18:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Skylar Woodward X-Priority: Normal In-Reply-To: Date: Fri, 8 Apr 2011 11:18:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <072CFC71-0FFE-4A69-8A2D-20D8A734389C@kiva.org> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> <4D9EAAA2.9030809@lodderstedt.net> <17C3457F-22A3-42F9-BA0A-80CEDED9DF70@oracle.com> <859122783-1302280631-cardhu_decombobulator_blackberry.rim.net-1217985074-@b1.c11.bise7.blackberry> To: Phil Hunt X-Mailer: Apple Mail (2.1082) Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 18:16:23 -0000 I can't see the purpose of "generated secret" by the client. I fear this = is going to lead down the same confusing path as the last thread on auth = codes. Essentially what you're asking for is a unique session ID per grant = request. If TLS is required across all connections to protect the = generated secret/ID, then this secret serves no security purpose. The = token (and auth code represented by it during the first leg) serves as = the session ID anyway, so the client-generated secret is redundant. = Additionally you have to deal with the provider rejecting secrets if = they are not unique. Such a secret would provide no identity guarantee beyond the "same = session" guarantee provided the token. Any application can use an = existing client ID, make up a secret, and authenticate. The server knows = nothing more about the identity of the client. Identity and secrets = must be established outside the OAuth handshake - at the same point = where application identity data (icon, name, owner) is managed. On Apr 8, 2011, at 9:49 AM, Phil Hunt wrote: > I am assuming the outbound requests are secured by TLS, but for = various reasons the return path (e.g. the redirect) might not be. Thus, = one restriction would be that the server never returns the code to the = client. >=20 > Thus, you could submit a secret simply for the purpose of verifying = the same specific requestor for each operation. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-04-08, at 9:36 AM, torsten@lodderstedt.net wrote: >=20 >> This would be another possible standard option. As you pointed out, = it would help to detect authz code theft even for native apps. It would = not help wrt client authorization since there are no properties = associated with the new credential. >>=20 >> The key is: how does the authz server get to know this secret? As the = redirects are not fully protected against leaks (history, referers) I = would not pass it in as a parameter to the authz request.=20 >>=20 >> Regards, >> Torsten. >> Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland =20 >>=20 >> -----Original Message----- >> From: Phil Hunt >> Date: Fri, 8 Apr 2011 09:22:18=20 >> To: Skylar Woodward >> Cc: Torsten Lodderstedt; Kris = Selden; Zeltsan, Zachary = \(Zachary\); = oauth@ietf.org >> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>=20 >> Why not have the client app generate a random text string to be used = as a request secret. The random text string would be matched during all = subsequent requests by the client surrounding a particular = authorization. Assuming the endpoints all require TLS for request side = operations it would prevent interception issues and bind the authz code = to a particular client instance even when matching client credentials = are used by an intercepting hacker. >>=20 >> Would this help to satisfy at least some of the client app instance = identification issues? >>=20 >> Note: it had also occurred to me that client apps should have static = client_instance identifiers. In practical terms this might be tied to an = IMEI number for example on a smart phone or other static information. = However, I don't think it would solve this security issue since it would = be easy to imitate. The above solution suggests a changing random string = instead. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-04-08, at 12:10 AM, Skylar Woodward wrote: >>=20 >>> Yes, I can see how this might seem confusing. Actually, we're = authenticating the client with authorization server - not a resource = request. On the MAC threads we discussed how the token can be used for = both. Hopefully that clears everything up, but I'll briefly address = some of the questions inline. >>>=20 >>> On Apr 7, 2011, at 11:26 PM, Torsten Lodderstedt wrote: >>>=20 >>>> Hi Skylar, >>>>=20 >>>> Am 06.04.2011 18:02, schrieb Skylar Woodward: >>>>> Well, I should elaborate. The method of authorization is open to = the client, and in this case (Kiva), MAC tokens are being used. The = client authenticates on the access_token request by presenting a MAC = authentication header. Creating the MAC signature requires a secret. In = the native client case, since there is no secret, it signs with the = empty string. So, how would you interpret this mechanism? Are we using = an empty string secret or signing without a secret? In terms of = communicating to the developers, they are told they don't have a secret. = For purposes of signing, they are instructed to sign with them empty = string when they have no secret. >>>>=20 >>>> You are talking about using the client secret to authenticate = resource server request, correct? This is not in scope of the core spec. = I was talking about authenticating the client with the authorization = server. >>>>=20 >>>> Apart from that, do you think singing with an empty string adds any = security to your solution? >>>=20 >>> No. It's about congruence at this point. Also, a MAC token by = definition is signed so it has to be some other assertion if it is not = signed. >>>=20 >>>> Moreover as far as I understand the MAC-Spec, it recommends to use = authorization server issued secrets to sign the request. So why do you = need a client secret for request signing? >>>>=20 >>>>> Alternatively, one could use Bearer token for client = authentication in this case where the token is just the client ID. To me = this is more confusing because they must authenticate with different = token types for secret vs. non-secret. Other opinions? >>>>=20 >>>> I'm confused now, why is the token the client id? A token is used = by the authorization server and may contain (or refer to) any data you = need to authorize access of the client to the resource server. >>>=20 >>> Right, you're confusing the spec with the use. I'm considering the = case of a simple Bearer assertion in cases of client authentication = where clients have no secret since an ID/password assertion would imply = an empty-string password or secret. As Marius said, we're splitting = hairs at this point. Section 3.1 makes no notes on the possible value = of client_secret for clients w/o secrets, so the assumption was that a = value of "client_secret=3D&..." would be ignored resulting in an invalid = Client Password submission. >>>=20 >>>>=20 >>>>> As to the question of interoperability, the fact that OAuth allows = freedom of choice to the AS for method of authentication makes this = point moot. Would you agree? (short of various providers could pooling = together to standardize on an auth method outside of the spec). >>>>=20 >>>> What authentication are you refering to? Who do you want to = authenticate? >>>=20 >>> Client authentication. Section 3.2. >>>=20 >>>>=20 >>>> regards, >>>> Torsten. >>>>=20 >>>>>=20 >>>>>=20 >>>>> On Apr 4, 2011, at 10:15 PM, torsten@lodderstedt.net wrote: >>>>>=20 >>>>>> Hi Skylar, >>>>>>=20 >>>>>> Thank you for sharing this information with us. Some thougts: >>>>>>=20 >>>>>> The empty string makes your implementation syntactically = compliant but does obviously not comply with its semantics and the = security considerations/expectations associated with a secret. Moreover, = what about interoperability? >>>>>>=20 >>>>>> I think not using secrets for such clients is the honest = solution. We can just change the spec's text to express what we think is = the right way. >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>> Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Skylar Woodward >>>>>> Date: Mon, 4 Apr 2011 19:14:53 >>>>>> To: Torsten Lodderstedt >>>>>> Cc: Zeltsan, Zachary = (Zachary); Kris = Selden; oauth@ietf.org >>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>>>>=20 >>>>>> In our implementation (not yet public) we accept the empty string = ("") as the value for clients not issued secrets. While this was done to = simplify the interface and implementation, it would make it compliant in = my view. In this case, the authorization server is validating the = credentials, which are the client ID and the empty string, which is = equivalent security-wise to any other length of "secret" issued to a = native client. >>>>>>=20 >>>>>> Besides, for many providers, the client credentials will only be = a client ID. They would plan to secure all exchanges over TLS and = credentials serve just as a tracking device or at best, a weak form of = identification. >>>>>>=20 >>>>>> skylar >>>>>>=20 >>>>>> On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote: >>>>>>=20 >>>>>>> Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): >>>>>>>> According to section "6 Refreshing an Access Token" (-13.txt), = client when making a request for exchanging a refresh token for an = access token has to include its authentication credentials, and the = "authorization server MUST validate the client credentials". >>>>>>>> How can this be done if a client is an application that can't = have a client secret? >>>>>>>> The authorization code grant does require client authentication = (per section 4.1): >>>>>>>>=20 >>>>>>>> (D) The client requests an access token from the authorization >>>>>>>> server's token endpoint by authenticating using its client >>>>>>>> credentials, and includes the authorization code received = in the >>>>>>>> previous step. >>>>>>>>=20 >>>>>>>> It appears that the clients that cannot keep its secret cannot = use (be issued) the refresh tokens. >>>>>>> In my opinion, this part of the spec is misleading. = Authorization code MUST be possible without client authentication. = Otherwise, OAuth is useless for native apps. >>>>>>>=20 >>>>>>> = http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-= 01#section-2.10 describes how the flow can be protected in such cases. >>>>>>>=20 >>>>>>> regards, >>>>>>> Torsten. >>>>>>>> Zachary >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Marius Scurtescu >>>>>>>> Sent: Monday, April 04, 2011 2:30 PM >>>>>>>> To: Kris Selden >>>>>>>> Cc: oauth@ietf.org >>>>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>>>>>>=20 >>>>>>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris = Selden wrote: >>>>>>>>> A typical iPhone app cannot be shipped with a client secret = and rightly or wrongly users expect to only have to enter their = credentials once. >>>>>>>>>=20 >>>>>>>>> What is the best profile to use for an app that can't have a = client secret and needs a refresh token or a long lived access token? >>>>>>>> The authorization code grant, aka web server flow. >>>>>>>>=20 >>>>>>>> The spec is misleading in this respect IMO. >>>>>>>>=20 >>>>>>>> Marius >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From skylar@kiva.org Fri Apr 8 11:25:30 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187C03A69E2 for ; Fri, 8 Apr 2011 11:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ddYYl1dQOrP for ; Fri, 8 Apr 2011 11:25:29 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by core3.amsl.com (Postfix) with SMTP id 2A14B3A699C for ; Fri, 8 Apr 2011 11:25:29 -0700 (PDT) Received: from mail-pv0-f180.google.com ([74.125.83.180]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKTZ9TgvBAG/zkHrgqguqHgHJfla8d0mTp@postini.com; Fri, 08 Apr 2011 11:27:15 PDT Received: by pvg2 with SMTP id 2so2294047pvg.11 for ; Fri, 08 Apr 2011 11:27:14 -0700 (PDT) Received: by 10.142.2.3 with SMTP id 3mr2162099wfb.172.1302287233872; Fri, 08 Apr 2011 11:27:13 -0700 (PDT) Received: from [10.0.1.9] (c-24-5-80-5.hsd1.ca.comcast.net [24.5.80.5]) by mx.google.com with ESMTPS id w32sm3950234wfh.7.2011.04.08.11.27.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2011 11:27:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <4D9F3425.1030405@lodderstedt.net> Date: Fri, 8 Apr 2011 11:27:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1E4E0315-235F-4504-A1F8-A76DE9721645@kiva.org> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> <4D9EAAA2.9030809@lodderstedt.net> <4D9F3425.1030405@lodderstedt .net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1082) Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 18:25:30 -0000 Torsten, that's what the spec recommends already. That's my assumption = for everything I've discussed thus far - that clients who can't keep = secrets are never issued them and thus must omit them out of lack of = having any. We're just splitting hairs on the definition of "omit." Also, there's = confusion because not everyone has considered the alternative client = auth methods apart from the 3.1 password mechanism. I feel a more = productive discussion would be to discuss the details of what it means = for a client to "omit" secrets for various auth mechanisms. So - password auth - HTTP MAC auth - HTTP Basic? Additionally if the Password Auth mechanism forbids omission of secrets = (including sending empty string as a secret) then we should suggest an = alternative, or advise that providers must use another self-defined = mechanism for passing unauthenticated client IDs if they wish to require = them for record tracking purposes. skylar On Apr 8, 2011, at 9:13 AM, Torsten Lodderstedt wrote: >=20 >>>> As to the question of interoperability, the fact that OAuth allows = freedom of choice to the AS for method of authentication makes this = point moot. Would you agree? (short of various providers could pooling = together to standardize on an auth method outside of the spec). >=20 > One possible standard for clients without the capability to protect = secrets would be to just omit secrets. Do you agree? > And the spec itself could (should in my opinion) set this standard. >=20 > regards, > Torsten. From phil.hunt@oracle.com Fri Apr 8 11:49:41 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69853A69CC for ; Fri, 8 Apr 2011 11:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp+r5Ftx2ofX for ; Fri, 8 Apr 2011 11:49:40 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 385D53A69B4 for ; Fri, 8 Apr 2011 11:49:40 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p38IpL4X017343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 18:51:23 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p38IpLEm026761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2011 18:51:21 GMT Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p38IpKjG020478; Fri, 8 Apr 2011 13:51:20 -0500 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Apr 2011 11:51:19 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Phil Hunt X-Priority: Normal In-Reply-To: <072CFC71-0FFE-4A69-8A2D-20D8A734389C@kiva.org> Date: Fri, 8 Apr 2011 11:51:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> <4D9EAAA2.9030809@lodderstedt.net> <17C3457F-22A3-42F9-BA0A-80CEDED9DF70@oracle.com> <859122783-1302280631-cardhu_decombobulator_blackberry.rim.net-1217985074-@b1.c11.bise7.blackberry> <072CFC71-0FFE-4A69-8A2D-20D8A734389C@kiva.org> To: Skylar Woodward X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4D9F5929.0237:SCFSTAT5015188,ss=1,fgs=0 Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 18:49:42 -0000 I don't think you are looking at it quite correctly. The token/auth code = is a session asserted by the server. The generated secret is asserted = by the client. This allows the server to detect more faults with the = client or attempts to intercept a particular sequence. I'm not yet convinced it is useful. I brought it up because of the = ongoing issue of trying to uniquely authenticate clients. Phil phil.hunt@oracle.com On 2011-04-08, at 11:18 AM, Skylar Woodward wrote: > I can't see the purpose of "generated secret" by the client. I fear = this is going to lead down the same confusing path as the last thread on = auth codes. >=20 > Essentially what you're asking for is a unique session ID per grant = request. If TLS is required across all connections to protect the = generated secret/ID, then this secret serves no security purpose. The = token (and auth code represented by it during the first leg) serves as = the session ID anyway, so the client-generated secret is redundant. = Additionally you have to deal with the provider rejecting secrets if = they are not unique. >=20 > Such a secret would provide no identity guarantee beyond the "same = session" guarantee provided the token. Any application can use an = existing client ID, make up a secret, and authenticate. The server knows = nothing more about the identity of the client. Identity and secrets = must be established outside the OAuth handshake - at the same point = where application identity data (icon, name, owner) is managed. >=20 >=20 > On Apr 8, 2011, at 9:49 AM, Phil Hunt wrote: >=20 >> I am assuming the outbound requests are secured by TLS, but for = various reasons the return path (e.g. the redirect) might not be. Thus, = one restriction would be that the server never returns the code to the = client. >>=20 >> Thus, you could submit a secret simply for the purpose of verifying = the same specific requestor for each operation. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-04-08, at 9:36 AM, torsten@lodderstedt.net wrote: >>=20 >>> This would be another possible standard option. As you pointed out, = it would help to detect authz code theft even for native apps. It would = not help wrt client authorization since there are no properties = associated with the new credential. >>>=20 >>> The key is: how does the authz server get to know this secret? As = the redirects are not fully protected against leaks (history, referers) = I would not pass it in as a parameter to the authz request.=20 >>>=20 >>> Regards, >>> Torsten. >>> Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland =20 >>>=20 >>> -----Original Message----- >>> From: Phil Hunt >>> Date: Fri, 8 Apr 2011 09:22:18=20 >>> To: Skylar Woodward >>> Cc: Torsten Lodderstedt; Kris = Selden; Zeltsan, Zachary = \(Zachary\); = oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>=20 >>> Why not have the client app generate a random text string to be used = as a request secret. The random text string would be matched during all = subsequent requests by the client surrounding a particular = authorization. Assuming the endpoints all require TLS for request side = operations it would prevent interception issues and bind the authz code = to a particular client instance even when matching client credentials = are used by an intercepting hacker. >>>=20 >>> Would this help to satisfy at least some of the client app instance = identification issues? >>>=20 >>> Note: it had also occurred to me that client apps should have static = client_instance identifiers. In practical terms this might be tied to an = IMEI number for example on a smart phone or other static information. = However, I don't think it would solve this security issue since it would = be easy to imitate. The above solution suggests a changing random string = instead. >>>=20 >>> Phil >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2011-04-08, at 12:10 AM, Skylar Woodward wrote: >>>=20 >>>> Yes, I can see how this might seem confusing. Actually, we're = authenticating the client with authorization server - not a resource = request. On the MAC threads we discussed how the token can be used for = both. Hopefully that clears everything up, but I'll briefly address = some of the questions inline. >>>>=20 >>>> On Apr 7, 2011, at 11:26 PM, Torsten Lodderstedt wrote: >>>>=20 >>>>> Hi Skylar, >>>>>=20 >>>>> Am 06.04.2011 18:02, schrieb Skylar Woodward: >>>>>> Well, I should elaborate. The method of authorization is open to = the client, and in this case (Kiva), MAC tokens are being used. The = client authenticates on the access_token request by presenting a MAC = authentication header. Creating the MAC signature requires a secret. In = the native client case, since there is no secret, it signs with the = empty string. So, how would you interpret this mechanism? Are we using = an empty string secret or signing without a secret? In terms of = communicating to the developers, they are told they don't have a secret. = For purposes of signing, they are instructed to sign with them empty = string when they have no secret. >>>>>=20 >>>>> You are talking about using the client secret to authenticate = resource server request, correct? This is not in scope of the core spec. = I was talking about authenticating the client with the authorization = server. >>>>>=20 >>>>> Apart from that, do you think singing with an empty string adds = any security to your solution? >>>>=20 >>>> No. It's about congruence at this point. Also, a MAC token by = definition is signed so it has to be some other assertion if it is not = signed. >>>>=20 >>>>> Moreover as far as I understand the MAC-Spec, it recommends to use = authorization server issued secrets to sign the request. So why do you = need a client secret for request signing? >>>>>=20 >>>>>> Alternatively, one could use Bearer token for client = authentication in this case where the token is just the client ID. To me = this is more confusing because they must authenticate with different = token types for secret vs. non-secret. Other opinions? >>>>>=20 >>>>> I'm confused now, why is the token the client id? A token is used = by the authorization server and may contain (or refer to) any data you = need to authorize access of the client to the resource server. >>>>=20 >>>> Right, you're confusing the spec with the use. I'm considering the = case of a simple Bearer assertion in cases of client authentication = where clients have no secret since an ID/password assertion would imply = an empty-string password or secret. As Marius said, we're splitting = hairs at this point. Section 3.1 makes no notes on the possible value = of client_secret for clients w/o secrets, so the assumption was that a = value of "client_secret=3D&..." would be ignored resulting in an invalid = Client Password submission. >>>>=20 >>>>>=20 >>>>>> As to the question of interoperability, the fact that OAuth = allows freedom of choice to the AS for method of authentication makes = this point moot. Would you agree? (short of various providers could = pooling together to standardize on an auth method outside of the spec). >>>>>=20 >>>>> What authentication are you refering to? Who do you want to = authenticate? >>>>=20 >>>> Client authentication. Section 3.2. >>>>=20 >>>>>=20 >>>>> regards, >>>>> Torsten. >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Apr 4, 2011, at 10:15 PM, torsten@lodderstedt.net wrote: >>>>>>=20 >>>>>>> Hi Skylar, >>>>>>>=20 >>>>>>> Thank you for sharing this information with us. Some thougts: >>>>>>>=20 >>>>>>> The empty string makes your implementation syntactically = compliant but does obviously not comply with its semantics and the = security considerations/expectations associated with a secret. Moreover, = what about interoperability? >>>>>>>=20 >>>>>>> I think not using secrets for such clients is the honest = solution. We can just change the spec's text to express what we think is = the right way. >>>>>>>=20 >>>>>>> regards, >>>>>>> Torsten. >>>>>>> Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Skylar Woodward >>>>>>> Date: Mon, 4 Apr 2011 19:14:53 >>>>>>> To: Torsten Lodderstedt >>>>>>> Cc: Zeltsan, Zachary = (Zachary); Kris = Selden; oauth@ietf.org >>>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>>>>>=20 >>>>>>> In our implementation (not yet public) we accept the empty = string ("") as the value for clients not issued secrets. While this was = done to simplify the interface and implementation, it would make it = compliant in my view. In this case, the authorization server is = validating the credentials, which are the client ID and the empty = string, which is equivalent security-wise to any other length of = "secret" issued to a native client. >>>>>>>=20 >>>>>>> Besides, for many providers, the client credentials will only be = a client ID. They would plan to secure all exchanges over TLS and = credentials serve just as a tracking device or at best, a weak form of = identification. >>>>>>>=20 >>>>>>> skylar >>>>>>>=20 >>>>>>> On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote: >>>>>>>=20 >>>>>>>> Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): >>>>>>>>> According to section "6 Refreshing an Access Token" (-13.txt), = client when making a request for exchanging a refresh token for an = access token has to include its authentication credentials, and the = "authorization server MUST validate the client credentials". >>>>>>>>> How can this be done if a client is an application that can't = have a client secret? >>>>>>>>> The authorization code grant does require client = authentication (per section 4.1): >>>>>>>>>=20 >>>>>>>>> (D) The client requests an access token from the = authorization >>>>>>>>> server's token endpoint by authenticating using its client >>>>>>>>> credentials, and includes the authorization code received = in the >>>>>>>>> previous step. >>>>>>>>>=20 >>>>>>>>> It appears that the clients that cannot keep its secret cannot = use (be issued) the refresh tokens. >>>>>>>> In my opinion, this part of the spec is misleading. = Authorization code MUST be possible without client authentication. = Otherwise, OAuth is useless for native apps. >>>>>>>>=20 >>>>>>>> = http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-= 01#section-2.10 describes how the flow can be protected in such cases. >>>>>>>>=20 >>>>>>>> regards, >>>>>>>> Torsten. >>>>>>>>> Zachary >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = On Behalf Of Marius Scurtescu >>>>>>>>> Sent: Monday, April 04, 2011 2:30 PM >>>>>>>>> To: Kris Selden >>>>>>>>> Cc: oauth@ietf.org >>>>>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>>>>>>>=20 >>>>>>>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris = Selden wrote: >>>>>>>>>> A typical iPhone app cannot be shipped with a client secret = and rightly or wrongly users expect to only have to enter their = credentials once. >>>>>>>>>>=20 >>>>>>>>>> What is the best profile to use for an app that can't have a = client secret and needs a refresh token or a long lived access token? >>>>>>>>> The authorization code grant, aka web server flow. >>>>>>>>>=20 >>>>>>>>> The spec is misleading in this respect IMO. >>>>>>>>>=20 >>>>>>>>> Marius >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> _______________________________________________ >>>>>>>> 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 From eran@hueniverse.com Fri Apr 8 20:54:41 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72F13A6A32 for ; Fri, 8 Apr 2011 20:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGOC8Y8AjSGD for ; Fri, 8 Apr 2011 20:54:36 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id CB55D3A6978 for ; Fri, 8 Apr 2011 20:54:35 -0700 (PDT) Received: (qmail 12140 invoked from network); 9 Apr 2011 03:56:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Apr 2011 03:56:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 8 Apr 2011 20:56:20 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , OAuth WG Date: Fri, 8 Apr 2011 20:56:09 -0700 Thread-Topic: OAuth2 scheme Thread-Index: Acv0szxJR54h3FRORpezZ9L8nUeh+gAxRy2gAAXVW8AACmyNEAAsFdmQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664E5CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465664E11D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281CAB8DB@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E3B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281D308B0@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11281D308B0@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234465664E5CDP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth2 scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 03:54:41 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E5CDP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks James. I think overall your proposal is a good direction. I think the combination = of Link and WWW-Authenticate headers (static/dynamic) discovery is interest= ing. If you have the time, I would love to see an I-D defining the OAuth2 authen= tication scheme (partial as you defined it) with clear usage and processing= rules for using it with other HTTP schemes. While this is clearly not with= in our scope, progressing such a draft now on the side makes a lot of sense= to me. EHL From: Manger, James H [mailto:James.H.Manger@team.telstra.com] Sent: Friday, April 08, 2011 12:17 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: OAuth2 scheme [Sorry, I didn't see this email before I sent my last one] > Chairs - I would like to ask that you declare all discovery requirements = and use cases out of scope for v2 and the working group at this point. > > --- > > As for the error code registry and the request Mike posted, I do not thin= k your use case has much to do with the goal Mike has with his registry pro= posal. Mike's proposal is for v2 to define an error registry for use with a= n error attribute across different HTTP schemes such as Bearer and MAC, and= for that to make sense, we need to define an OAuth2 scheme that *replaces*= the Bearer and MAC schemes - something you agree we should not do. An error code is part of discovery - it lets a client app "discover" what i= t needs to do next to gain access. We can have separate discovery of fairly static server capabilities and end= points and call that out of scope for v2. However, we still need dynamic discovery of which OAuth2 flow a client shou= ld do after a particular HTTP resource request fails. This is related to er= ror codes so needs to be as in-scope as error codes are. Indicating which O= Auth2 flow to perform should be OAuth2-specific, not kludged onto every (in= dependent) authentication scheme. P.S. I still absolutely agree that we should NOT define one OAuth2 scheme t= hat replaces Bearer and MAC. -- James Manger --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E5CDP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks James.

 

<= span style=3D'color:#1F497D'>I think overall your proposal is a good direct= ion. I think the combination of Link and WWW-Authenticate headers (static/d= ynamic) discovery is interesting.

 

If you have the time, I would love to se= e an I-D defining the OAuth2 authentication scheme (partial as you defined = it) with clear usage and processing rules for using it with other HTTP sche= mes. While this is clearly not within our scope, progressing such a draft n= ow on the side makes a lot of sense to me.

 

EHL

 

From: Manger, James H [mailto:James.H= .Manger@team.telstra.com]
Sent: Friday, April 08, 2011 12:17 AM<= br>To: Eran Hammer-Lahav; OAuth WG
Subject: RE: OAuth2 sch= eme

 =

[Sorry,= I didn’t see this email before I sent my last one]=

&n= bsp;

>= ; Chairs – I would like to ask that you declare all discovery require= ments and use cases out of scope for v2 and the working group at this point= .

&= gt; 

> ---

> 

> As for the error code registry and the request Mi= ke posted, I do not think your use case has much to do with the goal Mike h= as with his registry proposal. Mike’s proposal is for v2 to define an= error registry for use with an error attribute across different HTTP schem= es such as Bearer and MAC, and for that to make sense, we need to define an= OAuth2 scheme that *replaces* the Bearer and MAC schemes – so= mething you agree we should not do.

 

 

An error code is part of discove= ry – it lets a client app “discover” what it needs to do = next to gain access.

 

We can have separate discovery of fairly static serv= er capabilities and endpoints and call that out of scope for v2.=

However, we s= till need dynamic discovery of which OAuth2 flow a client should do after a= particular HTTP resource request fails. This is related to error codes so = needs to be as in-scope as error codes are. Indicating which OAuth2 flow to= perform should be OAuth2-specific, not kludged onto every (independent) au= thentication scheme.

 

P.S. I still absolutely agree that we should NOT def= ine one OAuth2 scheme that replaces Bearer and MAC.

 

--

James Manger

= --_000_90C41DD21FB7C64BB94121FBBC2E7234465664E5CDP3PW5EX1MB01E_-- From jricher@mitre.org Mon Apr 11 08:17:25 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56D0D28C128 for ; Mon, 11 Apr 2011 08:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.108 X-Spam-Level: X-Spam-Status: No, score=-5.108 tagged_above=-999 required=5 tests=[AWL=1.491, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsD1P4aD93FG for ; Mon, 11 Apr 2011 08:17:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id E9DD83A6889 for ; Mon, 11 Apr 2011 08:17:23 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0482521B1C10; Mon, 11 Apr 2011 11:17:24 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id F240821B1C07; Mon, 11 Apr 2011 11:17:23 -0400 (EDT) Received: from [129.83.50.23] (129.83.50.23) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Mon, 11 Apr 2011 11:17:23 -0400 From: Justin Richer To: Phil Hunt In-Reply-To: <17C3457F-22A3-42F9-BA0A-80CEDED9DF70@oracle.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net> <38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> <4D9EAAA2.9030809@lodderstedt.net> <17C3457F-22A3-42F9-BA0A-80CEDED9DF70@oracle.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 11 Apr 2011 11:19:03 -0400 Message-ID: <1302535143.7193.39.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 15:17:25 -0000 While this isn't the original use case I had in mind, this could be covered by something in the OAuth2 Instance extension: http://tools.ietf.org/html/draft-richer-oauth-instance-00 -- Justin On Fri, 2011-04-08 at 12:22 -0400, Phil Hunt wrote: > Why not have the client app generate a random text string to be used as a request secret. The random text string would be matched during all subsequent requests by the client surrounding a particular authorization. Assuming the endpoints all require TLS for request side operations it would prevent interception issues and bind the authz code to a particular client instance even when matching client credentials are used by an intercepting hacker. > > Would this help to satisfy at least some of the client app instance identification issues? > > Note: it had also occurred to me that client apps should have static client_instance identifiers. In practical terms this might be tied to an IMEI number for example on a smart phone or other static information. However, I don't think it would solve this security issue since it would be easy to imitate. The above solution suggests a changing random string instead. > > Phil > phil.hunt@oracle.com > > > > > On 2011-04-08, at 12:10 AM, Skylar Woodward wrote: > > > Yes, I can see how this might seem confusing. Actually, we're authenticating the client with authorization server - not a resource request. On the MAC threads we discussed how the token can be used for both. Hopefully that clears everything up, but I'll briefly address some of the questions inline. > > > > On Apr 7, 2011, at 11:26 PM, Torsten Lodderstedt wrote: > > > >> Hi Skylar, > >> > >> Am 06.04.2011 18:02, schrieb Skylar Woodward: > >>> Well, I should elaborate. The method of authorization is open to the client, and in this case (Kiva), MAC tokens are being used. The client authenticates on the access_token request by presenting a MAC authentication header. Creating the MAC signature requires a secret. In the native client case, since there is no secret, it signs with the empty string. So, how would you interpret this mechanism? Are we using an empty string secret or signing without a secret? In terms of communicating to the developers, they are told they don't have a secret. For purposes of signing, they are instructed to sign with them empty string when they have no secret. > >> > >> You are talking about using the client secret to authenticate resource server request, correct? This is not in scope of the core spec. I was talking about authenticating the client with the authorization server. > >> > >> Apart from that, do you think singing with an empty string adds any security to your solution? > > > > No. It's about congruence at this point. Also, a MAC token by definition is signed so it has to be some other assertion if it is not signed. > > > >> Moreover as far as I understand the MAC-Spec, it recommends to use authorization server issued secrets to sign the request. So why do you need a client secret for request signing? > >> > >>> Alternatively, one could use Bearer token for client authentication in this case where the token is just the client ID. To me this is more confusing because they must authenticate with different token types for secret vs. non-secret. Other opinions? > >> > >> I'm confused now, why is the token the client id? A token is used by the authorization server and may contain (or refer to) any data you need to authorize access of the client to the resource server. > > > > Right, you're confusing the spec with the use. I'm considering the case of a simple Bearer assertion in cases of client authentication where clients have no secret since an ID/password assertion would imply an empty-string password or secret. As Marius said, we're splitting hairs at this point. Section 3.1 makes no notes on the possible value of client_secret for clients w/o secrets, so the assumption was that a value of "client_secret=&..." would be ignored resulting in an invalid Client Password submission. > > > >> > >>> As to the question of interoperability, the fact that OAuth allows freedom of choice to the AS for method of authentication makes this point moot. Would you agree? (short of various providers could pooling together to standardize on an auth method outside of the spec). > >> > >> What authentication are you refering to? Who do you want to authenticate? > > > > Client authentication. Section 3.2. > > > >> > >> regards, > >> Torsten. > >> > >>> > >>> > >>> On Apr 4, 2011, at 10:15 PM, torsten@lodderstedt.net wrote: > >>> > >>>> Hi Skylar, > >>>> > >>>> Thank you for sharing this information with us. Some thougts: > >>>> > >>>> The empty string makes your implementation syntactically compliant but does obviously not comply with its semantics and the security considerations/expectations associated with a secret. Moreover, what about interoperability? > >>>> > >>>> I think not using secrets for such clients is the honest solution. We can just change the spec's text to express what we think is the right way. > >>>> > >>>> regards, > >>>> Torsten. > >>>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland > >>>> > >>>> -----Original Message----- > >>>> From: Skylar Woodward > >>>> Date: Mon, 4 Apr 2011 19:14:53 > >>>> To: Torsten Lodderstedt > >>>> Cc: Zeltsan, Zachary (Zachary); Kris Selden; oauth@ietf.org > >>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth > >>>> > >>>> In our implementation (not yet public) we accept the empty string ("") as the value for clients not issued secrets. While this was done to simplify the interface and implementation, it would make it compliant in my view. In this case, the authorization server is validating the credentials, which are the client ID and the empty string, which is equivalent security-wise to any other length of "secret" issued to a native client. > >>>> > >>>> Besides, for many providers, the client credentials will only be a client ID. They would plan to secure all exchanges over TLS and credentials serve just as a tracking device or at best, a weak form of identification. > >>>> > >>>> skylar > >>>> > >>>> On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote: > >>>> > >>>>> Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): > >>>>>> According to section "6 Refreshing an Access Token" (-13.txt), client when making a request for exchanging a refresh token for an access token has to include its authentication credentials, and the "authorization server MUST validate the client credentials". > >>>>>> How can this be done if a client is an application that can't have a client secret? > >>>>>> The authorization code grant does require client authentication (per section 4.1): > >>>>>> > >>>>>> (D) The client requests an access token from the authorization > >>>>>> server's token endpoint by authenticating using its client > >>>>>> credentials, and includes the authorization code received in the > >>>>>> previous step. > >>>>>> > >>>>>> It appears that the clients that cannot keep its secret cannot use (be issued) the refresh tokens. > >>>>> In my opinion, this part of the spec is misleading. Authorization code MUST be possible without client authentication. Otherwise, OAuth is useless for native apps. > >>>>> > >>>>> http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-01#section-2.10 describes how the flow can be protected in such cases. > >>>>> > >>>>> regards, > >>>>> Torsten. > >>>>>> Zachary > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Marius Scurtescu > >>>>>> Sent: Monday, April 04, 2011 2:30 PM > >>>>>> To: Kris Selden > >>>>>> Cc: oauth@ietf.org > >>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth > >>>>>> > >>>>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wrote: > >>>>>>> A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once. > >>>>>>> > >>>>>>> What is the best profile to use for an app that can't have a client secret and needs a refresh token or a long lived access token? > >>>>>> The authorization code grant, aka web server flow. > >>>>>> > >>>>>> The spec is misleading in this respect IMO. > >>>>>> > >>>>>> Marius > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> _______________________________________________ > >>>>> OAuth mailing 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 phil.hunt@oracle.com Mon Apr 11 08:37:54 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3738128C12B for ; Mon, 11 Apr 2011 08:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.829 X-Spam-Level: X-Spam-Status: No, score=-5.829 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8iJ-1dlIcZu for ; Mon, 11 Apr 2011 08:37:51 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 4E0923A697E for ; Mon, 11 Apr 2011 08:37:51 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p3BFbiED004921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Apr 2011 15:37:45 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p3BFbhkk026174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Apr 2011 15:37:43 GMT Received: from abhmt021.oracle.com (abhmt021.oracle.com [141.146.116.30]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p3BFbh5c024422; Mon, 11 Apr 2011 10:37:43 -0500 Received: from [192.168.1.71] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Apr 2011 08:37:41 -0700 References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net> <38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> <4D9EAAA2.9030809@lodderstedt.net> <17C3457F-22A3-42F9-BA0A-80CEDED9DF70@oracle.com> <1302535143.7193.39.camel@ground> In-Reply-To: <1302535143.7193.39.camel@ground> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Type: text/plain; charset=utf-8 Message-Id: <06B09B3A-7831-49D8-96CA-368B74E84974@oracle.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8G4) From: Phillip Hunt Date: Mon, 11 Apr 2011 08:37:38 -0700 To: Justin Richer X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4DA32048.007B:SCFSTAT5015188,ss=1,fgs=0 Cc: Kris Selden , "Zeltsan, Zachary \(Zachary\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 15:37:54 -0000 Will take a look.=20 Phil Sent from my phone.=20 On 2011-04-11, at 8:19, Justin Richer wrote: > While this isn't the original use case I had in mind, this could be > covered by something in the OAuth2 Instance extension: >=20 > http://tools.ietf.org/html/draft-richer-oauth-instance-00 >=20 > -- Justin >=20 > On Fri, 2011-04-08 at 12:22 -0400, Phil Hunt wrote: >> Why not have the client app generate a random text string to be used as a= request secret. The random text string would be matched during all subsequ= ent requests by the client surrounding a particular authorization. Assuming= the endpoints all require TLS for request side operations it would prevent i= nterception issues and bind the authz code to a particular client instance e= ven when matching client credentials are used by an intercepting hacker. >>=20 >> Would this help to satisfy at least some of the client app instance ident= ification issues? >>=20 >> Note: it had also occurred to me that client apps should have static clie= nt_instance identifiers. In practical terms this might be tied to an IMEI nu= mber for example on a smart phone or other static information. However, I do= n't think it would solve this security issue since it would be easy to imita= te. The above solution suggests a changing random string instead. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-04-08, at 12:10 AM, Skylar Woodward wrote: >>=20 >>> Yes, I can see how this might seem confusing. Actually, we're authentica= ting the client with authorization server - not a resource request. On the M= AC threads we discussed how the token can be used for both. Hopefully that c= lears everything up, but I'll briefly address some of the questions inline. >>>=20 >>> On Apr 7, 2011, at 11:26 PM, Torsten Lodderstedt wrote: >>>=20 >>>> Hi Skylar, >>>>=20 >>>> Am 06.04.2011 18:02, schrieb Skylar Woodward: >>>>> Well, I should elaborate. The method of authorization is open to the c= lient, and in this case (Kiva), MAC tokens are being used. The client authen= ticates on the access_token request by presenting a MAC authentication heade= r. Creating the MAC signature requires a secret. In the native client case, s= ince there is no secret, it signs with the empty string. So, how would you i= nterpret this mechanism? Are we using an empty string secret or signing with= out a secret? In terms of communicating to the developers, they are told the= y don't have a secret. For purposes of signing, they are instructed to sign w= ith them empty string when they have no secret. >>>>=20 >>>> You are talking about using the client secret to authenticate resource s= erver request, correct? This is not in scope of the core spec. I was talking= about authenticating the client with the authorization server. >>>>=20 >>>> Apart from that, do you think singing with an empty string adds any sec= urity to your solution? >>>=20 >>> No. It's about congruence at this point. Also, a MAC token by definition= is signed so it has to be some other assertion if it is not signed. >>>=20 >>>> Moreover as far as I understand the MAC-Spec, it recommends to use auth= orization server issued secrets to sign the request. So why do you need a cl= ient secret for request signing? >>>>=20 >>>>> Alternatively, one could use Bearer token for client authentication in= this case where the token is just the client ID. To me this is more confusi= ng because they must authenticate with different token types for secret vs. n= on-secret. Other opinions? >>>>=20 >>>> I'm confused now, why is the token the client id? A token is used by th= e authorization server and may contain (or refer to) any data you need to au= thorize access of the client to the resource server. >>>=20 >>> Right, you're confusing the spec with the use. I'm considering the case o= f a simple Bearer assertion in cases of client authentication where clients h= ave no secret since an ID/password assertion would imply an empty-string pas= sword or secret. As Marius said, we're splitting hairs at this point. Secti= on 3.1 makes no notes on the possible value of client_secret for clients w/o= secrets, so the assumption was that a value of "client_secret=3D&..." would= be ignored resulting in an invalid Client Password submission. >>>=20 >>>>=20 >>>>> As to the question of interoperability, the fact that OAuth allows fre= edom of choice to the AS for method of authentication makes this point moot.= Would you agree? (short of various providers could pooling together to stan= dardize on an auth method outside of the spec). >>>>=20 >>>> What authentication are you refering to? Who do you want to authenticat= e? >>>=20 >>> Client authentication. Section 3.2. >>>=20 >>>>=20 >>>> regards, >>>> Torsten. >>>>=20 >>>>>=20 >>>>>=20 >>>>> On Apr 4, 2011, at 10:15 PM, torsten@lodderstedt.net wrote: >>>>>=20 >>>>>> Hi Skylar, >>>>>>=20 >>>>>> Thank you for sharing this information with us. Some thougts: >>>>>>=20 >>>>>> The empty string makes your implementation syntactically compliant bu= t does obviously not comply with its semantics and the security consideratio= ns/expectations associated with a secret. Moreover, what about interoperabil= ity? >>>>>>=20 >>>>>> I think not using secrets for such clients is the honest solution. We= can just change the spec's text to express what we think is the right way. >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>> Gesendet mit BlackBerry=C2=AE Webmail von Telekom Deutschland >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Skylar Woodward >>>>>> Date: Mon, 4 Apr 2011 19:14:53 >>>>>> To: Torsten Lodderstedt >>>>>> Cc: Zeltsan, Zachary (Zachary); K= ris Selden; oauth@ietf.org >>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>>>>=20 >>>>>> In our implementation (not yet public) we accept the empty string (""= ) as the value for clients not issued secrets. While this was done to simpli= fy the interface and implementation, it would make it compliant in my view. = In this case, the authorization server is validating the credentials, which= are the client ID and the empty string, which is equivalent security-wise t= o any other length of "secret" issued to a native client. >>>>>>=20 >>>>>> Besides, for many providers, the client credentials will only be a cl= ient ID. They would plan to secure all exchanges over TLS and credentials se= rve just as a tracking device or at best, a weak form of identification. >>>>>>=20 >>>>>> skylar >>>>>>=20 >>>>>> On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote: >>>>>>=20 >>>>>>> Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): >>>>>>>> According to section "6 Refreshing an Access Token" (-13.txt), clie= nt when making a request for exchanging a refresh token for an access token h= as to include its authentication credentials, and the "authorization server M= UST validate the client credentials". >>>>>>>> How can this be done if a client is an application that can't have a= client secret? >>>>>>>> The authorization code grant does require client authentication (pe= r section 4.1): >>>>>>>>=20 >>>>>>>> (D) The client requests an access token from the authorization >>>>>>>> server's token endpoint by authenticating using its client >>>>>>>> credentials, and includes the authorization code received in t= he >>>>>>>> previous step. >>>>>>>>=20 >>>>>>>> It appears that the clients that cannot keep its secret cannot use (= be issued) the refresh tokens. >>>>>>> In my opinion, this part of the spec is misleading. Authorization co= de MUST be possible without client authentication. Otherwise, OAuth is usele= ss for native apps. >>>>>>>=20 >>>>>>> http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsidera= tions-01#section-2.10 describes how the flow can be protected in such cases.= >>>>>>>=20 >>>>>>> regards, >>>>>>> Torsten. >>>>>>>> Zachary >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beh= alf Of Marius Scurtescu >>>>>>>> Sent: Monday, April 04, 2011 2:30 PM >>>>>>>> To: Kris Selden >>>>>>>> Cc: oauth@ietf.org >>>>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>>>>>>=20 >>>>>>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden= wrote: >>>>>>>>> A typical iPhone app cannot be shipped with a client secret and ri= ghtly or wrongly users expect to only have to enter their credentials once. >>>>>>>>>=20 >>>>>>>>> What is the best profile to use for an app that can't have a clien= t secret and needs a refresh token or a long lived access token? >>>>>>>> The authorization code grant, aka web server flow. >>>>>>>>=20 >>>>>>>> The spec is misleading in this respect IMO. >>>>>>>>=20 >>>>>>>> Marius >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 From eran@hueniverse.com Mon Apr 11 16:16:07 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 31404E06E1 for ; Mon, 11 Apr 2011 16:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQYoPoCuU145 for ; Mon, 11 Apr 2011 16:16:05 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 6BDADE066A for ; Mon, 11 Apr 2011 16:16:00 -0700 (PDT) Received: (qmail 6031 invoked from network); 11 Apr 2011 23:15:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Apr 2011 23:15:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 11 Apr 2011 16:15:50 -0700 From: Eran Hammer-Lahav To: Skylar Woodward , OAuth WG Date: Mon, 11 Apr 2011 16:15:46 -0700 Thread-Topic: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 Thread-Index: AcvG6+zzWEcHzevzR2iwFVcy1BpGKgxsloiw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72344656743AB2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@kiva.org> In-Reply-To: <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@kiva.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 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, 11 Apr 2011 23:16:07 -0000 > -----Original Message----- > From: Skylar Woodward [mailto:skylar@kiva.org] > Sent: Monday, February 07, 2011 9:25 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 >=20 > On body-hash... >=20 > Having completed a trial implementation, it seems redundant, and > potentially problematic, to include the body-hash in the Authentication > header. The danger is that implementors may neglect to recalculate the ha= sh > themselves, reusing the value (even if incorrect) provided by the client.= Why > not just require the provider to calculate this and validate it by compar= ing the > final signature? This way it's clearer for everyone what the expectations= are > in validating the signature. I actually like this "feature". If the server doesn't care about body integ= rity for whatever reason (based on its security analysis), it van still val= idate the request without bothering to validate the body hash. EHL From eran@hueniverse.com Mon Apr 11 16:22:15 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 946CBE06B2 for ; Mon, 11 Apr 2011 16:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCae9X-GaLVt for ; Mon, 11 Apr 2011 16:22:15 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id D4359E0692 for ; Mon, 11 Apr 2011 16:22:14 -0700 (PDT) Received: (qmail 12237 invoked from network); 11 Apr 2011 23:22:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Apr 2011 23:22:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 11 Apr 2011 16:21:34 -0700 From: Eran Hammer-Lahav To: Peter Wolanin Date: Mon, 11 Apr 2011 16:21:31 -0700 Thread-Topic: OAuth v2 Mac token spec Thread-Index: AcvWjuN9zu3GRGtgRiWa8wd/BtlAuAiEBhLg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72344656743AB6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth v2 Mac token spec 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, 11 Apr 2011 23:22:15 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGV0ZXIgV29sYW5pbiBb bWFpbHRvOnBldGVyLndvbGFuaW5AYWNxdWlhLmNvbV0NCj4gU2VudDogU3VuZGF5LCBGZWJydWFy eSAyNywgMjAxMSA2OjU5IEFNDQoNCj4gSSB3YXMgYSBsaXR0bGUgdW5jbGVhciBpbiB0aGUgc3Bl YyB3aGV0aGVyIHRoZSBjbGllbnQgY2FuIGNob29zZSBub3QgdG8gaW5jbHVkZQ0KPiB0aGUgYm9k eSBoYXNoIGluIHRoZSBzaWduYXR1cmUuICBJJ2QgaG9wZSB0aGF0IHRoZSBzcGVjIGVuZHMgdXAg Y2xlYXJseQ0KPiByZXF1aXJpbmcgdGhlIGNsaWVudCB0byBhbHdheXMgc2VuZCBpdCBldmVuIGlm IGEgZ2l2ZW4gc2VydmVyIG1heSBvciBtYXkgbm90DQo+IHZhbGlkYXRlIHRoZSBib2R5IGhhc2gu ICBPdXIgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgaW5jbHVkZSB0aGUgYm9keQ0KPiBkaXJlY3Rs eSBpbiB0aGUgSE1BQyBjYWxjdWxhdGlvbiwgYnV0IGNvbnNpZGVyaW5nIHlvdXIgY3VycmVudCBk cmFmdCBJDQo+IGFwcHJlY2lhdGUgdGhlIGV4dHJhIGZsZXhpYmlsaXR5IHByb3ZpZGVkIGJ5IHNp Z25pbmcgb3ZlciB0aGUgYm9keSBoYXNoIHJhdGhlcg0KPiB0aGFuIHRoZSBib2R5IGl0c2VsZi4N Cg0KWWVzLCB3ZSBuZWVkIHRvIGZpZ3VyZSBvdXQgd2hlbiB0aGUgY2xpZW50IGlzIHJlcXVpcmVk IHRvIGluY2x1ZGUgaXQuIFRoZSBpc3N1ZSBpcyB0aGF0IGluIHNvbWUgZGVwbG95bWVudHMsIGl0 IGlzIG5vdCBwb3NzaWJsZSBmb3IgdGhlIGNsaWVudCB0byBjYWxjdWxhdGUgdGhpcyB2YWx1ZSBh dCB0aGUgcG9pbnQgd2hlcmUgdGhlIGhlYWRlciBpcyBzZXQuDQogDQo+IEEgZG93bnNpZGUgdG8g dGhlIE1BQyBzcGVjIGZvciBPQXV0aDIgaXMsIGFzIGZhciBhcyBJIGNhbiBzZWUsIHlvdSBoYXZl IHRvDQo+IHNlbmQgeW91ciBjbGllbnQgc2VjcmV0IGluIHRoZSByZXF1ZXN0IGlmIHlvdSBldmVy IG5lZWQgdG8gcmVmcmVzaCB5b3VyIE9BdXRoDQo+IHRva2VuPyAgSSBzZWUgaW4gc29tZSByZWNl bnQgbWVzc2FnZXMgbGllayBodHRwOi8vd3d3LmlldGYub3JnL21haWwtDQo+IGFyY2hpdmUvd2Vi L29hdXRoL2N1cnJlbnQvbXNnMDUyMTQuaHRtbMKgIHNvbWUgZGlzY3Vzc2lvbiB0aGF0IHN1Z2dl c3RzDQo+IEknbSBtaXN0YWtlbj8NCg0KTm9wZS4gUmVmcmVzaCBkb2VzIG5vdCByZXF1aXJlIHRo ZSBhY2Nlc3MgdG9rZW4gb3IgaXRzIHNlY3JldC4gSnVzdCB0aGUgcmVmcmVzaCBjb2RlLg0KIA0K PiBBbHNvLCBhcyBzdGF0ZWQgaW4gc2VjdGlvbiA3LjMsIHRoZXJlIHNlZW1zIHRvIGJlIG5vIHBy b3Zpc2lvbiBmb3IgZW5zdXJpbmcNCj4gcmVzcG9uc2UgYXV0aGVudGljaXR5IGV4Y2VwdCByZWx5 aW5nIG9uIFNTTC4gV2UgaGF2ZSBiZWVuIHVzaW5nIHByb3RvY29scw0KPiB0aGF0IGluY2x1ZGUg aW4gdGhlIHJlc3BvbnNlIGFuIEhNQUMgb2YgdGhlIHJlc3BvbnNlIGJvZHkgY2FsY3VsYXRlZCB0 bw0KPiBpbmNsdWRlIHRoZSBjbGllbnQtc3VwcGxpZWQgbm9uY2UuICBPYnZpb3VzbHkgb25lIGNv dWxkIGFkZCBzdWNoIGEgcmVzcG9uc2UNCj4gaGVhZGVyIHdpdGhvdXQgYnJlYWtpbmcgdGhlIHBy b3RvY29sLCBidXQgSSdkIGxpa2UgdG8gc2VlIGFuIG9wdGlvbiBpbiB0aGUNCj4gTUFDIGNyZWRl bnRpYWxzIGFuIGFkZGVkIGZpZWxkIHRoYXQgc3BlY2lmaWVzIHdoZXRoZXIgdGhlIHNlcnZlciBp cyBleHBlY3RlZA0KPiB0byBwcm92aWRlIHN1Y2ggYSByZXNwb25zZSBITUFDIGFuZCBhIHN0YW5k YXJkaXplZCBuYW1lIGFuZCBjb25zdHJ1Y3Rpb24NCj4gZm9yIHN1Y2ggYSByZXNwb25zZSBoZWFk ZXIuDQoNCkkgd2lsbCBhZGQgdGhpcyBsYXRlciwgb25jZSB0aGUgY3VycmVudCBiaXRzIGFyZSBz dGFibGUuDQoNCkVITA0K From James.H.Manger@team.telstra.com Mon Apr 11 23:00:37 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 47500E072D for ; Mon, 11 Apr 2011 23:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZUtj7PYirFB for ; Mon, 11 Apr 2011 23:00:36 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfc.amsl.com (Postfix) with ESMTP id 2E7DFE0734 for ; Mon, 11 Apr 2011 23:00:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,194,1301839200"; d="scan'208,217";a="30238133" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 12 Apr 2011 16:00:33 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6313"; a="23628199" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcbni.tcif.telstra.com.au with ESMTP; 12 Apr 2011 16:00:32 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Tue, 12 Apr 2011 16:00:32 +1000 From: "Manger, James H" To: Eran Hammer-Lahav , OAuth WG Date: Tue, 12 Apr 2011 16:00:31 +1000 Thread-Topic: OAuth2 scheme Thread-Index: Acv0szxJR54h3FRORpezZ9L8nUeh+gAxRy2gAAXVW8AACmyNEAAsFdmQAJsr1xA= Message-ID: <255B9BB34FB7D647A506DC292726F6E11281ECAC0B@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465664E11D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281CAB8DB@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E3B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281D308B0@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E5CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664E5CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11281ECAC0BWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth2 scheme 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, 12 Apr 2011 06:00:37 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11281ECAC0BWSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will have a go writing an I-D defining an OAuth2 WWW-Auth response header= ... though it will not be for at least a fortnight :-( -- James Manger From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Saturday, 9 April 2011 1:56 PM To: Manger, James H; OAuth WG Subject: RE: OAuth2 scheme Thanks James. I think overall your proposal is a good direction. I think the combination = of Link and WWW-Authenticate headers (static/dynamic) discovery is interest= ing. If you have the time, I would love to see an I-D defining the OAuth2 authen= tication scheme (partial as you defined it) with clear usage and processing= rules for using it with other HTTP schemes. While this is clearly not with= in our scope, progressing such a draft now on the side makes a lot of sense= to me. EHL --_000_255B9BB34FB7D647A506DC292726F6E11281ECAC0BWSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I will have a go writi= ng an I-D defining an OAuth2 WWW-Auth response header… though it will= not be for at least a fortnight :-(

 

--

James Manger

 

From: Eran Hammer-Lahav [= mailto:eran@hueniverse.com]
Sent: Saturday, 9 April 2011 1:56 PM
To: Manger, James H; OAuth WG
Subject: RE: OAuth2 scheme

 

Thanks = James.

&n= bsp;

I think= overall your proposal is a good direction. I think the combination of Link= and WWW-Authenticate headers (static/dynamic) discovery is interesting.

&n= bsp;

If you = have the time, I would love to see an I-D defining the OAuth2 authenticatio= n scheme (partial as you defined it) with clear usage and processing rules = for using it with other HTTP schemes. While this is clearly not within our scope, progressing such a draft now o= n the side makes a lot of sense to me.

&n= bsp;

EHL

--_000_255B9BB34FB7D647A506DC292726F6E11281ECAC0BWSMSG3153Vsrv_-- From andrewarnott@gmail.com Tue Apr 12 07:27:43 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 29C1DE07DB for ; Tue, 12 Apr 2011 07:27:43 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXMssaqyV+4h for ; Tue, 12 Apr 2011 07:27:41 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfc.amsl.com (Postfix) with ESMTP id D8BFCE07D9 for ; Tue, 12 Apr 2011 07:27:41 -0700 (PDT) Received: by qwc23 with SMTP id 23so4795291qwc.31 for ; Tue, 12 Apr 2011 07:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=h029zA9exXImkIRvpoF8CXH5J5m9YyZGivTZNrXY21I=; b=kjZ0IAHoLinr2enTq2S5q5d80PyydHO0ZxRp90/WFfaOxeA18J7XrUuU0PLZIRGIrE mYzG8URAvjCeOs7IOPUP/oHiie2stwoHnorbouGS2yjtaGXIjvy74NLBHf0fn2hY85Cv npwFt94mWJicKvTFZD66la/5FpqWQmP1/uFSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=u+G3jbpi+uqGh4Mgvr/WXzroKBBkcNyykL9ZuVzSyEd/Tg1WnhksRbmv670bvcz2VV /AtgEhCXp76lYXtm+Je5pMqh8yi26qDg6uU0O6yCOEGBpD9CT3Af89M7b/GJjyiC2srH 8LRiZDbqC5/4zsald9tjsLRD81e7/nLCr+j44= MIME-Version: 1.0 Received: by 10.229.49.130 with SMTP id v2mr5161489qcf.264.1302618461579; Tue, 12 Apr 2011 07:27:41 -0700 (PDT) Received: by 10.229.73.141 with HTTP; Tue, 12 Apr 2011 07:27:41 -0700 (PDT) Date: Tue, 12 Apr 2011 07:27:41 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=00163646d038ae2bea04a0b97e58 Subject: [OAUTH-WG] client authentication for implicit grant type 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, 12 Apr 2011 14:27:43 -0000 --00163646d038ae2bea04a0b97e58 Content-Type: text/plain; charset=ISO-8859-1 I brought this concern up about a year ago. Now reviewing the latest drafts, I still have a concern with it. It is regarding the use of client_id without a password. I agree with section 3, as included below: Section 3. Client Authentication The client identifier is not a secret, it is exposed to the resource > owner, and MUST NOT be used alone for client authentication. Client > authentication is accomplished via additional means such as a > matching client password. The above tells me (rightly so IMO) that considering the client_id alone (without real authentication) is dangerous. Yet the Implicit Grant type accepts a client_id, but no authentication: Section 4.2 Implicit Grant client_id > > REQUIRED. The client identifier as described in Section 3. > > Now here me: I am *not* advocating for a client_secret in this case. I fully understand that some clients, particularly javascript widget clients that are embedded in others' web pages, can't keep secrets. What I am advocating is that clients that can't keep secrets shouldn't have IDs either. This is a wide-open door for clients to obtain access to protected user data by lying about their identity to authorization servers. They can achieve this in either of two ways, given some popular client_id we'll arbitrarily call 'facebook' that users are accustomed to authorizing access to: 1. An evil client can redirect the user to the authorization endpoint, requesting an implicit grant, and including client_id=facebook in the URL. The authorization server may ask the user "Do you want to give Facebook access?" along with (perhaps) a warning that most users won't know what to do about (honestly, most technical users wouldn't know how to verify either. The user, who trusts Facebook, will click Accept, and offer whatever rogue client was running on the page they were visiting the access that they requested. 2. In scenario 2, which is far worse, an evil client can redirect the user to the authorization endpoint, requesting an implicit grant, and including client_id=facebook in the URL. Same so far, but in this case, the authorization server sees that access has already been authorized by the resource owner to this client in the past and immediately redirects back with the requested access token, no user involvement whatsoever. Again, the client obtains access. Now, one might say to #2 that authorization servers shouldn't automatically authorize implicit requests. That person would be absolutely right. I'm concerned that enough clients will complain about the user experience though that authorization servers will yield to them and begin auto-authorizing these, justifying it by making the "limited" access tokens. No go. Either you have protected data or you don't. To #1, there's no way that I can think of to properly educate the user to be able to detect a phishing attack of this nature, such that if they see a "do you want to authorize facebook?" when there is no facebook widget on the page, that they should deny access. Between those two, I see only negative impact to including client_id in implicit grant requests. Please, will someone either address my concerns (tell me where I'm wrong) or remove that parameter from this grant type? Thanks for your time. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo --00163646d038ae2bea04a0b97e58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I brought this concern up about a year ago. =A0Now reviewing the lates= t drafts, I still have a concern with it. =A0It is regarding the use of cli= ent_id without a password. =A0I agree with section 3, as included below:

Section=A03. Client Authentication

The client identifier is not a secret, it is exposed to the resource
= owner, and MUST NOT be used alone for client authentication. Client
= authentication is accomplished via additional means such as a
matc= hing client password.

The above tells me (rightly so IMO) that considering th= e client_id alone (without real authentication) is dangerous. =A0Yet the Im= plicit Grant type accepts a client_id, but no authentication:
Section 4.2 Implicit Grant

client_id
REQUIRED. The client identifier as de= scribed in Section 3.
Now here me: I am not= =A0advocating for a client_secret in this case. =A0I fully understand that = some clients, particularly javascript widget clients that are embedded in o= thers' web pages, can't keep secrets. =A0What I am advocating is th= at =A0clients that can't keep secrets shouldn't have IDs either. = =A0This is a wide-open door for clients to obtain access to protected user = data by lying about their identity to authorization servers. =A0They can ac= hieve this in either of two ways, given some popular client_id we'll ar= bitrarily call 'facebook' that users are accustomed to authorizing = access to:
  1. An evil client can redirect the user to the authorization endp= oint, requesting an implicit grant, and including client_id=3Dfacebook in t= he URL. =A0The authorization server may ask the user "Do you want to g= ive Facebook access?" along with (perhaps) a warning that most users w= on't know what to do about (honestly, most technical users wouldn't= know how to verify either. =A0The user, who trusts Facebook, will click Ac= cept, and offer whatever rogue client was running on the page they were vis= iting the access that they requested.
  2. In scenario 2, which is far worse,=A0an evil client can redirect the us= er to the authorization endpoint, requesting an implicit grant, and includi= ng client_id=3Dfacebook in the URL. =A0Same so far, but in this case, the a= uthorization server sees that access has already been authorized by the res= ource owner to this client in the past and immediately redirects back with = the requested access token, no user involvement whatsoever. =A0Again, the c= lient obtains access.
Now, one might say to #2 that authorization servers shouldn't= automatically authorize implicit requests. =A0That person would be absolut= ely right. =A0I'm concerned that enough clients will complain about the= user experience though that authorization servers will yield to them and b= egin auto-authorizing these, justifying it by making the "limited"= ; access tokens. =A0No go. =A0Either you have protected data or you don'= ;t. =A0
To #1, there's no way that I can think of to properly educate the = user to be able to detect a phishing attack of this nature, such that if th= ey see a "do you want to authorize facebook?" when there is no fa= cebook widget on the page, that they should deny access. =A0

Between those two, I see only negative impact to includ= ing client_id in implicit grant requests. =A0Please, will someone either ad= dress my concerns (tell me where I'm wrong) or remove that parameter fr= om this grant type?

Thanks for your time.

--
A= ndrew Arnott
"I [may] not agree with what you have to say, but I= 9;ll defend to the death your right to say it." - S. G. Tallentyre=20
We're hiring! My team= at Microsoft has 7 open slots.=A0http://bit.ly/fZBVUo

--00163646d038ae2bea04a0b97e58-- From eran@hueniverse.com Tue Apr 12 07:48:23 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6B4A5E07EB for ; Tue, 12 Apr 2011 07:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ixFlmCLGmbw for ; Tue, 12 Apr 2011 07:48:19 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id B8E96E07E3 for ; Tue, 12 Apr 2011 07:48:18 -0700 (PDT) Received: (qmail 25844 invoked from network); 12 Apr 2011 14:48:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 Apr 2011 14:48:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 12 Apr 2011 07:48:12 -0700 From: Eran Hammer-Lahav To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Tue, 12 Apr 2011 07:48:07 -0700 Thread-Topic: [OAUTH-WG] client authentication for implicit grant type Thread-Index: Acv5Hcwonj+wsxDMREekrc1d40QYugAAlLSg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72344656743B2E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72344656743B2EP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] client authentication for implicit grant type 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, 12 Apr 2011 14:48:23 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72344656743B2EP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think there is much we can do either way to prevent these phishing-= like attacks with or without the client identifier. The key to security her= e is the ability of the end-user to keep track of how it got there, and bas= ed on that decide if they want to grant access to whoever sent them to the = authorization endpoint. This is the same problem with phishing - the user e= nds up in a login page and unless they pay attention how they go there (and= where they are if its possible to assert), they will give the attacker the= ir password. If you don't include the client identifier and won't give them a hint "John= 's App wants access", they will just get used to approving it without the h= int. At the end of the day, if there is value in approving such unidentifie= d clients, end-users will do it regardless of security. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Tuesday, April 12, 2011 7:28 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] client authentication for implicit grant type I brought this concern up about a year ago. Now reviewing the latest draft= s, I still have a concern with it. It is regarding the use of client_id wi= thout a password. I agree with section 3, as included below: Section 3. Client Authentication The client identifier is not a secret, it is exposed to the resource owner, and MUST NOT be used alone for client authentication. Client authentication is accomplished via additional means such as a matching client password. The above tells me (rightly so IMO) that considering the client_id alone (w= ithout real authentication) is dangerous. Yet the Implicit Grant type acce= pts a client_id, but no authentication: Section 4.2 Implicit Grant client_id REQUIRED. The client identifier as described in Section 3. Now here me: I am not advocating for a client_secret in this case. I fully= understand that some clients, particularly javascript widget clients that = are embedded in others' web pages, can't keep secrets. What I am advocatin= g is that clients that can't keep secrets shouldn't have IDs either. This= is a wide-open door for clients to obtain access to protected user data by= lying about their identity to authorization servers. They can achieve thi= s in either of two ways, given some popular client_id we'll arbitrarily cal= l 'facebook' that users are accustomed to authorizing access to: 1. An evil client can redirect the user to the authorization endpoint, re= questing an implicit grant, and including client_id=3Dfacebook in the URL. = The authorization server may ask the user "Do you want to give Facebook ac= cess?" along with (perhaps) a warning that most users won't know what to do= about (honestly, most technical users wouldn't know how to verify either. = The user, who trusts Facebook, will click Accept, and offer whatever rogue= client was running on the page they were visiting the access that they req= uested. 2. In scenario 2, which is far worse, an evil client can redirect the use= r to the authorization endpoint, requesting an implicit grant, and includin= g client_id=3Dfacebook in the URL. Same so far, but in this case, the auth= orization server sees that access has already been authorized by the resour= ce owner to this client in the past and immediately redirects back with the= requested access token, no user involvement whatsoever. Again, the client= obtains access. Now, one might say to #2 that authorization servers shouldn't automatically= authorize implicit requests. That person would be absolutely right. I'm = concerned that enough clients will complain about the user experience thoug= h that authorization servers will yield to them and begin auto-authorizing = these, justifying it by making the "limited" access tokens. No go. Either= you have protected data or you don't. To #1, there's no way that I can think of to properly educate the user to b= e able to detect a phishing attack of this nature, such that if they see a = "do you want to authorize facebook?" when there is no facebook widget on th= e page, that they should deny access. Between those two, I see only negative impact to including client_id in imp= licit grant requests. Please, will someone either address my concerns (tel= l me where I'm wrong) or remove that parameter from this grant type? Thanks for your time. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo --_000_90C41DD21FB7C64BB94121FBBC2E72344656743B2EP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I donR= 17;t think there is much we can do either way to prevent these phishing-lik= e attacks with or without the client identifier. The key to security here i= s the ability of the end-user to keep track of how it got there, and based = on that decide if they want to grant access to whoever sent them to the aut= horization endpoint. This is the same problem with phishing – the use= r ends up in a login page and unless they pay attention how they go there (= and where they are if its possible to assert), they will give the attacker = their password.

 = ;

If you don’t include th= e client identifier and won’t give them a hint “John’s Ap= p wants access”, they will just get used to approving it without the = hint. At the end of the day, if there is value in approving such unidentifi= ed clients, end-users will do it regardless of security.<= /p>

 

EHL

 = ;

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4= .0pt'>

From: oauth-bounces@ietf.org [mailto= :oauth-bounces@ietf.org] On Behalf Of Andrew Arnott
Sent: = Tuesday, April 12, 2011 7:28 AM
To: OAuth WG (oauth@ietf.org)
= Subject: [OAUTH-WG] client authentication for implicit grant type

 

I brought this concern up about a year ago.  N= ow reviewing the latest drafts, I still have a concern with it.  It is= regarding the use of client_id without a password.  I agree with sect= ion 3, as included below:

 

Section 3. Client Authentication

The client identifier is not a secret, it is exposed to the resourceowner, and MUST NOT be used alone for client authentication. Client
aut= hentication is accomplished via additional means such as a
matching clie= nt password.

 

<= /div>

The above tells me (rightly so IMO) that con= sidering the client_id alone (without real authentication) is dangerous. &n= bsp;Yet the Implicit Grant type accepts a client_id, but no authentication:=

 

<= div>

Section 4.2 Implicit Grant

=  

= client_id

REQUIRED. The client identifier as described in Section 3.

Now here me: I am not advocating for a client_secret in this case.  I fully understa= nd that some clients, particularly javascript widget clients that are embed= ded in others' web pages, can't keep secrets.  What I am advocating is= that  clients that can't keep secrets shouldn't have IDs either. &nbs= p;This is a wide-open door for clients to obtain access to protected user d= ata by lying about their identity to authorization servers.  They can = achieve this in either of two ways, given some popular client_id we'll arbi= trarily call 'facebook' that users are accustomed to authorizing access to:=

  1. An evil client can redirect the user to the authorization endpoint, r= equesting an implicit grant, and including client_id=3Dfacebook in the URL.=  The authorization server may ask the user "Do you want to give = Facebook access?" along with (perhaps) a warning that most users won't= know what to do about (honestly, most technical users wouldn't know how to= verify either.  The user, who trusts Facebook, will click Accept, and= offer whatever rogue client was running on the page they were visiting the= access that they requested.
  2. In scenario 2, which is far worse, an evil client can redirect the us= er to the authorization endpoint, requesting an implicit grant, and includi= ng client_id=3Dfacebook in the URL.  Same so far, but in this case, th= e authorization server sees that access has already been authorized by the = resource owner to this client in the past and immediately redirects back wi= th the requested access token, no user involvement whatsoever.  Again,= the client obtains access.

N= ow, one might say to #2 that authorization servers shouldn't automatically = authorize implicit requests.  That person would be absolutely right. &= nbsp;I'm concerned that enough clients will complain about the user experie= nce though that authorization servers will yield to them and begin auto-aut= horizing these, justifying it by making the "limited" access toke= ns.  No go.  Either you have protected data or you don't.  <= o:p>

To #1, there's no way that I = can think of to properly educate the user to be able to detect a phishing a= ttack of this nature, such that if they see a "do you want to authoriz= e facebook?" when there is no facebook widget on the page, that they s= hould deny access.  

 

Between those two, I see = only negative impact to including client_id in implicit grant requests. &nb= sp;Please, will someone either address my concerns (tell me where I'm wrong= ) or remove that parameter from this grant type?

<= p class=3DMsoNormal> 

Th= anks for your time.

 

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

We're hiring! My team at Mi= crosoft has 7 open slots. http://bit.ly/fZBVUo

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72344656743B2EP3PW5EX1MB01E_-- From andrewarnott@gmail.com Tue Apr 12 08:30:15 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C0537E0805 for ; Tue, 12 Apr 2011 08:30:15 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URZO2rnRhqf0 for ; Tue, 12 Apr 2011 08:30:14 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfc.amsl.com (Postfix) with ESMTP id 33FCBE07EA for ; Tue, 12 Apr 2011 08:30:14 -0700 (PDT) Received: by qyk29 with SMTP id 29so1906213qyk.10 for ; Tue, 12 Apr 2011 08:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bg1q0k+uEmvakVJCKuWhVctken+dIgsumqRHTDqXNtE=; b=idufGSInenxK+HVO/r99DOX9KMK+W4jhl7NBuEvPdlb+QjQkIiZVP+2yzTZYwOPL5i ThCRhn0nkL08eEC1keK0Cgyflzkbd3yGkR6WsTbgxikTQDKpONYbUUR+kWGkDlSrxUeK alqHi8vTHIg0o1e1T5NBCEKI6kC/vcgI4crcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=F0vZrlMhNjl2itrmDUAEJ7+R9CdBj4jSdsfUlmnPTYSQeudeT+GjNOVrmCrElYtmj5 j28LY1ya7xL90SnpIoqDK91M8QYZPnn3mykkK94uSo33eFRhBPrSYu/cAps/gv1fnUpe UVQOLtZVixlmLss2/a4avPQVN17wLa1MRKgG8= MIME-Version: 1.0 Received: by 10.229.49.130 with SMTP id v2mr5225651qcf.264.1302622213863; Tue, 12 Apr 2011 08:30:13 -0700 (PDT) Received: by 10.229.73.141 with HTTP; Tue, 12 Apr 2011 08:30:13 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72344656743B2E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72344656743B2E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 12 Apr 2011 08:30:13 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00163646d03855782a04a0ba5e96 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] client authentication for implicit grant type 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, 12 Apr 2011 15:30:15 -0000 --00163646d03855782a04a0ba5e96 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, Eran. Will the security considerations section discuss this and recommend that auth servers warn the users of the potential phishing attack= ? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav wro= te: > I don=92t think there is much we can do either way to prevent these > phishing-like attacks with or without the client identifier. The key to > security here is the ability of the end-user to keep track of how it got > there, and based on that decide if they want to grant access to whoever s= ent > them to the authorization endpoint. This is the same problem with phishin= g =96 > the user ends up in a login page and unless they pay attention how they g= o > there (and where they are if its possible to assert), they will give the > attacker their password. > > > > If you don=92t include the client identifier and won=92t give them a hint > =93John=92s App wants access=94, they will just get used to approving it = without > the hint. At the end of the day, if there is value in approving such > unidentified clients, end-users will do it regardless of security. > > > > EHL > > > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Andrew Arnott > *Sent:* Tuesday, April 12, 2011 7:28 AM > *To:* OAuth WG (oauth@ietf.org) > *Subject:* [OAUTH-WG] client authentication for implicit grant type > > > > I brought this concern up about a year ago. Now reviewing the latest > drafts, I still have a concern with it. It is regarding the use of > client_id without a password. I agree with section 3, as included below: > > > > Section 3. Client Authentication > > The client identifier is not a secret, it is exposed to the resource > owner, and MUST NOT be used alone for client authentication. Client > authentication is accomplished via additional means such as a > matching client password. > > > > The above tells me (rightly so IMO) that considering the client_id alone > (without real authentication) is dangerous. Yet the Implicit Grant type > accepts a client_id, but no authentication: > > > > Section 4.2 Implicit Grant > > > > client_id > > REQUIRED. The client identifier as described in Section 3. > > Now here me: I am *not* advocating for a client_secret in this case. I > fully understand that some clients, particularly javascript widget client= s > that are embedded in others' web pages, can't keep secrets. What I am > advocating is that clients that can't keep secrets shouldn't have IDs > either. This is a wide-open door for clients to obtain access to protect= ed > user data by lying about their identity to authorization servers. They c= an > achieve this in either of two ways, given some popular client_id we'll > arbitrarily call 'facebook' that users are accustomed to authorizing acce= ss > to: > > 1. An evil client can redirect the user to the authorization endpoint, > requesting an implicit grant, and including client_id=3Dfacebook in th= e URL. > The authorization server may ask the user "Do you want to give Facebo= ok > access?" along with (perhaps) a warning that most users won't know wha= t to > do about (honestly, most technical users wouldn't know how to verify e= ither. > The user, who trusts Facebook, will click Accept, and offer whatever = rogue > client was running on the page they were visiting the access that they > requested. > 2. In scenario 2, which is far worse, an evil client can redirect the > user to the authorization endpoint, requesting an implicit grant, and > including client_id=3Dfacebook in the URL. Same so far, but in this c= ase, the > authorization server sees that access has already been authorized by t= he > resource owner to this client in the past and immediately redirects ba= ck > with the requested access token, no user involvement whatsoever. Agai= n, the > client obtains access. > > Now, one might say to #2 that authorization servers shouldn't automatical= ly > authorize implicit requests. That person would be absolutely right. I'm > concerned that enough clients will complain about the user experience tho= ugh > that authorization servers will yield to them and begin auto-authorizing > these, justifying it by making the "limited" access tokens. No go. Eith= er > you have protected data or you don't. > > To #1, there's no way that I can think of to properly educate the user to > be able to detect a phishing attack of this nature, such that if they see= a > "do you want to authorize facebook?" when there is no facebook widget on = the > page, that they should deny access. > > > > Between those two, I see only negative impact to including client_id in > implicit grant requests. Please, will someone either address my concerns > (tell me where I'm wrong) or remove that parameter from this grant type? > > > > Thanks for your time. > > > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the deat= h > your right to say it." - S. G. Tallentyre > > We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo > > > --00163646d03855782a04a0ba5e96 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, Eran. =A0Will the security considerations section discuss this and = recommend that auth servers warn the users of the potential phishing attack= ?

--
Andrew Arnott
"I [may] not agree with= what you have to say, but I'll defend to the death your right to say i= t." - S. G. Tallentyre=20
We're hiring! My team= at Microsoft has 7 open slots.=A0http://bit.ly/fZBVUo



On Tue, Apr 12, 2011 at 7:48 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

I don=92t think there is= much we can do either way to prevent these phishing-like attacks with or w= ithout the client identifier. The key to security here is the ability of th= e end-user to keep track of how it got there, and based on that decide if t= hey want to grant access to whoever sent them to the authorization endpoint= . This is the same problem with phishing =96 the user ends up in a login pa= ge and unless they pay attention how they go there (and where they are if i= ts possible to assert), they will give the attacker their password.<= /p>

=A0

If you don=92t include the client identifier and won=92t give them a hi= nt =93John=92s App wants access=94, they will just get used to approving it= without the hint. At the end of the day, if there is value in approving su= ch unidentified clients, end-users will do it regardless of security.

=A0

EHL

=A0

=A0

From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be= half Of Andrew Arnott
Sent: Tuesday, April 12, 2011 7:28 AM
To: OAuth WG (oauth@ietf.org)
Sub= ject: [OAUTH-WG] client authentication for implicit grant type

=A0

I brought this concern up about a year ago. = =A0Now reviewing the latest drafts, I still have a concern with it. =A0It i= s regarding the use of client_id without a password. =A0I agree with sectio= n 3, as included below:

=A0

Section=A03. Client Authentication

The client identifier is not a secret, it is exposed to th= e resource
owner, and MUST NOT be used alone for client authentication. Client
auth= entication is accomplished via additional means such as a
matching clien= t password.

=A0

The above tells me (rightly so IMO) that considering the client_id alone (w= ithout real authentication) is dangerous. =A0Yet the Implicit Grant type ac= cepts a client_id, but no authentication:

=A0

Section 4.2 Implicit Grant

=A0

client_id

REQUIRED. T= he client identifier as described in Section 3.

Now here me: I am not=A0advocating for a client_secret in this case.= =A0I fully understand that some clients, particularly javascript widget cl= ients that are embedded in others' web pages, can't keep secrets. = =A0What I am advocating is that =A0clients that can't keep secrets shou= ldn't have IDs either. =A0This is a wide-open door for clients to obtai= n access to protected user data by lying about their identity to authorizat= ion servers. =A0They can achieve this in either of two ways, given some pop= ular client_id we'll arbitrarily call 'facebook' that users are= accustomed to authorizing access to:

  1. An evil clien= t can redirect the user to the authorization endpoint, requesting an implic= it grant, and including client_id=3Dfacebook in the URL. =A0The authorizati= on server may ask the user "Do you want to give Facebook access?"= along with (perhaps) a warning that most users won't know what to do a= bout (honestly, most technical users wouldn't know how to verify either= . =A0The user, who trusts Facebook, will click Accept, and offer whatever r= ogue client was running on the page they were visiting the access that they= requested.
  2. In scenario 2, which is far worse,=A0an evil client= can redirect the user to the authorization endpoint, requesting an implici= t grant, and including client_id=3Dfacebook in the URL. =A0Same so far, but= in this case, the authorization server sees that access has already been a= uthorized by the resource owner to this client in the past and immediately = redirects back with the requested access token, no user involvement whatsoe= ver. =A0Again, the client obtains access.

Now, one might say to #2 that authorizatio= n servers shouldn't automatically authorize implicit requests. =A0That = person would be absolutely right. =A0I'm concerned that enough clients = will complain about the user experience though that authorization servers w= ill yield to them and begin auto-authorizing these, justifying it by making= the "limited" access tokens. =A0No go. =A0Either you have protec= ted data or you don't. =A0

To #1, there's no way that I can thin= k of to properly educate the user to be able to detect a phishing attack of= this nature, such that if they see a "do you want to authorize facebo= ok?" when there is no facebook widget on the page, that they should de= ny access. =A0

=A0

= Between those two, I see only negative impact to including client_id in imp= licit grant requests. =A0Please, will someone either address my concerns (t= ell me where I'm wrong) or remove that parameter from this grant type?<= /p>

=A0

= Thanks for your time.

=A0

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

We're hiring! My team a= t Microsoft has 7 open slots.=A0http://bit.ly/fZBVUo

=A0


--00163646d03855782a04a0ba5e96-- From eran@hueniverse.com Tue Apr 12 08:51:19 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 22B3BE06B9 for ; Tue, 12 Apr 2011 08:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYLRi3Z7DSLD for ; Tue, 12 Apr 2011 08:51:13 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 90485E0807 for ; Tue, 12 Apr 2011 08:51:13 -0700 (PDT) Received: (qmail 23596 invoked from network); 12 Apr 2011 15:51:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Apr 2011 15:51:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 12 Apr 2011 08:51:01 -0700 From: Eran Hammer-Lahav To: Andrew Arnott Date: Tue, 12 Apr 2011 08:50:56 -0700 Thread-Topic: [OAUTH-WG] client authentication for implicit grant type Thread-Index: Acv5Jp7YIWavw0GITSOde8UJcPqDigAAsGGQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72344656743B5E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72344656743B2E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72344656743B5EP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] client authentication for implicit grant type 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, 12 Apr 2011 15:51:19 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72344656743B5EP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It should include a section on phishing-like attacks. EHL From: Andrew Arnott [mailto:andrewarnott@gmail.com] Sent: Tuesday, April 12, 2011 8:30 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] client authentication for implicit grant type Thanks, Eran. Will the security considerations section discuss this and re= commend that auth servers warn the users of the potential phishing attack? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav > wrote: I don't think there is much we can do either way to prevent these phishing-= like attacks with or without the client identifier. The key to security her= e is the ability of the end-user to keep track of how it got there, and bas= ed on that decide if they want to grant access to whoever sent them to the = authorization endpoint. This is the same problem with phishing - the user e= nds up in a login page and unless they pay attention how they go there (and= where they are if its possible to assert), they will give the attacker the= ir password. If you don't include the client identifier and won't give them a hint "John= 's App wants access", they will just get used to approving it without the h= int. At the end of the day, if there is value in approving such unidentifie= d clients, end-users will do it regardless of security. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Andrew Arnott Sent: Tuesday, April 12, 2011 7:28 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] client authentication for implicit grant type I brought this concern up about a year ago. Now reviewing the latest draft= s, I still have a concern with it. It is regarding the use of client_id wi= thout a password. I agree with section 3, as included below: Section 3. Client Authentication The client identifier is not a secret, it is exposed to the resource owner, and MUST NOT be used alone for client authentication. Client authentication is accomplished via additional means such as a matching client password. The above tells me (rightly so IMO) that considering the client_id alone (w= ithout real authentication) is dangerous. Yet the Implicit Grant type acce= pts a client_id, but no authentication: Section 4.2 Implicit Grant client_id REQUIRED. The client identifier as described in Section 3. Now here me: I am not advocating for a client_secret in this case. I fully= understand that some clients, particularly javascript widget clients that = are embedded in others' web pages, can't keep secrets. What I am advocatin= g is that clients that can't keep secrets shouldn't have IDs either. This= is a wide-open door for clients to obtain access to protected user data by= lying about their identity to authorization servers. They can achieve thi= s in either of two ways, given some popular client_id we'll arbitrarily cal= l 'facebook' that users are accustomed to authorizing access to: 1. An evil client can redirect the user to the authorization endpoint, re= questing an implicit grant, and including client_id=3Dfacebook in the URL. = The authorization server may ask the user "Do you want to give Facebook ac= cess?" along with (perhaps) a warning that most users won't know what to do= about (honestly, most technical users wouldn't know how to verify either. = The user, who trusts Facebook, will click Accept, and offer whatever rogue= client was running on the page they were visiting the access that they req= uested. 2. In scenario 2, which is far worse, an evil client can redirect the use= r to the authorization endpoint, requesting an implicit grant, and includin= g client_id=3Dfacebook in the URL. Same so far, but in this case, the auth= orization server sees that access has already been authorized by the resour= ce owner to this client in the past and immediately redirects back with the= requested access token, no user involvement whatsoever. Again, the client= obtains access. Now, one might say to #2 that authorization servers shouldn't automatically= authorize implicit requests. That person would be absolutely right. I'm = concerned that enough clients will complain about the user experience thoug= h that authorization servers will yield to them and begin auto-authorizing = these, justifying it by making the "limited" access tokens. No go. Either= you have protected data or you don't. To #1, there's no way that I can think of to properly educate the user to b= e able to detect a phishing attack of this nature, such that if they see a = "do you want to authorize facebook?" when there is no facebook widget on th= e page, that they should deny access. Between those two, I see only negative impact to including client_id in imp= licit grant requests. Please, will someone either address my concerns (tel= l me where I'm wrong) or remove that parameter from this grant type? Thanks for your time. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo --_000_90C41DD21FB7C64BB94121FBBC2E72344656743B5EP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It should= include a section on phishing-like attacks.

 

EHL

 

From: Andrew Arnott [mailto:= andrewarnott@gmail.com]
Sent: Tuesday, April 12, 2011 8:30 AMTo: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] client authentication for implicit grant type<= o:p>

 

=

Thanks, Eran.  Will the security considerations s= ection discuss this and recommend that auth servers warn the users of the p= otential phishing attack?


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

We're hiring! My team at Microsoft = has 7 open slots. h= ttp://bit.ly/fZBVUo



On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

=

I don’t th= ink there is much we can do either way to prevent these phishing-like attac= ks with or without the client identifier. The key to security here is the a= bility of the end-user to keep track of how it got there, and based on that= decide if they want to grant access to whoever sent them to the authorizat= ion endpoint. This is the same problem with phishing – the user ends = up in a login page and unless they pay attention how they go there (and whe= re they are if its possible to assert), they will give the attacker their p= assword.

 

If you don’t include the client identifier and won= 217;t give them a hint “John’s App wants access”, they wi= ll just get used to approving it without the hint. At the end of the day, i= f there is value in approving such unidentified clients, end-users will do = it regardless of security.

 

EHL

 

=  

=

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = On Behalf Of Andrew Arnott
Sent: Tuesday, April 12, 2011 7:28= AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] client authenticatio= n for implicit grant type

 

I brought this concern up about a year ag= o.  Now reviewing the latest drafts, I still have a concern with it. &= nbsp;It is regarding the use of client_id without a password.  I agree= with section 3, as included below:

 <= o:p>

Section 3. Client Authentication<= /p>

The client identifier is not a secret, it is exposed to the resou= rce
owner, and MUST NOT be used alone for client authentication. Client<= br>authentication is accomplished via additional means such as a
matchin= g client password.

 

The above tells me (rightly so IMO) that considering the client_id= alone (without real authentication) is dangerous.  Yet the Implicit G= rant type accepts a client_id, but no authentication:

<= div>

 

Section 4.2 Implicit Gran= t

 

client_id

<= span style=3D'font-size:13.5pt'>REQUIRED. The client identifier as describe= d in Section 3.

Now here me: I am = not advocating for a client_secret in this case.  I fully = understand that some clients, particularly javascript widget clients that a= re embedded in others' web pages, can't keep secrets.  What I am advoc= ating is that  clients that can't keep secrets shouldn't have IDs eith= er.  This is a wide-open door for clients to obtain access to protecte= d user data by lying about their identity to authorization servers.  T= hey can achieve this in either of two ways, given some popular client_id we= 'll arbitrarily call 'facebook' that users are accustomed to authorizing ac= cess to:

  1. An evil client can redirect the user to the authorization end= point, requesting an implicit grant, and including client_id=3Dfacebook in = the URL.  The authorization server may ask the user "Do you want = to give Facebook access?" along with (perhaps) a warning that most use= rs won't know what to do about (honestly, most technical users wouldn't kno= w how to verify either.  The user, who trusts Facebook, will click Acc= ept, and offer whatever rogue client was running on the page they were visi= ting the access that they requested.
  2. In scenario 2, which is far worse, an evil client can redirec= t the user to the authorization endpoint, requesting an implicit grant, and= including client_id=3Dfacebook in the URL.  Same so far, but in this = case, the authorization server sees that access has already been authorized= by the resource owner to this client in the past and immediately redirects= back with the requested access token, no user involvement whatsoever. &nbs= p;Again, the client obtains access.

Now, on= e might say to #2 that authorization servers shouldn't automatically author= ize implicit requests.  That person would be absolutely right.  I= 'm concerned that enough clients will complain about the user experience th= ough that authorization servers will yield to them and begin auto-authorizi= ng these, justifying it by making the "limited" access tokens. &n= bsp;No go.  Either you have protected data or you don't.  

To #1, there's no way that I can think of to prop= erly educate the user to be able to detect a phishing attack of this nature= , such that if they see a "do you want to authorize facebook?" wh= en there is no facebook widget on the page, that they should deny access. &= nbsp;

 

Between those two, I see only negative impact to including client_id in i= mplicit grant requests.  Please, will someone either address my concer= ns (tell me where I'm wrong) or remove that parameter from this grant type?=

 

T= hanks for your time.

 

--
Andrew= Arnott
"I [may] not agree with what you have to say, but I'll defe= nd to the death your right to say it." - S. G. Tallentyre <= /p>

We're hiring! My team at Mi= crosoft has 7 open slots. http://bit.ly/fZBVUo

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72344656743B5EP3PW5EX1MB01E_-- From torsten@lodderstedt.net Tue Apr 12 08:54:25 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F19BBE0822 for ; Tue, 12 Apr 2011 08:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOxxt0kS0lnE for ; Tue, 12 Apr 2011 08:54:21 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.98]) by ietfc.amsl.com (Postfix) with ESMTP id 58FA0E081C for ; Tue, 12 Apr 2011 08:54:21 -0700 (PDT) Received: from [79.253.12.122] (helo=[192.168.71.34]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Q9fv1-00058b-Qq; Tue, 12 Apr 2011 17:54:19 +0200 Message-ID: <4DA475AE.9030106@lodderstedt.net> Date: Tue, 12 Apr 2011 17:54:22 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72344656743B2E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72344656743B5E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72344656743B5E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------010802030909040602060501" X-Df-Sender: torsten@lodderstedt-online.de Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] client authentication for implicit grant type 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, 12 Apr 2011 15:54:26 -0000 This is a multi-part message in MIME format. --------------010802030909040602060501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The proposed text already does (http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02). When will you post the new revision of the core draft that includes the proposed text? regards, Torsten. Am 12.04.2011 17:50, schrieb Eran Hammer-Lahav: > > It should include a section on phishing-like attacks. > > EHL > > *From:*Andrew Arnott [mailto:andrewarnott@gmail.com] > *Sent:* Tuesday, April 12, 2011 8:30 AM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] client authentication for implicit grant type > > Thanks, Eran. Will the security considerations section discuss this > and recommend that auth servers warn the users of the potential > phishing attack? > > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the > death your right to say it." - S. G. Tallentyre > > We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo > > > > On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav > > wrote: > > I don't think there is much we can do either way to prevent these > phishing-like attacks with or without the client identifier. The key > to security here is the ability of the end-user to keep track of how > it got there, and based on that decide if they want to grant access to > whoever sent them to the authorization endpoint. This is the same > problem with phishing -- the user ends up in a login page and unless > they pay attention how they go there (and where they are if its > possible to assert), they will give the attacker their password. > > If you don't include the client identifier and won't give them a hint > "John's App wants access", they will just get used to approving it > without the hint. At the end of the day, if there is value in > approving such unidentified clients, end-users will do it regardless > of security. > > EHL > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] *On > Behalf Of *Andrew Arnott > *Sent:* Tuesday, April 12, 2011 7:28 AM > *To:* OAuth WG (oauth@ietf.org ) > *Subject:* [OAUTH-WG] client authentication for implicit grant type > > I brought this concern up about a year ago. Now reviewing the latest > drafts, I still have a concern with it. It is regarding the use of > client_id without a password. I agree with section 3, as included below: > > Section 3. Client Authentication > > The client identifier is not a secret, it is exposed to the resource > owner, and MUST NOT be used alone for client authentication. Client > authentication is accomplished via additional means such as a > matching client password. > > The above tells me (rightly so IMO) that considering the client_id > alone (without real authentication) is dangerous. Yet the Implicit > Grant type accepts a client_id, but no authentication: > > Section 4.2 Implicit Grant > > client_id > > REQUIRED. The client identifier as described in Section 3. > > Now here me: I am /not/ advocating for a client_secret in this case. > I fully understand that some clients, particularly javascript widget > clients that are embedded in others' web pages, can't keep secrets. > What I am advocating is that clients that can't keep secrets > shouldn't have IDs either. This is a wide-open door for clients to > obtain access to protected user data by lying about their identity to > authorization servers. They can achieve this in either of two ways, > given some popular client_id we'll arbitrarily call 'facebook' that > users are accustomed to authorizing access to: > > 1. An evil client can redirect the user to the authorization > endpoint, requesting an implicit grant, and including > client_id=facebook in the URL. The authorization server may ask > the user "Do you want to give Facebook access?" along with > (perhaps) a warning that most users won't know what to do about > (honestly, most technical users wouldn't know how to verify > either. The user, who trusts Facebook, will click Accept, and > offer whatever rogue client was running on the page they were > visiting the access that they requested. > 2. In scenario 2, which is far worse, an evil client can redirect > the user to the authorization endpoint, requesting an implicit > grant, and including client_id=facebook in the URL. Same so > far, but in this case, the authorization server sees that access > has already been authorized by the resource owner to this client > in the past and immediately redirects back with the requested > access token, no user involvement whatsoever. Again, the client > obtains access. > > Now, one might say to #2 that authorization servers shouldn't > automatically authorize implicit requests. That person would be > absolutely right. I'm concerned that enough clients will complain > about the user experience though that authorization servers will yield > to them and begin auto-authorizing these, justifying it by making the > "limited" access tokens. No go. Either you have protected data or > you don't. > > To #1, there's no way that I can think of to properly educate the user > to be able to detect a phishing attack of this nature, such that if > they see a "do you want to authorize facebook?" when there is no > facebook widget on the page, that they should deny access. > > Between those two, I see only negative impact to including client_id > in implicit grant requests. Please, will someone either address my > concerns (tell me where I'm wrong) or remove that parameter from this > grant type? > > Thanks for your time. > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the > death your right to say it." - S. G. Tallentyre > > We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010802030909040602060501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The proposed text already does (http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02).

When will you post the new revision of the core draft that includes the proposed text?

regards,
Torsten.

Am 12.04.2011 17:50, schrieb Eran Hammer-Lahav:

It should include a section on phishing-like attacks.

 

EHL

 

From: Andrew Arnott [mailto:andrewarnott@gmail.com]
Sent: Tuesday, April 12, 2011 8:30 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] client authentication for implicit grant type

 

Thanks, Eran.  Will the security considerations section discuss this and recommend that auth servers warn the users of the potential phishing attack?


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

We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo



On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I don’t think there is much we can do either way to prevent these phishing-like attacks with or without the client identifier. The key to security here is the ability of the end-user to keep track of how it got there, and based on that decide if they want to grant access to whoever sent them to the authorization endpoint. This is the same problem with phishing – the user ends up in a login page and unless they pay attention how they go there (and where they are if its possible to assert), they will give the attacker their password.

 

If you don’t include the client identifier and won’t give them a hint “John’s App wants access”, they will just get used to approving it without the hint. At the end of the day, if there is value in approving such unidentified clients, end-users will do it regardless of security.

 

EHL

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew Arnott
Sent: Tuesday, April 12, 2011 7:28 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] client authentication for implicit grant type

 

I brought this concern up about a year ago.  Now reviewing the latest drafts, I still have a concern with it.  It is regarding the use of client_id without a password.  I agree with section 3, as included below:

 

Section 3. Client Authentication

The client identifier is not a secret, it is exposed to the resource
owner, and MUST NOT be used alone for client authentication. Client
authentication is accomplished via additional means such as a
matching client password.

 

The above tells me (rightly so IMO) that considering the client_id alone (without real authentication) is dangerous.  Yet the Implicit Grant type accepts a client_id, but no authentication:

 

Section 4.2 Implicit Grant

 

client_id

REQUIRED. The client identifier as described in Section 3.

Now here me: I am not advocating for a client_secret in this case.  I fully understand that some clients, particularly javascript widget clients that are embedded in others' web pages, can't keep secrets.  What I am advocating is that  clients that can't keep secrets shouldn't have IDs either.  This is a wide-open door for clients to obtain access to protected user data by lying about their identity to authorization servers.  They can achieve this in either of two ways, given some popular client_id we'll arbitrarily call 'facebook' that users are accustomed to authorizing access to:

  1. An evil client can redirect the user to the authorization endpoint, requesting an implicit grant, and including client_id=facebook in the URL.  The authorization server may ask the user "Do you want to give Facebook access?" along with (perhaps) a warning that most users won't know what to do about (honestly, most technical users wouldn't know how to verify either.  The user, who trusts Facebook, will click Accept, and offer whatever rogue client was running on the page they were visiting the access that they requested.
  2. In scenario 2, which is far worse, an evil client can redirect the user to the authorization endpoint, requesting an implicit grant, and including client_id=facebook in the URL.  Same so far, but in this case, the authorization server sees that access has already been authorized by the resource owner to this client in the past and immediately redirects back with the requested access token, no user involvement whatsoever.  Again, the client obtains access.

Now, one might say to #2 that authorization servers shouldn't automatically authorize implicit requests.  That person would be absolutely right.  I'm concerned that enough clients will complain about the user experience though that authorization servers will yield to them and begin auto-authorizing these, justifying it by making the "limited" access tokens.  No go.  Either you have protected data or you don't.  

To #1, there's no way that I can think of to properly educate the user to be able to detect a phishing attack of this nature, such that if they see a "do you want to authorize facebook?" when there is no facebook widget on the page, that they should deny access.  

 

Between those two, I see only negative impact to including client_id in implicit grant requests.  Please, will someone either address my concerns (tell me where I'm wrong) or remove that parameter from this grant type?

 

Thanks for your time.

 

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

We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo

 

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------010802030909040602060501-- From eran@hueniverse.com Tue Apr 12 09:29:12 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CBD6BE07D5 for ; Tue, 12 Apr 2011 09:29:12 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq6XmhmHq5rF for ; Tue, 12 Apr 2011 09:29:07 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id D5BDCE072E for ; Tue, 12 Apr 2011 09:29:06 -0700 (PDT) Received: (qmail 17310 invoked from network); 12 Apr 2011 16:29:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 Apr 2011 16:29:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 12 Apr 2011 09:28:52 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Tue, 12 Apr 2011 09:28:47 -0700 Thread-Topic: [OAUTH-WG] client authentication for implicit grant type Thread-Index: Acv5KfoGVmeV8UFUSYWN0w6/2X9W6AABKGKw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72344656743B7D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72344656743B2E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72344656743B5E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DA475AE.9030106@lodderstedt.net> In-Reply-To: <4DA475AE.9030106@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72344656743B7DP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] client authentication for implicit grant type 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, 12 Apr 2011 16:29:12 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72344656743B7DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hopefully by the end of the week. My farm took all my free time this weeken= d. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Tuesday, April 12, 2011 8:54 AM To: Eran Hammer-Lahav Cc: Andrew Arnott; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] client authentication for implicit grant type The proposed text already does (http://tools.ietf.org/html/draft-loddersted= t-oauth-securityconsiderations-02). When will you post the new revision of the core draft that includes the pro= posed text? regards, Torsten. Am 12.04.2011 17:50, schrieb Eran Hammer-Lahav: It should include a section on phishing-like attacks. EHL From: Andrew Arnott [mailto:andrewarnott@gmail.com] Sent: Tuesday, April 12, 2011 8:30 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] client authentication for implicit grant type Thanks, Eran. Will the security considerations section discuss this and re= commend that auth servers warn the users of the potential phishing attack? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav > wrote: I don't think there is much we can do either way to prevent these phishing-= like attacks with or without the client identifier. The key to security her= e is the ability of the end-user to keep track of how it got there, and bas= ed on that decide if they want to grant access to whoever sent them to the = authorization endpoint. This is the same problem with phishing - the user e= nds up in a login page and unless they pay attention how they go there (and= where they are if its possible to assert), they will give the attacker the= ir password. If you don't include the client identifier and won't give them a hint "John= 's App wants access", they will just get used to approving it without the h= int. At the end of the day, if there is value in approving such unidentifie= d clients, end-users will do it regardless of security. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Andrew Arnott Sent: Tuesday, April 12, 2011 7:28 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] client authentication for implicit grant type I brought this concern up about a year ago. Now reviewing the latest draft= s, I still have a concern with it. It is regarding the use of client_id wi= thout a password. I agree with section 3, as included below: Section 3. Client Authentication The client identifier is not a secret, it is exposed to the resource owner, and MUST NOT be used alone for client authentication. Client authentication is accomplished via additional means such as a matching client password. The above tells me (rightly so IMO) that considering the client_id alone (w= ithout real authentication) is dangerous. Yet the Implicit Grant type acce= pts a client_id, but no authentication: Section 4.2 Implicit Grant client_id REQUIRED. The client identifier as described in Section 3. Now here me: I am not advocating for a client_secret in this case. I fully= understand that some clients, particularly javascript widget clients that = are embedded in others' web pages, can't keep secrets. What I am advocatin= g is that clients that can't keep secrets shouldn't have IDs either. This= is a wide-open door for clients to obtain access to protected user data by= lying about their identity to authorization servers. They can achieve thi= s in either of two ways, given some popular client_id we'll arbitrarily cal= l 'facebook' that users are accustomed to authorizing access to: 1. An evil client can redirect the user to the authorization endpoint, re= questing an implicit grant, and including client_id=3Dfacebook in the URL. = The authorization server may ask the user "Do you want to give Facebook ac= cess?" along with (perhaps) a warning that most users won't know what to do= about (honestly, most technical users wouldn't know how to verify either. = The user, who trusts Facebook, will click Accept, and offer whatever rogue= client was running on the page they were visiting the access that they req= uested. 2. In scenario 2, which is far worse, an evil client can redirect the use= r to the authorization endpoint, requesting an implicit grant, and includin= g client_id=3Dfacebook in the URL. Same so far, but in this case, the auth= orization server sees that access has already been authorized by the resour= ce owner to this client in the past and immediately redirects back with the= requested access token, no user involvement whatsoever. Again, the client= obtains access. Now, one might say to #2 that authorization servers shouldn't automatically= authorize implicit requests. That person would be absolutely right. I'm = concerned that enough clients will complain about the user experience thoug= h that authorization servers will yield to them and begin auto-authorizing = these, justifying it by making the "limited" access tokens. No go. Either= you have protected data or you don't. To #1, there's no way that I can think of to properly educate the user to b= e able to detect a phishing attack of this nature, such that if they see a = "do you want to authorize facebook?" when there is no facebook widget on th= e page, that they should deny access. Between those two, I see only negative impact to including client_id in imp= licit grant requests. Please, will someone either address my concerns (tel= l me where I'm wrong) or remove that parameter from this grant type? Thanks for your time. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72344656743B7DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hopefully by the end of the week. My farm took all my free time this= weekend.

 

EHL

 

From: Torsten Lodderstedt [m= ailto:torsten@lodderstedt.net]
Sent: Tuesday, April 12, 2011 8:5= 4 AM
To: Eran Hammer-Lahav
Cc: Andrew Arnott; OAuth WG = (oauth@ietf.org)
Subject: Re: [OAUTH-WG] client authentication fo= r implicit grant type

 

The proposed text already does (= http://tools.ietf.org/html/draft-lodderstedt-oauth-securityco= nsiderations-02).

When will you post the new revision of the cor= e draft that includes the proposed text?

regards,
Torsten.
Am 12.04.2011 17:50, schrieb Eran Hammer-Lahav:

It should include a section on phishing-like attacks.<= /p>

 

EHL<= /o:p>

 

From: Andrew Arnott [mailto:andrewarnott@gmail.com]
= Sent: Tuesday, April 12, 2011 8:30 AM
To: Eran Hammer-Laha= v
Cc: OAuth WG (oauth@ietf.org<= /a>)
Subject: Re: [OAUTH-WG] client authentication for implicit g= rant type

 =

Thanks, Eran.  Will the security consid= erations section discuss this and recommend that auth servers warn the user= s of the potential phishing attack?


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




On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:<= /o:p>

I don’t think there is much we can do either way to preve= nt these phishing-like attacks with or without the client identifier. The k= ey to security here is the ability of the end-user to keep track of how it = got there, and based on that decide if they want to grant access to whoever= sent them to the authorization endpoint. This is the same problem with phi= shing – the user ends up in a login page and unless they pay attentio= n how they go there (and where they are if its possible to assert), they wi= ll give the attacker their password.

 =

If = you don’t include the client identifier and won’t give them a h= int “John’s App wants access”, they will just get used to= approving it without the hint. At the end of the day, if there is value in= approving such unidentified clients, end-users will do it regardless of se= curity.

 

EHL

 <= o:p>

 

From: oauth-= bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew Arnott=
Sent: Tuesday, April 12, 2011 7:28 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] client authentication for implicit grant type

 

I brought this concern up about a year ago.=  Now reviewing the latest drafts, I still have a concern with it. &nb= sp;It is regarding the use of client_id without a password.  I agree w= ith section 3, as included below:

 

Section 3. Client Authentication

The client identifier is not a secret, it is exposed to the re= source
owner, and MUST NOT be used alone for client authentication. Clie= nt
authentication is accomplished via additional means such as a
matc= hing client password.

 

The above tells me (rightly so IMO)= that considering the client_id alone (without real authentication) is dang= erous.  Yet the Implicit Grant type accepts a client_id, but no authen= tication:

 

Section 4.2 Implicit Grant

=

 

client_id

REQUIRED. The client identifier as = described in Section 3.

Now here me: I am not advocating for a client_secret in thi= s case.  I fully understand that some clients, particularly javascript= widget clients that are embedded in others' web pages, can't keep secrets.=  What I am advocating is that  clients that can't keep secrets s= houldn't have IDs either.  This is a wide-open door for clients to obt= ain access to protected user data by lying about their identity to authoriz= ation servers.  They can achieve this in either of two ways, given som= e popular client_id we'll arbitrarily call 'facebook' that users are accust= omed to authorizing access to:

  1. An evil client can redirect the user to the authorization endpoin= t, requesting an implicit grant, and including client_id=3Dfacebook in the = URL.  The authorization server may ask the user "Do you want to g= ive Facebook access?" along with (perhaps) a warning that most users w= on't know what to do about (honestly, most technical users wouldn't know ho= w to verify either.  The user, who trusts Facebook, will click Accept,= and offer whatever rogue client was running on the page they were visiting= the access that they requested.
  2. In scenario 2, which is far worse, an evi= l client can redirect the user to the authorization endpoint, requesting an= implicit grant, and including client_id=3Dfacebook in the URL.  Same = so far, but in this case, the authorization server sees that access has alr= eady been authorized by the resource owner to this client in the past and i= mmediately redirects back with the requested access token, no user involvem= ent whatsoever.  Again, the client obtains access.

    3. Now, one might say to #2 that authorization serv= ers shouldn't automatically authorize implicit requests.  That person = would be absolutely right.  I'm concerned that enough clients will com= plain about the user experience though that authorization servers will yiel= d to them and begin auto-authorizing these, justifying it by making the &qu= ot;limited" access tokens.  No go.  Either you have protecte= d data or you don't.  

    T= o #1, there's no way that I can think of to properly educate the user to be= able to detect a phishing attack of this nature, such that if they see a &= quot;do you want to authorize facebook?" when there is no facebook wid= get on the page, that they should deny access.  

    <= div>

     

Between those two, I see only negative impact to including client_id in = implicit grant requests.  Please, will someone either address my conce= rns (tell me where I'm wrong) or remove that parameter from this grant type= ?

 

=

Thanks for your time.

 

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

We're hiring! My team at Microsof= t has 7 open slots. http://bit.ly/fZBVUo

&= nbsp;

 

 
= 
 
__________________________________________=
_____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailm=
an/listinfo/oauth
= --_000_90C41DD21FB7C64BB94121FBBC2E72344656743B7DP3PW5EX1MB01E_-- From skylar@kiva.org Tue Apr 12 15:25:09 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7A922E08A5 for ; Tue, 12 Apr 2011 15:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3K1Yf9bYY3Kt for ; Tue, 12 Apr 2011 15:25:08 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfc.amsl.com (Postfix) with SMTP id ADEAEE0895 for ; Tue, 12 Apr 2011 15:25:07 -0700 (PDT) Received: from mail-iy0-f175.google.com ([209.85.210.175]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKTaTRQlOs1D+AQRIFsrfN4QjmrakY2nv+@postini.com; Tue, 12 Apr 2011 15:25:07 PDT Received: by mail-iy0-f175.google.com with SMTP id 7so41532iye.6 for ; Tue, 12 Apr 2011 15:25:06 -0700 (PDT) Received: by 10.42.82.75 with SMTP id c11mr2122839icl.92.1302647106414; Tue, 12 Apr 2011 15:25:06 -0700 (PDT) Received: from [10.0.1.4] (c-24-5-80-5.hsd1.ca.comcast.net [24.5.80.5]) by mx.google.com with ESMTPS id uf10sm4896775icb.17.2011.04.12.15.25.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2011 15:25:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72344656743B7D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 12 Apr 2011 15:25:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <441CA9C9-E3BA-4DCA-AD69-473660EE93F9@kiva.org> References: <90C41DD21FB7C64BB94121FBBC2E72344656743B2E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72344656743B5E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DA475AE.9030106@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72344656743B7D@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] client authentication for implicit grant type 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, 12 Apr 2011 22:25:09 -0000 Just as a response to Andrew, the concern is valid, and providers should = be educated to warn users about the possibility of a forged identity. = This risk for forgery is actually possible for clients with and without = secrets. Anyone can spoof either type if the client ID is known, thus = showing the approval dialog on the authorization endpoint. The only = difference is that the auth code returned will be useless to the phisher = in the case of a client with a secret. To this point, we always warn our users not to approve an app unless = they trust the application that spawned the approval dialog. We = emphasize this warning even more when a client_id is presented which = can't later validate the identity through use of a secret. As a result of how hard it is to guarantee client identity in these = cases, I think you'll find many providers downplay the identity in = approval dialogs. The page title often reads something generic like "An = application is requesting access to your account" followed then by = details of the app. We've refrained from displaying the name or icon = too prominently in the top or title of the page for this reason. = Certainly, this is kind of guidance to providers is important for the = security notes as well as the UI considerations. So, while identity may seem hopeless in theory, it's actually useful as = a context check, as Eran suggests. (John's App? why is that asking for = permission from this online pharma store?) Moreover, its useful to = providers in terms of tracking app usage because in practice, there is = very little to be gained in forging an app's identity. You might as = well make your own convincing looking app name and icon. Regardless the = challenge remains for the providers to track abuse of the API and user = data, be it from well-meaning apps, sneaky malicious apps, or = mischievous apps masquerading as someone else. skylar On Apr 12, 2011, at 9:28 AM, Eran Hammer-Lahav wrote: > Hopefully by the end of the week. My farm took all my free time this = weekend. > =20 > EHL > =20 > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 > Sent: Tuesday, April 12, 2011 8:54 AM > To: Eran Hammer-Lahav > Cc: Andrew Arnott; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] client authentication for implicit grant type > =20 > The proposed text already does = (http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations= -02). >=20 > When will you post the new revision of the core draft that includes = the proposed text? >=20 > regards, > Torsten. >=20 > Am 12.04.2011 17:50, schrieb Eran Hammer-Lahav: > It should include a section on phishing-like attacks. > =20 > EHL > =20 > From: Andrew Arnott [mailto:andrewarnott@gmail.com]=20 > Sent: Tuesday, April 12, 2011 8:30 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] client authentication for implicit grant type > =20 > Thanks, Eran. Will the security considerations section discuss this = and recommend that auth servers warn the users of the potential phishing = attack? >=20 > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the = death your right to say it." - S. G. Tallentyre > We're hiring! My team at Microsoft has 7 open slots. = http://bit.ly/fZBVUo >=20 >=20 >=20 >=20 > On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav = wrote: > I don=92t think there is much we can do either way to prevent these = phishing-like attacks with or without the client identifier. The key to = security here is the ability of the end-user to keep track of how it got = there, and based on that decide if they want to grant access to whoever = sent them to the authorization endpoint. This is the same problem with = phishing =96 the user ends up in a login page and unless they pay = attention how they go there (and where they are if its possible to = assert), they will give the attacker their password. > =20 > If you don=92t include the client identifier and won=92t give them a = hint =93John=92s App wants access=94, they will just get used to = approving it without the hint. At the end of the day, if there is value = in approving such unidentified clients, end-users will do it regardless = of security. > =20 > EHL > =20 > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Andrew Arnott > Sent: Tuesday, April 12, 2011 7:28 AM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] client authentication for implicit grant type > =20 > I brought this concern up about a year ago. Now reviewing the latest = drafts, I still have a concern with it. It is regarding the use of = client_id without a password. I agree with section 3, as included = below: > =20 > Section 3. Client Authentication >=20 > The client identifier is not a secret, it is exposed to the resource > owner, and MUST NOT be used alone for client authentication. Client > authentication is accomplished via additional means such as a > matching client password. > =20 > The above tells me (rightly so IMO) that considering the client_id = alone (without real authentication) is dangerous. Yet the Implicit = Grant type accepts a client_id, but no authentication: > =20 > Section 4.2 Implicit Grant > =20 > client_id > REQUIRED. The client identifier as described in Section 3. > Now here me: I am not advocating for a client_secret in this case. I = fully understand that some clients, particularly javascript widget = clients that are embedded in others' web pages, can't keep secrets. = What I am advocating is that clients that can't keep secrets shouldn't = have IDs either. This is a wide-open door for clients to obtain access = to protected user data by lying about their identity to authorization = servers. They can achieve this in either of two ways, given some = popular client_id we'll arbitrarily call 'facebook' that users are = accustomed to authorizing access to: > =95 An evil client can redirect the user to the authorization = endpoint, requesting an implicit grant, and including client_id=3Dfacebook= in the URL. The authorization server may ask the user "Do you want to = give Facebook access?" along with (perhaps) a warning that most users = won't know what to do about (honestly, most technical users wouldn't = know how to verify either. The user, who trusts Facebook, will click = Accept, and offer whatever rogue client was running on the page they = were visiting the access that they requested. > =95 In scenario 2, which is far worse, an evil client can = redirect the user to the authorization endpoint, requesting an implicit = grant, and including client_id=3Dfacebook in the URL. Same so far, but = in this case, the authorization server sees that access has already been = authorized by the resource owner to this client in the past and = immediately redirects back with the requested access token, no user = involvement whatsoever. Again, the client obtains access. > Now, one might say to #2 that authorization servers shouldn't = automatically authorize implicit requests. That person would be = absolutely right. I'm concerned that enough clients will complain about = the user experience though that authorization servers will yield to them = and begin auto-authorizing these, justifying it by making the "limited" = access tokens. No go. Either you have protected data or you don't. =20 > To #1, there's no way that I can think of to properly educate the user = to be able to detect a phishing attack of this nature, such that if they = see a "do you want to authorize facebook?" when there is no facebook = widget on the page, that they should deny access. =20 > =20 > Between those two, I see only negative impact to including client_id = in implicit grant requests. Please, will someone either address my = concerns (tell me where I'm wrong) or remove that parameter from this = grant type? > =20 > Thanks for your time. > =20 > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the = death your right to say it." - S. G. Tallentyre > We're hiring! My team at Microsoft has 7 open slots. = http://bit.ly/fZBVUo > =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 From andrewarnott@gmail.com Tue Apr 12 19:45:35 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 076EFE0687 for ; Tue, 12 Apr 2011 19:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeY+uBbg5bKg for ; Tue, 12 Apr 2011 19:45:32 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfc.amsl.com (Postfix) with ESMTP id A286CE0670 for ; Tue, 12 Apr 2011 19:45:32 -0700 (PDT) Received: by qyk7 with SMTP id 7so107921qyk.10 for ; Tue, 12 Apr 2011 19:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fcK94Ygm/OvCwHwklxuxgq1jCzC5EI8skNxkIElUKOU=; b=SN4ROGKM9OncnfzDrCvycnx9KCSOSzHCzMW1hSonA7dG5MXWj7jz8kc50Be1bzWAnM JgbwNqfVcraKZqCfikITJrRzSJZvl2QCqzMvdVem8EhL93xvaajdAg+yoqxjK4VpFq2P DHSPEnNY0oSAY4zVoagaSTvQDJ6jNkqcaHb6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WwJ2Z2k0fLhjy6mKd1m83/uTSx9OYjy+6KqIhieK2HS4gpDoic5EcIIwM2BQ7JEchS ykaMGERob5ghI8PKqRvsnVP/+Dmc2evhw53C30dn3EcR0hccS/QvtbWezXTo/E5fIRVL 7qQ77vTPvrprDXamBhXKoQ03kOAYu3JGd/CKE= MIME-Version: 1.0 Received: by 10.224.182.75 with SMTP id cb11mr3589809qab.125.1302662730542; Tue, 12 Apr 2011 19:45:30 -0700 (PDT) Received: by 10.229.73.141 with HTTP; Tue, 12 Apr 2011 19:45:30 -0700 (PDT) In-Reply-To: <441CA9C9-E3BA-4DCA-AD69-473660EE93F9@kiva.org> References: <90C41DD21FB7C64BB94121FBBC2E72344656743B2E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72344656743B5E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DA475AE.9030106@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72344656743B7D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <441CA9C9-E3BA-4DCA-AD69-473660EE93F9@kiva.org> Date: Tue, 12 Apr 2011 19:45:30 -0700 Message-ID: From: Andrew Arnott To: Skylar Woodward Content-Type: multipart/alternative; boundary=20cf303b42db50ee6a04a0c3cd59 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] client authentication for implicit grant type 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, 13 Apr 2011 02:45:35 -0000 --20cf303b42db50ee6a04a0c3cd59 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, Skylar. Eran's and your comments do alleviate my concerns somewhat= . In reviewing the security considerations text, which I hadn't seen this morning when writing my earlier email, I feel *much* better. My favorite part is this: Authorization servers MUST NOT automatically process (without user interaction) repeated authorizations without authenticating the client. > > > By the way, a colleague at Microsoft pointed out that my email signature ma= y lead others on this list to believe I represent Microsoft in my participation on this list. I *do not represent Microsoft* in my participation here. I act as a lone developer. I apologize for any confusion. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Tue, Apr 12, 2011 at 3:25 PM, Skylar Woodward wrote: > Just as a response to Andrew, the concern is valid, and providers should = be > educated to warn users about the possibility of a forged identity. This > risk for forgery is actually possible for clients with and without secret= s. > Anyone can spoof either type if the client ID is known, thus showing th= e > approval dialog on the authorization endpoint. The only difference is th= at > the auth code returned will be useless to the phisher in the case of a > client with a secret. > > To this point, we always warn our users not to approve an app unless they > trust the application that spawned the approval dialog. We emphasize thi= s > warning even more when a client_id is presented which can't later validat= e > the identity through use of a secret. > > As a result of how hard it is to guarantee client identity in these cases= , > I think you'll find many providers downplay the identity in approval > dialogs. The page title often reads something generic like "An applicatio= n > is requesting access to your account" followed then by details of the app= . > We've refrained from displaying the name or icon too prominently in the = top > or title of the page for this reason. Certainly, this is kind of guidanc= e > to providers is important for the security notes as well as the UI > considerations. > > So, while identity may seem hopeless in theory, it's actually useful as a > context check, as Eran suggests. (John's App? why is that asking for > permission from this online pharma store?) Moreover, its useful to > providers in terms of tracking app usage because in practice, there is ve= ry > little to be gained in forging an app's identity. You might as well make > your own convincing looking app name and icon. Regardless the challenge > remains for the providers to track abuse of the API and user data, be it > from well-meaning apps, sneaky malicious apps, or mischievous apps > masquerading as someone else. > > skylar > > > On Apr 12, 2011, at 9:28 AM, Eran Hammer-Lahav wrote: > > > Hopefully by the end of the week. My farm took all my free time this > weekend. > > > > EHL > > > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > Sent: Tuesday, April 12, 2011 8:54 AM > > To: Eran Hammer-Lahav > > Cc: Andrew Arnott; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] client authentication for implicit grant type > > > > The proposed text already does ( > http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations= -02 > ). > > > > When will you post the new revision of the core draft that includes the > proposed text? > > > > regards, > > Torsten. > > > > Am 12.04.2011 17:50, schrieb Eran Hammer-Lahav: > > It should include a section on phishing-like attacks. > > > > EHL > > > > From: Andrew Arnott [mailto:andrewarnott@gmail.com] > > Sent: Tuesday, April 12, 2011 8:30 AM > > To: Eran Hammer-Lahav > > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] client authentication for implicit grant type > > > > Thanks, Eran. Will the security considerations section discuss this an= d > recommend that auth servers warn the users of the potential phishing atta= ck? > > > > -- > > Andrew Arnott > > "I [may] not agree with what you have to say, but I'll defend to the > death your right to say it." - S. G. Tallentyre > > We're hiring! My team at Microsoft has 7 open slots. > http://bit.ly/fZBVUo > > > > > > > > > > On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav > wrote: > > I don=92t think there is much we can do either way to prevent these > phishing-like attacks with or without the client identifier. The key to > security here is the ability of the end-user to keep track of how it got > there, and based on that decide if they want to grant access to whoever s= ent > them to the authorization endpoint. This is the same problem with phishin= g =96 > the user ends up in a login page and unless they pay attention how they g= o > there (and where they are if its possible to assert), they will give the > attacker their password. > > > > If you don=92t include the client identifier and won=92t give them a hi= nt > =93John=92s App wants access=94, they will just get used to approving it = without > the hint. At the end of the day, if there is value in approving such > unidentified clients, end-users will do it regardless of security. > > > > EHL > > > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Andrew Arnott > > Sent: Tuesday, April 12, 2011 7:28 AM > > To: OAuth WG (oauth@ietf.org) > > Subject: [OAUTH-WG] client authentication for implicit grant type > > > > I brought this concern up about a year ago. Now reviewing the latest > drafts, I still have a concern with it. It is regarding the use of > client_id without a password. I agree with section 3, as included below: > > > > Section 3. Client Authentication > > > > The client identifier is not a secret, it is exposed to the resource > > owner, and MUST NOT be used alone for client authentication. Client > > authentication is accomplished via additional means such as a > > matching client password. > > > > The above tells me (rightly so IMO) that considering the client_id alon= e > (without real authentication) is dangerous. Yet the Implicit Grant type > accepts a client_id, but no authentication: > > > > Section 4.2 Implicit Grant > > > > client_id > > REQUIRED. The client identifier as described in Section 3. > > Now here me: I am not advocating for a client_secret in this case. I > fully understand that some clients, particularly javascript widget client= s > that are embedded in others' web pages, can't keep secrets. What I am > advocating is that clients that can't keep secrets shouldn't have IDs > either. This is a wide-open door for clients to obtain access to protect= ed > user data by lying about their identity to authorization servers. They c= an > achieve this in either of two ways, given some popular client_id we'll > arbitrarily call 'facebook' that users are accustomed to authorizing acce= ss > to: > > =95 An evil client can redirect the user to the authorization > endpoint, requesting an implicit grant, and including client_id=3Dfaceboo= k in > the URL. The authorization server may ask the user "Do you want to give > Facebook access?" along with (perhaps) a warning that most users won't kn= ow > what to do about (honestly, most technical users wouldn't know how to ver= ify > either. The user, who trusts Facebook, will click Accept, and offer > whatever rogue client was running on the page they were visiting the acce= ss > that they requested. > > =95 In scenario 2, which is far worse, an evil client can redirec= t > the user to the authorization endpoint, requesting an implicit grant, and > including client_id=3Dfacebook in the URL. Same so far, but in this case= , the > authorization server sees that access has already been authorized by the > resource owner to this client in the past and immediately redirects back > with the requested access token, no user involvement whatsoever. Again, = the > client obtains access. > > Now, one might say to #2 that authorization servers shouldn't > automatically authorize implicit requests. That person would be absolute= ly > right. I'm concerned that enough clients will complain about the user > experience though that authorization servers will yield to them and begin > auto-authorizing these, justifying it by making the "limited" access toke= ns. > No go. Either you have protected data or you don't. > > To #1, there's no way that I can think of to properly educate the user = to > be able to detect a phishing attack of this nature, such that if they see= a > "do you want to authorize facebook?" when there is no facebook widget on = the > page, that they should deny access. > > > > Between those two, I see only negative impact to including client_id in > implicit grant requests. Please, will someone either address my concerns > (tell me where I'm wrong) or remove that parameter from this grant type? > > > > Thanks for your time. > > > > -- > > Andrew Arnott > > "I [may] not agree with what you have to say, but I'll defend to the > death your right to say it." - S. G. Tallentyre > > We're hiring! My team at Microsoft has 7 open slots. > http://bit.ly/fZBVUo > > > > > > > > > > _______________________________________________ > > OAuth mailing 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 > --20cf303b42db50ee6a04a0c3cd59 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, Skylar. =A0Eran's and your comments do alleviate my concerns so= mewhat. =A0In reviewing the security considerations text, which I hadn'= t seen this morning when writing my earlier email, I feel much=A0bet= ter. =A0My favorite part is this:

Authorizat=
ion servers MUST NOT automatically process (without user interaction) repea=
ted authorizations without authenticating the client.


By the way, a = colleague at Microsoft pointed out that my email signature may lead others = on this list to believe I represent Microsoft in my participation on this l= ist. =A0I do not represent Microsoft=A0in my participation here. =A0= I act as a lone developer. =A0I apologize for any confusion.

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



On Tue, Apr 12, 2011 at 3:25 PM, Skylar = Woodward <skylar@ki= va.org> wrote:
Just as a response to Andrew, the concern is valid, and providers should be= educated to warn users about the possibility of a forged identity. =A0This= risk for forgery is actually possible for clients with and without secrets= . =A0 Anyone can spoof either type if the client ID is known, thus showing = the approval dialog on the authorization endpoint. =A0The only difference i= s that the auth code returned will be useless to the phisher in the case of= a client with a secret.

To this point, we always warn our users not to approve an app unless they t= rust the application that spawned the approval dialog. =A0We emphasize this= warning even more when a client_id is presented which can't later vali= date the identity through use of a secret.

As a result of how hard it is to guarantee client identity in these cases, = I think you'll find many providers downplay the identity in approval di= alogs. The page title often reads something generic like "An applicati= on is requesting access to your account" followed then by details of t= he app. =A0We've refrained from displaying the name or icon too promine= ntly in the top or title of the page for this reason. =A0Certainly, this is= kind of guidance to providers is important for the security notes as well = as the UI considerations.

So, while identity may seem hopeless in theory, it's actually useful as= a context check, as Eran suggests. =A0(John's App? why is that asking = for permission from this online pharma store?) =A0Moreover, its useful to p= roviders in terms of tracking app usage because in practice, there is very = little to be gained in forging an app's identity. =A0You might as well = make your own convincing looking app name and icon. =A0Regardless the chall= enge remains for the providers to track abuse of the API and user data, be = it from well-meaning apps, sneaky malicious apps, or mischievous apps masqu= erading as someone else.

skylar


On Apr 12, 2011, at 9:28 AM, Eran Hammer-Lahav wrote:

> Hopefully by the end of the week. My farm took all my free time this w= eekend.
>
> EHL
>
> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> Sent: Tuesday, April 12, 2011 8:54 AM
> To: Eran Hammer-Lahav
> Cc: Andrew Arnott; OAuth WG (oauth@i= etf.org)
> Subject: Re: [OAUTH-WG] client authentication for implicit grant type<= br> >
> The proposed text already does (http:/= /tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02)= .
>
> When will you post the new revision of the core draft that includes th= e proposed text?
>
> regards,
> Torsten.
>
> Am 12.04.2011 17:50, schrieb Eran Hammer-Lahav:
> It should include a section on phishing-like attacks.
>
> EHL
>
> From: Andrew Arnott [mailto:= andrewarnott@gmail.com]
> Sent: Tuesday, April 12, 2011 8:30 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] client authentication for implicit grant type<= br> >
> Thanks, Eran. =A0Will the security considerations section discuss this= and recommend that auth servers warn the users of the potential phishing a= ttack?
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend= to the death your right to say it." - S. G. Tallentyre
> We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo
>
>
>
>
> On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I don=92t think there is much we can do either way to prevent these ph= ishing-like attacks with or without the client identifier. The key to secur= ity here is the ability of the end-user to keep track of how it got there, = and based on that decide if they want to grant access to whoever sent them = to the authorization endpoint. This is the same problem with phishing =96 t= he user ends up in a login page and unless they pay attention how they go t= here (and where they are if its possible to assert), they will give the att= acker their password.
>
> If you don=92t include the client identifier and won=92t give them a h= int =93John=92s App wants access=94, they will just get used to approving i= t without the hint. At the end of the day, if there is value in approving s= uch unidentified clients, end-users will do it regardless of security.
>
> EHL
>
>
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf Of Andrew Arnott
> Sent: Tuesday, April 12, 2011 7:28 AM
> To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] client authentication for implicit grant type
>
> I brought this concern up about a year ago. =A0Now reviewing the lates= t drafts, I still have a concern with it. =A0It is regarding the use of cli= ent_id without a password. =A0I agree with section 3, as included below: >
> Section 3. Client Authentication
>
> The client identifier is not a secret, it is exposed to the resource > owner, and MUST NOT be used alone for client authentication. Client > authentication is accomplished via additional means such as a
> matching client password.
>
> The above tells me (rightly so IMO) that considering the client_id alo= ne (without real authentication) is dangerous. =A0Yet the Implicit Grant ty= pe accepts a client_id, but no authentication:
>
> Section 4.2 Implicit Grant
>
> client_id
> REQUIRED. The client identifier as described in Section 3.
> Now here me: I am not advocating for a client_secret in this case. =A0= I fully understand that some clients, particularly javascript widget client= s that are embedded in others' web pages, can't keep secrets. =A0Wh= at I am advocating is that =A0clients that can't keep secrets shouldn&#= 39;t have IDs either. =A0This is a wide-open door for clients to obtain acc= ess to protected user data by lying about their identity to authorization s= ervers. =A0They can achieve this in either of two ways, given some popular = client_id we'll arbitrarily call 'facebook' that users are accu= stomed to authorizing access to:
> =A0 =A0 =A0 =95 An evil client can redirect the user to the authorizat= ion endpoint, requesting an implicit grant, and including client_id=3Dfaceb= ook in the URL. =A0The authorization server may ask the user "Do you w= ant to give Facebook access?" along with (perhaps) a warning that most= users won't know what to do about (honestly, most technical users woul= dn't know how to verify either. =A0The user, who trusts Facebook, will = click Accept, and offer whatever rogue client was running on the page they = were visiting the access that they requested.
> =A0 =A0 =A0 =95 In scenario 2, which is far worse, an evil client can = redirect the user to the authorization endpoint, requesting an implicit gra= nt, and including client_id=3Dfacebook in the URL. =A0Same so far, but in t= his case, the authorization server sees that access has already been author= ized by the resource owner to this client in the past and immediately redir= ects back with the requested access token, no user involvement whatsoever. = =A0Again, the client obtains access.
> Now, one might say to #2 that authorization servers shouldn't auto= matically authorize implicit requests. =A0That person would be absolutely r= ight. =A0I'm concerned that enough clients will complain about the user= experience though that authorization servers will yield to them and begin = auto-authorizing these, justifying it by making the "limited" acc= ess tokens. =A0No go. =A0Either you have protected data or you don't. > To #1, there's no way that I can think of to properly educate the = user to be able to detect a phishing attack of this nature, such that if th= ey see a "do you want to authorize facebook?" when there is no fa= cebook widget on the page, that they should deny access.
>
> Between those two, I see only negative impact to including client_id i= n implicit grant requests. =A0Please, will someone either address my concer= ns (tell me where I'm wrong) or remove that parameter from this grant t= ype?
>
> Thanks for your time.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend= to the death your right to say it." - S. G. Tallentyre
> We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo
>
>
>
>
> _______________________________________________
> OAuth mailing 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
h= ttps://www.ietf.org/mailman/listinfo/oauth

--20cf303b42db50ee6a04a0c3cd59-- From stephen.farrell@cs.tcd.ie Wed Apr 13 12:10:12 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B46D4E07CC for ; Wed, 13 Apr 2011 12:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5Rf9CnF7ojR for ; Wed, 13 Apr 2011 12:10:12 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id D9791E078F for ; Wed, 13 Apr 2011 12:10:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EE426171C74; Wed, 13 Apr 2011 20:10:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1302721808; bh=VdxGhH65rRmfac1YN5Fk7m4r NgcUltZ35i/iK4UV8oY=; b=JU7x0yKbh/s0XaZjLQvdHBSwP5Lq0gghtfERLuW3 EEntAwS0xE3NMgw+qjSod2YHFnH8FFALwqDIurCu4mUb12nySIL0WSgPy26SnYrf L0LJzs9PNrADN4gHJ3ts1d6SrdOwtbhyXw2+M6QXU0MXCxd6Qa4Pk5Bka+P6P1Oa lHnRx++gDCb+uepR/PVUecb01t4wK3AnnmtViWctxkDkfnbKf3Qgg6d0urKfbu8m b4/YTvvlj43KE6cpAoBF+8mCr094KkOplt8e5Vuq54fsD3osSU2CEvUtBL2gPqGg HsM73JFHUxHhsyAi1EvAzq04eYkhCU5TkKQTYBY3WjrzSw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id jcVojhRUnNwI; Wed, 13 Apr 2011 20:10:08 +0100 (IST) Received: from [10.87.48.4] (unknown [86.45.59.143]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5DB66171C73; Wed, 13 Apr 2011 20:10:08 +0100 (IST) Message-ID: <4DA5F50F.6050109@cs.tcd.ie> Date: Wed, 13 Apr 2011 20:10:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Barry Leiba Subject: [OAUTH-WG] 3rd oauth co-chair - Barry Leiba 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, 13 Apr 2011 19:10:12 -0000 Hi all, After chatting with Hannes and Blaine in Prague we figured that it might help to get a 3rd co-chair for oauth to get the wg over the line with the base spec and thereafter. Well, we got lucky, so I'm glad to say Barry Leiba has agreed to take on the role alongside Hannes and Blaine. Barry has a lot of experience in chairing IETF working groups, including some with significant mail volumes like oauth and also has a great fit of IETF apps/security knowledge both of which should also help a lot. I've just mailed the secretariat adding Barry so it might take a day or so for things to show up on the WG page. I'm sure you'll join me, Hannes and Blaine in welcoming Barry and wishing him all the best in helping us all get oauth done. (And then we'll immediately start hassling him about stuff:-) Regards, Stephen. From zachary.zeltsan@alcatel-lucent.com Wed Apr 13 12:55:13 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 66B26E085D for ; Wed, 13 Apr 2011 12:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atKpqSK-3c5P for ; Wed, 13 Apr 2011 12:55:12 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfc.amsl.com (Postfix) with ESMTP id AE257E07CB for ; Wed, 13 Apr 2011 12:55:12 -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 p3DJt3bK003552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Apr 2011 14:55:04 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3DJt3l4005223 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Apr 2011 14:55:03 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 13 Apr 2011 14:55:03 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Stephen Farrell'" , "oauth@ietf.org" Date: Wed, 13 Apr 2011 14:55:01 -0500 Thread-Topic: [OAUTH-WG] 3rd oauth co-chair - Barry Leiba Thread-Index: Acv6DnY04G6BdMgVQ2KsrNxdQVZ2KQABCJqQ Message-ID: <5710F82C0E73B04FA559560098BF95B12505F041CB@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4DA5F50F.6050109@cs.tcd.ie> In-Reply-To: <4DA5F50F.6050109@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: Barry Leiba Subject: Re: [OAUTH-WG] 3rd oauth co-chair - Barry Leiba 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, 13 Apr 2011 19:55:13 -0000 I have been involved with MARF WG, which Barry co-Chairs, and am sure that = this appointment is a good news for OAUTH. Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of S= tephen Farrell Sent: Wednesday, April 13, 2011 3:10 PM To: oauth@ietf.org Cc: Barry Leiba Subject: [OAUTH-WG] 3rd oauth co-chair - Barry Leiba Hi all, After chatting with Hannes and Blaine in Prague we figured that it might help to get a 3rd co-chair for oauth to get the wg over the line with the base spec and thereafter. Well, we got lucky, so I'm glad to say Barry Leiba has agreed to take on the role alongside Hannes and Blaine. Barry has a lot of experience in chairing IETF working groups, including some with significant mail volumes like oauth and also has a great fit of IETF apps/security knowledge both of which should also help a lot. I've just mailed the secretariat adding Barry so it might take a day or so for things to show up on the WG page. I'm sure you'll join me, Hannes and Blaine in welcoming Barry and wishing him all the best in helping us all get oauth done. (And then we'll immediately start hassling him about stuff:-) Regards, Stephen. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Wed Apr 13 13:13:26 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D4EC2E0839 for ; Wed, 13 Apr 2011 13:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P99Zh4WyjLyp for ; Wed, 13 Apr 2011 13:13:26 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id EB6EDE082D for ; Wed, 13 Apr 2011 13:13:25 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5EE6540D20; Wed, 13 Apr 2011 14:16:26 -0600 (MDT) Message-ID: <4DA603E1.6040707@stpeter.im> Date: Wed, 13 Apr 2011 14:13:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Zeltsan, Zachary (Zachary)" References: <4DA5F50F.6050109@cs.tcd.ie> <5710F82C0E73B04FA559560098BF95B12505F041CB@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B12505F041CB@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090603030005040500040407" Cc: Barry Leiba , "oauth@ietf.org" Subject: Re: [OAUTH-WG] 3rd oauth co-chair - Barry Leiba 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, 13 Apr 2011 20:13:27 -0000 This is a cryptographically signed message in MIME format. --------------ms090603030005040500040407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1, Barry is very good. On 4/13/11 1:55 PM, Zeltsan, Zachary (Zachary) wrote: > I have been involved with MARF WG, which Barry co-Chairs, and am sure t= hat this appointment is a good news for OAUTH. >=20 > Zachary >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Stephen Farrell > Sent: Wednesday, April 13, 2011 3:10 PM > To: oauth@ietf.org > Cc: Barry Leiba > Subject: [OAUTH-WG] 3rd oauth co-chair - Barry Leiba >=20 >=20 > Hi all, >=20 > After chatting with Hannes and Blaine in Prague we figured that > it might help to get a 3rd co-chair for oauth to get the wg over > the line with the base spec and thereafter. Well, we got lucky, > so I'm glad to say Barry Leiba has agreed to take on the role > alongside Hannes and Blaine. >=20 > Barry has a lot of experience in chairing IETF working groups, > including some with significant mail volumes like oauth > and also has a great fit of IETF apps/security knowledge both > of which should also help a lot. >=20 > I've just mailed the secretariat adding Barry so it might take > a day or so for things to show up on the WG page. >=20 > I'm sure you'll join me, Hannes and Blaine in welcoming Barry > and wishing him all the best in helping us all get oauth done. > (And then we'll immediately start hassling him about stuff:-) >=20 > Regards, > Stephen. >=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 --------------ms090603030005040500040407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQx MzIwMTMyMVowIwYJKoZIhvcNAQkEMRYEFMhrQVIj264mQhQdHa5AdsquBeRdMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBuKsYuSzq/B7l+ezr+OX5JoJagEee0jru+ZFjh0ZgnIuYyVXhhkHuZa3WR PvxQ0Gxv/Hvn2sb5Bz3FxmXckvGxmyWkqcIrMTR9W8vLKm5UEM/cKAx+v7wkjMxcgm5ByYyC wlVXPUSoCfpN/LpvXo6nNRsTl3yX255dE876FyXxvLpNVoVophYILd+TBgjSKt4Ejmgh+EwT bGTGv3dGh0tHQuyt7uv7qyRadUxUgZDTPykuesxqPsUvA+fzvX8L9o1yLLcjY5LyW74pIK5d eCc4nV2Zjo2SRBeFh+FsUpowCUsR8wXMrBJr3smsY5DtN3GE+jhtsxgnJvrqAY747JB4AAAA AAAA --------------ms090603030005040500040407-- From bcampbell@pingidentity.com Thu Apr 14 12:20:28 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C9D54E08B3 for ; Thu, 14 Apr 2011 12:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciKuQuJWFk+w for ; Thu, 14 Apr 2011 12:20:27 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfc.amsl.com (Postfix) with ESMTP id 0E1C9E07A8 for ; Thu, 14 Apr 2011 12:20:26 -0700 (PDT) Received: from mail-px0-f177.google.com ([209.85.212.177]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKTadI9w4N1XM1wRucpFLD+hOiX66Gz6gN@postini.com; Thu, 14 Apr 2011 12:20:27 PDT Received: by mail-px0-f177.google.com with SMTP id 10so829575pxi.22 for ; Thu, 14 Apr 2011 12:20:23 -0700 (PDT) Received: by 10.68.52.129 with SMTP id t1mr718474pbo.525.1302808823093; Thu, 14 Apr 2011 12:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.47.105 with HTTP; Thu, 14 Apr 2011 12:19:53 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 14 Apr 2011 13:19:53 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Fwd: OAuth spec typo 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, 14 Apr 2011 19:20:29 -0000 There's tiny little typo in http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.1.3 where "parameter" should be "parameters" ---------- Forwarded message ---------- From: Peter Motykowski Date: Thu, Apr 14, 2011 at 9:56 AM Subject: OAuth spec typo To: Brian Campbell Section 4.1.3 - The first paragraph should read "by adding the following parameters" since there are three required parameters. Thanks, Peter From hardjono@mit.edu Thu Apr 14 13:17:38 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 284AFE0737 for ; Thu, 14 Apr 2011 13:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsIJ1SSvHcL4 for ; Thu, 14 Apr 2011 13:17:37 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by ietfc.amsl.com (Postfix) with ESMTP id C7681E06B8 for ; Thu, 14 Apr 2011 13:17:36 -0700 (PDT) X-AuditID: 1209190e-b7c80ae0000047dd-a9-4da756666890 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 26.E8.18397.66657AD4; Thu, 14 Apr 2011 16:17:42 -0400 (EDT) Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p3EKHZaj008393; Thu, 14 Apr 2011 16:17:35 -0400 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id p3EKGH0j005578; Thu, 14 Apr 2011 16:16:57 -0400 Received: from w92exhub9.exchange.mit.edu (18.7.73.17) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 14 Apr 2011 16:14:53 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub9.exchange.mit.edu ([18.7.73.17]) with mapi; Thu, 14 Apr 2011 16:16:42 -0400 From: Thomas Hardjono To: oauth , Eran Hammer-Lahav Date: Thu, 14 Apr 2011 16:16:40 -0400 Thread-Topic: Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005E_01CBFABF.56205C50" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA2WTe0gUURTGubOz47g4Nq2re7QXDaQR7JbYQyoj6SWGPaAi+sMa3dFd2h1l ZzW3B9mDtDXNLDEXo0JLMUvMfKWZSharpRsI0TvDDC2NFqwsjGYaX+B/3z3f737nHLiXVKjd RBBp4m2clWfNDKHC1V7rQnQJe0pjljUOhIR3Xi9G4a6hQWI9FlXQvj2qpGQU24HtU601cGZT Kmdduu6AyvjoXr8y2XkepVU11CjS0cezyIG8SaCXQ0P3yXEdAO53lYQDqUg13YzgTo4Lkw8t CNI/DyvlQw+Cpr6LSD7UIHjd/2T8Ti6C4rdZmBRG0Iuh688DLwciSQ29AfrHEqSygg6G6leZ SqmM04vA84uWyn50EDgqXEpJa+gF0FPzA5dv6iG/MFKSFL0DHGV6iUDioD87KjA5UAuv+q5i 8gIa6H3eSUws8/d+LyHz/vAmo/L/xAo6G0H37SJcMih6NrgK+/BcFOCcluWczjmncU5xDgW9 G+66NTK/DN63ZSplvQDqhooUst4I9debxusL4VJWr5esI6Di9DCSY6Kg41TsTCQSTufU4rJe A5d/txIzmRXwpf07uoZmlaN5BsthnYU1mQUuXifEszzPWXVheovJpucMKXeR9Fi8A33r0Ugr 04ZoEjE+1NP5pTFqJZsq2C1tKJDEGH/Ks0ss+cYlGexGVjDut6aYOaENAalgNFT24M0YNWVg 7Yc5a9KENYfEGS1VGBgSo6YTWRt3kOOSOeuEO5ckGaAGdouhs61cIpeWYDLbpmyM9JbCfcTw LomhhGTWIpgSZb8D6UiP52szUuN8Es8FaaliCaIlyJjCT+ZMfIRBpBXX8qN6JMpH/CaTSYNi E0xscpD538TGTllB6YjPOOG2h+pT+ZXaVkd7dkNEVZ3ftm8jay5sZfnujOGh+eeUR9I+Pj46 0nyiUnVsaLvrSYAm73h036aIzVs6s3e+rAocbcQvP1sbtzrpyqqXnppDwXuV9k+q8OAuW0vd wzL7mfJ87Q3ji1sFY/pa04fuvAGiOjckujJvoZuPjQ5TvWZwwciGLlFYBfYfDlouFOMDAAA= Subject: [OAUTH-WG] Revised Section 3 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, 14 Apr 2011 20:17:38 -0000 ------=_NextPart_000_005E_01CBFABF.56205C50 Content-Type: multipart/mixed; boundary="----=_NextPart_001_005F_01CBFABF.56205C50" ------=_NextPart_001_005F_01CBFABF.56205C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Eran, Folks, Per my promise at the last IETF80 to improve the text for Section 3, attached is the XML version and TXT file. As you will see, I did not introduce any major changes but only clarifications and explanations. I used the text from draft-11, which I believe has the more complete text. Since many/most shared secret schemes are not assertion-based schemes, I split Section 3.2 into two new sections: - one section on shared secret schemes (eg. EKE, PAKE, OTP, etc, etc numerous) - another section on assertions proper. The additional references are located at the end of the attached TXT file. Hope these changes are acceptable. cheers, /thomas/ __________________________________________ Thomas Hardjono MIT Kerberos Consortium email: hardjono[at]mit.edu desk: +1 617-715-2451 __________________________________________ ------=_NextPart_001_005F_01CBFABF.56205C50 Content-Type: application/x-zip-compressed; name="Section3-TH.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Section3-TH.zip" UEsDBBQAAAAIAHGAjj6OZC1J1QwAAE8kAAAPAAAAU2VjdGlvbjMtVEgudHh01VpbUxtHFn5PVf5D l7echSppQMIkNlt+EEIsxMYoSI6zcVGu1kxL6jC3dPeA5V+/3+nLzOgW52FTu2u7wGi6z/U71+Hj u9vp6IxNxWfD5oViZinwPU2LJ5kv2ETERhY5O2FSsxnXImH46XbwfnrFEsXnptvr3X/7Df09iRgb plLkhg2VSPBd8lTTE8bYh6XImcyNUBwEQfhJmqXlxSuzLJT8wi0fLdSjUB37JHbEpCU1l0JbStJo kc5ZpYkKxwXDink4GzeM2dNSxkvwjNMqARt/xNEIJBXjOTQCN8VKVZRCGfCxdvAUSTw6HFv5oOIU kmWC504as1RFtVh6Zi2pi5nhMtck7ppUXAk2E6sCbOm0jsHUUoISZgkj61LEEC3wmxSZ2BCC2fM6 XooMsirxeyVBtMXbFKzKE6EWBZ4upDbK3Qs2t/d32T3y3rqoBBEhkjk3FahDOk2SOA66s/O6ZpOr 2/dvLxggZelk/AHCa11lJR2D9rOiMk7UIp9LbxVpVi0fagF7wWokLU5bQkIbPkulXpLTjaq0aQDk rsEzg5QuwBnSEFoTOYcZq9TB2tnMiwnduI7hbLjIuUHElSIxYl7ymYREBINaJuiLgwuRA74p22u+ tv6QQFdiUycw9hQJmMQrFSy4/0GI0uq3FFLVV9qGCv6Z7okbdjP4Vxssa6jwEZOvnPwl4V1JOhRi qA1T4HMDdR5wLgQsDU/45v1k6lT2sZYVFo88R67YSb1QtQ1bDDIR447UmfOt4IgoQjecHxSvXbxb Niu2Mx+0M0VcpExmZYpnueEOgo4zQbqyctkI7OyIPQguHqzLdFWWhUIuYDNV8CRgKfW5EUT2iAMb GMsL6FJ4nq5YIsq0WAlPxBQJX3mpcTTDDzPRnPHonFcUg1FIs70m0Y4RXE+FSnZkXH+iDCfa9q80 JUS9hGgJ06ssE0bJ2EMOQm16p40jnwI3k7PLpDU3UHaZ1kGiVsX704ORPrmaTsfsnGvw32lFRKql lIi5zB2hj3eXw/73vR/u2WzlOQRqO8TSdcqD2irnRBKixhv2cefqnwPiLpE7xGdOIGIHKSQABgR/ cImcEksidZnCb2WlykJT1sjT1eGZcxajP+NbxMeRKR5QAknbo17U84+uCm3OQvL1bKK4yPzjQTvG z7yV4i+/Dvk/7yb85PL45kuZf7i4zH7K8P/+jx/8vWGBSpub7nRVijMK9dTb9Ohz9+npqQu5s26l UpHHBZxTS7pQPDefDG69Xksvn+jYd/Tltex90Hd5rzrvfecvAUOoP7H5hAz6emlMqZ+fDJ73L/HP 2fh5f+RVw/+gHD2Y1fZBSJNXjHwU6Wqt8FMyCyml7ZoNLFkqsyJZtUDVNDAlV/A4WOgzz9BR/yQT Lz/9uRv99P76bnSxD9zR+l0fKHuu/U9B6C+CQrDha/39+TK5e/jdnAQ8rNno9eKX3vycm5PZz38R fvbXQipLPI5FadqoWs+DgIjHj6mLTQszoaB8NUtFX5EFUK6rSJJIeoZOYp2UKyu+dOhKGtsdhJ4c TVyuM3QVvuTsSux1iegDkROX3icOq9sF4tx1oZt5sEXORiMwisoYSt+cZxJVzBLYX/fqQYEEz4tQ JUPBcZ0NRLRkru0xLVpVE7GuZMYVSqPMiH0wQtPgor4/+tYJMYOgCXahY2uMIs8hFGE/vfSjY+qt DOaejq/o7VtbTTu1k8Len6sio66WhgXwbB+0dA7QOKCMIwEdulSFym7t2NIgKaAoLMOW/NH22k4T KCVpWMlXDQNql3ANloDJ7DH75QN6pNAfOKf8SX+UXKonqUWjNOVJck9oUq2wpDNnj3gqXHseOirf 1ljBXewIZKXQs7hUCOohc6OnS5FdFqKrhC6hjmhRovsHIlpEbHg1GNvC3nv16sX9YacGZLfdhyRo kmGahRK2paut5sk5UqM3I1AaXd4f2vAlFYpKM5GhSEi6pmv8kj3Qo3YNPm9C4OB2Oj7cImu7jv7L V/eHrTZcbw1n68ptdZq757wOm+GMDGZsdHMybnMJnrWdcg1oVz7XM5Dz8n8nJYa/J9FJ3ZAO6sDZ TkmUP8GjHV0HAL+WC+r86g8PIdY8zHEMo6FxaAhjng0WNNNAHxpE7gZGQVJLRT2qAqAxGHOVuB3C Ar0HpK5mv6EMebeZ+vOssMQp1oCSiKGSQtE0pb69JaidOBdI2mnIj15s6lFp3qN5UBEZQAz/8TmM wl0XlYpFA3QaRJ0UeWKXJgs7mxKy3MgRkaXqGM2rbAaCgMqjWMo49QsMS4EctT4B2TRR55aQhEeu wOo6bH+JTo9f1Tax46DBkACYAjZ02UJXeJRTbJz0Xx538P30h9PT+w6bDG7e2iTbSmQfbweT60mk eZZ2YwyJXTzvFvreJ+ChTXLhlMxk13VgZtXtRcc49UYoaFpoi2cZAywyfqCURfxf9PrH980+p1Zt aufBkL5jKjC1BwFJ303aiTvjZH40a6WiggLv41uoDisYMKbHaEFgqs/kEuKm5RcRMsK134116vXR zjLR5HnwQntma1dZyBD1gEyzUNrZUMSEvfaAFvZbdPeRpzLhds3mYLQVQQ6NiQ+PVlgcbBxRh159 v03TdTDhqs0QrTwSMsPe1ZKlNAjHM1rjuD3Zeigd6Aq8/NzHHZL2QaedFVxhzjfVdMsGRASN1+Dl FlmcGm1aJXbdpqZ9rwUdCqWMm1As6iMd36YUABQK7KplpM204FQUSac2EDLpskhsxDau4q4BbK7a rsNPvbD2GvuQTnaavJXyHc9dS8d9C8er4knYi2s5pBlN5vtB2VLG5h0fvHTHu9J5vrOhC0UbPm7U 9ADx2zTq0ggjITGngmtXv5oxT+bOTyAX5rwC4diSoKEb7XvsbFo/vqm9tFHfKt2I6v0QOji2d2/C Du5Gw9ubm9G7i9HFYc1kSp3HNos1gTd4fYXQGkQ4Ep7vguAbW0UE2qFk7WRN48IVMJsu6r3vDssM aJefBFkPkC9TqloUY1RspEgO7T6l8GjH5NLktGCnln6JyFAeaE0t3MZcycXSt/kWGhuA2bRAnVvs a4bwamAzBa+/VXB1Tq/jyBLZWBnYz/xQW9Oyk/HWAmBPrgipzP3ZDOldydKRg8+QmGzTNhMhP3iQ zXSRUi1+f3cd7ZFx336i7Xd7sbWgWLMRLJ9sGMh2j5pcS6uI9gYmWH277ts2rR0U/hXO5i7Ekvk/ 3YfsXm1seuT1+Ordcvbh89Nt+jGKoiKThrIe6QwzPCI88en9r9MXz08u9tFwMviHlcqfnwwKNOG0 NKHdpn6uBybGD+QHfIMn8LW+/R9autg4c3XNla51XOyLQDxeIKkih9Hc4vJ5vhEBZEpqQxAnOkbD 6Va+4T3kaQRPoyfhrbcF0kVXLgQtmgG2jJcIGPNEc6mp4whR+azeWz1rotylc7/09u3IdmCSWE0B 34okxia2Z7FE2qL9ybrrBkAKdUsB4e4fe3jQRmDbmpSDrPSSBMxmMnfC/rF1v/4WiTKOEq7z3xHv 7SnxD/tcuyhICrvoCFX86mYwZPVQZ2lY/7jTreI9MaGANsSfeMtu1MD7PhZOn9l3irrK6tQa0iVw LuQjIRL5zHXZB80I8Ci5M1MiaTog0XBBllYtK1mg4zUI7c022b/r1sq43hLUjcbcJXzfc1jbBPHX q9umcEEAX/+tUDvJPy094htiqM0IdE3lmLQMZcMuPBpGgYM3hr3kIOFip6U6Z++nQ4Y2TxxZIl6a 5q0g2/1ydA1VTqrWQKLrKv7tN3ciTGr2J7cSAoPxeMyGYZvErhCLekkvmAfrrdM4vPk7oJ0ScsX1 aHpJaMoTTPyaTRWPHzq4taD5A7S/t7wnEbuJ2LlAoYNT/0E/3AiFwRtouUExwsE+1Hw2ymO1Kilt vxErzM0U6guUkjH3+6pzu2wb12ugCb1bhpQL+n0Agx7LZjJabg4MJsoH/Syi0zHSF+xbd9jED6KP RmyyylAGZZXRBu8O/RBX9hcbHOUwho6VfOTxqsNu+UOKDzpsOIi8AWk09j1APUK/Q4Is1MOm9SZ+ sj74+XSv6X6sAM3+8fGppW8Hs6aXRtfM9QojYoZpGOmVfqnCvVJfsZ/RUxGTHq2qbqlq1cQbqq8g Kdqat2eM6tLZ0VFSxDqyNa4LYnlUqMWRzORRmC+OHkHvqND1B7Qt6FKawIAYLU2W/u3TtIj7/Vcv TnsvX/S9UWhPYVtZK2YuDPnDbziGhEq34SDfzKVfxA/awN5rHp5X5N7+ce+YNraWG21HGk5uuzKu Zug+LI6u87nCVKOq2Lbdbf7k3PbPd+Kx8M56KwGog+Hd28Mg5V60l0qmZN1+wAStMumXJthtLrp2 eAgIBuDIfdEeUpdipqx+QOjLVti6v/8GUEsBAhQAFAAAAAgAcYCOPo5kLUnVDAAATyQAAA8AAAAA AAAAAQAgAAAAAAAAAFNlY3Rpb24zLVRILnR4dFBLBQYAAAAAAQABAD0AAAACDQAAAAA= ------=_NextPart_001_005F_01CBFABF.56205C50 Content-Type: application/x-zip-compressed; name="section3-XML-TH.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="section3-XML-TH.zip" UEsDBBQAAAAIAEF/jj6E5Zx+NAwAAEoqAAATAAAAc2VjdGlvbjMtWE1MLVRILnhtbOVa61IcNxb+ nyq/g/aHA1QxMwZiJ3YBVWPAizchODBeZ+OiXJpuzYyWvqWlBsa/9jX29fZJ9juSulvq6QHiVGq3 KuQCjKRzP0ffOeLJV0++YvjaVyLSMs+YljoRBxtHiRSZZkeliPFd8kRtMJ5Fi7w82IjM2oBXekFr EaeDG4eWEEjp5kfGPmALk5kWJQf9bM5upV4wHGR0PC/lZ3OaKVHeiHLbrFj6TBrOMylUS05qJZIZ qxSR4jilWT6rD0StsOx2IaMFGEdJFYOX2+IRqomXUCtmOfiWrCjzQpQaHNksL2uyoZ5DxiaQMRU8 8+TSizKv5gvH1lMin2ouM0WCB/LxUrCpWObgTbtVBM4tOeikF1IxVYgIQtacL/NUdMRh7SEVLUQK 0UvxayVB3pNC56zKYlHOc6zOpdKlPVw7oyXS55Vh49mR7vfycSWIB3HMuK7AHBooktYKoLZ7CSt2 eXr+/odj9uP5pCWW8mtoqVSVFrQXtprmlbbq5NlMOhtKvfR8j/AtBWxMGmF3S00ozaeJVAuKGF1W SrchaM/Co+OETsF/EmGnWCxnMHqVaBMGnoWd1FCVqwiRAtda94moKkmgiBd8KiEbxVAjHdTHxrnI kAUJu9/Yvk0gi6pEV0Vwd2QpvolhIjyi4HotRGHUXQhZNud84z3s0smaFGVn43/4MRjEmcvLbOnp WFBWlZJ21unq5wESoBPRLo5torWEHIuz95cTaxuX22luYp1nLM96WeRlaHGPVSoiHJQqtTEhOJKX 0gdB87CFmqDpl9+oZj0AC+g8yhMm0yLBWqa5jWxPMMqZyshuasF2TwGAcuLa+F9VRZGXKE1sWuY8 DkI0cYUclNYIBmNpwxBBW2I9WbJYFEm+FD4lncd86ZTA/hS/TEW70UX+rKJ07xir+a3/UnmH5L7N yzi4XTzDBla2keicX9Qnff9Wigq8WkCjmKllmgpdysiFvcnV/mgdrmHSuRoanmQxF3SN+i5YXOAH lZSx08nkHXvNFYTp9QSKCOw5k5mlt39XCtR9Xs6FPti4eHO0+2Ln2w02OmTTpWPcw6RHaGVEg1nK jBMXKNG1n9tT/+6Zwg93/DaTc/g38Md+UQqeougEnzL2BrVS3HEKcbaZQCsEp+DX9q6jQhpLVSQI o6Iqi1xRgcyS5dargPaol/g+LzXkvO5w3P/Lx6Pj8WT8kT5+d47CMNL5NQAHWX60M9yhz09zpV/V N5mTbxjlKa2N/QL3yvkq+vzLEf/rxSXfe/Ps7HORfTh+k/6U4ufdv32gQ0c54Azwz2RZiFdU3xLn 1tHd4Pb2dgBV00FVJiKLcoSKTYd5yTP9SePIQVBVP9Ger+l/B3Lng7rIdqrXO1/TCUQzbvFIf8LN crDQulBP98ZPd9/gX+vNp7snTh38BIVoYfrkq6ur0HSjVdvtj1bc2sk51DaKHi1vRLIMUBmV/7r0 +iHUzYhpHi/702KWJ0l+SwsFLxGg4KRetUXDSIMLGxeeXlLVQIWeY/cGox/eZhToBxsvNrqxoM36 RNzpGqF+knF3F/bdqIJHAmnVXbk4+en924uT42F/MRh2+I30IySwRWhVil5ePdnYx2l/RNYJ3Pkn Stk/IvvqaDlQL14v4ovrX/WeScHAiQfzn3dmr7nem/79/y9f16M1gks8ikSh/SwO70/KxWnuQLFL YJ96k6fbNah58G4b3gsgfeINloljSduAkNfgFlVJbcAuRSYJgTYmUylAssM7dQL55D1N19xy+yMH Uw4pWJpPu9jFsxj0xpWNtUsLOi4twr4Hw7y2rd49MMYUWUIYqkF1M55KYDOfznpQN61lIsNkeQ0B a1hkJQSm9qm9NbuV8JAhCnopU14C+cmUhKlt3XaSQLM3IqCD0oDaUHuBdgdsh45RjTfZ+fj95JTt Dp9RT6JRL7cDcsHhla6ZmjNhyMzKPKVGkVp2sPY3+uQ2AZsBXXHnbNlLCmjWmNpTK86hPayGCn5j WtlAPSgsaYqQLVt21FfgNKwEq66txWEUfECTUeNm69tH+rPgsryVSqyYiTKXvFy3hkYvshJnN1gV tkeu+w8H/Y2OPqWpQAGukb3tu1SDdRlapATldC4GpVAFNBcewcDQYjgfsqPT8Tv2EfB15+XLb662 tpto9wdGUO1awJrzUph+qGtvR91SPPn+BARP3lxtmfJDiuWVYiIFxpB0OhTDhSC6wYHGcpttm+eT d1sr1EnU3d3vXl5trakPfcVWrcxh+k3Sbev6JzvbbIo9svbBikGsRqs861gxzWuTVBauhaU3iJvf djMEgUKXRI3wWvT2+Fvh4Qpcr6/+tKabHDcF4PHtJP0Hwf3qsYl0VnJOvVjz4RZ0nZF+/nlqKAFN EcPGT3UVQIOMXEGnxu2USZBFZEn9Y6nDIl6KOS9jO8GcA2HDOtX0n1COUV/uPkpzQ57KhaTrNFBh WcCuSULtuaeCmVzNcUfSitOFWkcaFNEgqQyIgDKSAh+6kk4VTuVVGYk2UWmkRb6lAe7cDLgozK0b OiJ5lSer0inoImpvxEJGiWhvkXAAYspfU1A7l9OJxUqqqUM/D58/e9maigZHGp0+UgfBSzRMOuEA ZfTe7nfPtvH9+bfPn1+F18vl+OwHc/l4tfzj+fjy7eVQ8TQZRHkpBlgf5Kpz8siU+3qzTOXAtgd6 OdgZPuts/l6UsEKuTL5JdByw5zUVaRLvm53dZ1ft5Lmr+8SMjeqbLqKbuXE5ot71WrL0zyiRcvIZ AD0AOW5jRBG+bTO1hLkjWgHohEXvaq8q+XldRpqswa1ti0o9CO+9auvYCcpeBikA0w0kKHKEDwVi OxzvxYU+gYgC2x/b1BN8onPDExlz7Z4AOjkbxjiFfeyy0svGTT9pKDO2Qt+51wPVpDIoNAC5toar efdOzB+4ScY1sZTm0vatIMxpoJcKonDUWP9gOCvqD96NQ4r0/RFtPfSLmk/IYqiwiphSkQfBRTNH kcwGdiDt7w+aVaqr1IBxXd/Czb5tBy5zRDPQzXLV3N1aZs0h4rbpwG2zyGNTWLwQyILIaygYrOim a3BfIEytZK8Pw6Syz1Km2vQ82ax7qTnNb4U5GD4gMGuEppmerc8GT0NTOF2hoTOBvi6CtjsKUgnA x63uLtDc4wLhboq1gJRmieDKooF2SCMz61FQDfr+IBz9eY1aApiFV7DZ052XoP/wlGplDC+W/knL g6Ssg7+I1FkTZR0MU6nWnC6AOp0Cfa17G9m8ODk6Pzs7+fH45NiHmvT1KLkmBGZXpQps1xEv5Pkl xmiYBqnDcSc5LI4oNbhAAJTHwc4v4ndsAYwp681L4u906JheoOPaXpu4HxOCNgTdCI9IEW+ZgXju igzPqECtOHblbTcWKbADvaUK+8BbyvnCtcgm+zo5+Zu88dCUr9NZ0jN7/Sreva7DV3WLplQny//o UWwjjJnCPTQQXXOHMO/BpC7pfbevoYHQrESXjWl6pvYGm6o8Iez4/uLtI9LxHpUe0qbrjwe4PeT5 L5vvBkGA4Iy7EUCtoKIsoGls+K7FG8wckm8d031lc3+n8SeeKfdMiLtxc/Du9MfF9MPd7XnycTgc 5qnUdGGTjWCyG5RVfHr1y+Sbp3vHvQQsd1qpyuzp3jhH501TZ3r2U0/VWEf4hVyHb3Ae/t8c/d+P rE3JshjPwrgwAtcVMywD89Jf65iph+sT2hJAhvfZbJqaoSI0in3PrLR9YFw5MIWJjQ7RC3DvLwMA 7jIh6M0XQZ7yAuVD39LATIfPWqbeUMnaVwXP7uqSiXCbbhw2Twz7I7N62BZcCytA28H/1apGMm77 rGrYulJY2CU1C4HsHmINBlG2I1+ZRPlsaChVF0y3y4UnTUJXHQP7WWUkyZxOZWbl73WUz4gUHPqx c//w7Z6XjlLY4UBPLasfOu5rZn1GZlQa52YqXMPl07PxEWsHRcbldqh63635eEB8qWvQ2Ip3yz0f 0QDANbWImKn5iyhVpe19iHQW8ob0RIk3nXeXx2Y7SriR3PolljRlIM1wXhbGQDaeneZ1G7JK/j// +rfqsmgfTb8I6FosP7MKOVhvvFFrHqKqFX0c+DUK/D4Bbhci67ADekTNVKYj90CEmTSvimJ2r8Q7 fa2Yl7P3kyOGlk+MDDEn/uMC3koVd5m0E67fgznCB7LVT+w//wVQSwECFAAUAAAACABBf44+hOWc fjQMAABKKgAAEwAAAAAAAAABACAAAAAAAAAAc2VjdGlvbjMtWE1MLVRILnhtbFBLBQYAAAAAAQAB AEEAAABlDAAAAAA= ------=_NextPart_001_005F_01CBFABF.56205C50-- ------=_NextPart_000_005E_01CBFABF.56205C50 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+4wggTMMIIDtKADAgECAhA04y/94Vi/dkaC9/1NZ7F6MA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTEwMzAzMDAwMDAwWhcNMTIwMzAyMjM1OTU5WjCCARMxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9u bzEfMB0GCSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAqXFlCDKk41h+Qdsa43S4gLmnm78zrrujeF/9ehTTbO2xWpQN5RXC1iaqTH3yfqdzZVax ssJ5yg5adnNBJUjFgy5FbgEzthKGURl+CcLvWhAVAVsAJhu227qhK/2SPnIXGP43u1TlZD+8LU9E WngkY3M3AiKhcclB0G9hX31qXsUCAwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAL BgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBD oEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRh bElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA3xiHqu8i5pWT418M2F07ZFN5tpHyOF2mJH8M M/mtUqkI6OpdT7X1YI68pv2UALawaTQIwLpFDDv2vTPyi9+yVANyngAUqe9QogpUhnVv0U6utNrE aFzIjwkoaPDpacOZRvz47yl4eN36rM2vGJ1i3eZfsEA8X0+aepIsUsX9zwZ69ocXyhs4+xNiEByQ YwBIUA2JUCf/bv5lIY4sX3XLHddtBgZ8vGPCjiJDu+1tXwdjqf2NyeHJRHk3TcNH7Nd3HSpR7Ojn fuMzpOtmRTuJ4N74J1+Ck4LWA3s6ZofXbGL/8qglffU1Wf+XW89L3hIKMfY4z3hf++YustE+Fmwj 1jCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV 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 dWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQNOMv/eFYv3ZGgvf9TWexejAJBgUrDgMCGgUAoIIDGzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0MTQyMDE2NDBaMCMG CSqGSIb3DQEJBDEWBBSV8kJ1yHWPUCrgXJNMF/ueTOqwQzCBqwYJKoZIhvcNAQkPMYGdMIGaMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCCAQMGCSsGAQQBgjcQBDGB9TCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhA0 4y/94Vi/dkaC9/1NZ7F6MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQNOMv/eFYv3ZGgvf9TWexejANBgkq hkiG9w0BAQEFAASBgE9gTlHqDA87pNA30LLaTc2nSp7ubdb6Zem66OAywJ4S1XbKsKF+5WDYy5TK rwu8Q50Ris8P7bP+iOXSXDMJu/ErgjgkgRQx0lziVP0/GoOfK+K5/WFIIeNk14sNC0BWIbOgppAy a17UMbZ8k5fXXhuuIAwFfOkOeqNcN4Iuee5JAAAAAAAA ------=_NextPart_000_005E_01CBFABF.56205C50-- From eran@hueniverse.com Thu Apr 14 13:20:07 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DDD52E07D5 for ; Thu, 14 Apr 2011 13:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id im8TAnZFBQ5W for ; Thu, 14 Apr 2011 13:20:06 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id 46636E06B8 for ; Thu, 14 Apr 2011 13:20:06 -0700 (PDT) Received: (qmail 21430 invoked from network); 14 Apr 2011 20:20:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Apr 2011 20:20:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 14 Apr 2011 13:19:42 -0700 From: Eran Hammer-Lahav To: Thomas Hardjono , oauth Date: Thu, 14 Apr 2011 13:19:34 -0700 Thread-Topic: Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3Xw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Revised Section 3 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, 14 Apr 2011 20:20:08 -0000 To make discussion easier, here is the proposed text: [NOTE: Text for the following Section 3 is based on OAUTH draft-11] 3. Client Credentials When interacting with the authorization server, the client identifies itself using a set of client credentials which include a client identifier and other properties for client authentication. The means through which the client obtains its credentials are beyond the scope of this specification. Some authentication=20 schemes require the client to undergo registration with the authorization server. Due to the nature of some clients, authorization servers SHOULD NOT make assumptions about the confidentiality of client secrets without establishing trust with the client. Although it is difficult for=20 servers to ascertain the security capabilities of clients, in general=20 authorization servers SHOULD NOT issue client secrets to clients incapab= le=20 of keeping their secrets confidential. The authorization server MAY authenticate the client using any appropriate set of credentials and authentication schemes. The client MUST NOT include more than one set of credentials or authentication mechanism with each request. Although authentication schemes and their protocol implementations=20 are out of scope, this specification seeks to support a broad=20 selection of authentication schemes that are currently deployed=20 today and that may be deployed in the future. 3.1. Client Password Credentials Client password credentials use a shared symmetric secret to authenticate the client. The client identifier and password are included in the request using the HTTP Basic authentication scheme as defined in [RFC2617] by including the client identifier as the username and client password as the password. For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=3Dauthorization_code&code=3Di1WsRn1uB1& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb Alternatively, the client MAY include the password in the request body using the following parameters: client_id REQUIRED. The client identifier. client_secret REQUIRED. The client password. For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=3Dauthorization_code&client_id=3Ds6BhdRkqt3& client_secret=3DgX1fBat3bV&code=3Di1WsRn1uB1& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb The authorization server MUST accept the client credentials using both request parameters and the HTTP Basic authentication scheme. The authorization server MAY support additional authentication schemes suitable for the transmission of password credentials. 3.2. Shared Secret Credentials Beyond client password credentials, there is a broad family=20 of authentication schemes based on the notion of shared secrets. =20 In these schemes the primary aim is for the client to prove=20 possession of the shared secret. In the current OAUTH 2.0 context,=20 shared secret credentials are different from assertion credentials=20 (see below) in that here the client does not have to=20 provide any assertions or claims.=20 =20 Within the family of authentication schemes based on the pairwise=20 sharing of secrets there are a variety of protocols that have=20 been deployed. These include challenge-response protocols=20 (e.g. CHAP [RFC1994]), password-authenticated key agreement=20 protocols (e.g. EKE [REF]) and various embodiments=20 of the one-time password (OTP) protocols (e.g. [RFC2289]). These authentication protocols=20 are out of scope of this specification, but in deployment=20 of these authentication schemes with OAUTH 2.0, the authorization=20 server MUST accept the client credentials using both request parameters and the HTTP Basic authentication scheme. 3.3 Client Assertion Credentials The term assertion (or signed assertion) refers to a statement or=20 claim made by a trusted third party regarding a given subject=20 at a given moment in time. Typically an assertion is digitally=20 signed by its issuer in order to provide source-authenticity=20 and integrity protection. There are a number of vehicles for=20 the implementation of assertions. =20 Examples include X.509 subject and attribute certificates=20 [RFC3280,RFC5755], SAML 2.0 assertions [OASIS.saml-core-2.0-os],=20 Claims [OASIS.imi-identity-1.0], Kerberos service tickets [RFC4120] and = others. =20 Their differences typically lie in their semantic expressiveness,=20 syntactic complexity and size. In OAUTH, client assertion credentials provide an extension point=20 by which the authorization server can authenticate a client by validatin= g=20 a signed assertion issued by a third party (assertion issuer),=20 which is trusted by both the client and the authorization server. A client must obtain an assertion (such as a SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer or may in some cases self-issue an assertion. =20 The format of the assertion, the process by which an assertion is obtained, and the method of validating an assertion are defined by the assertion issuer and the authorization server, and are beyond the scope of this specification. However, for=20 the purposes of the authorization server validating the identity of=20 a client, the assertion presented by the client SHOULD contain=20 at least the following information: o Identity of the client. o Identity of the issuer. o Method of authentication used by the issuer to=20 authenticate the client (RECOMMENDED). o Time of authentication of the client by the issuer (RECOMMENDED). o Time of assertion issuance and validity period of assertion. o Digital signature of the issuer. o An indication (explicit or implied) as to the means by which=20 the client demonstrates its right to present the assertion (RECOMMEND= ED). When using a client assertion, the client includes the following parameters: client_assertion_type REQUIRED. The format of the assertion as defined by the authorization server. The value MUST be an absolute URI. client_assertion REQUIRED. The client assertion. For example, the client sends the following access token request using a SAML 2.0 assertion to authenticate itself (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=3Dauthorization_code&code=3Di1WsRn1uB1& client_assertion=3DPHNhbWxwOl[...omitted for brevity...]ZT4%3D& client_assertion_type=3D urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb When obtaining an access token using a client assertion together with an authorization code (as described in Section 5.1.1), a mechanism is needed to map between the value of "client_id" parameter used to obtain the authorization code, and the client assertion. Such a mechanism is beyond the scope of this specification, but MUST be specified for any client assertion type used in combination with an authorization code. The authorization server MUST reject access token requests using client assertion credentials that do not contain HMAC or signed values that: o State the assertion was specifically issued to be consumed by the receiving endpoint (typically via an audience or recipient value containing the receiving endpoint's identifier). o Identify the entity that issued the assertion (typically via an issuer value). o Identify when the assertion expires as an absolute time (typically via an expiration value containing a UTC date/time value). The authorization server MUST reject expired assertions. References RFC1994. PPP Challenge Handshake Authentication Protocol (CHAP), IETF Stan= dards Track, August 1996. S. M. Bellovin; M. Merritt (May 1992). "Encrypted Key Exchange: Password-Ba= sed Protocols Secure Against Dictionary Attacks". Proceedings of the 1992 I= EEE Symposium on Research in Security and Privacy, Oakland, CA. RFC4120. The Kerberos Network Authentication Service (V5), IETF Standards = Track, July 2005. OASIS Identity Metasystem Interoperability Version 1.0, Oasis Standard, Jul= y 2009. URL: http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0= -spec-os.html#_Toc229451842 RFC5755 An Internet Attribute Certificate Profile for Authorization, IETF = Standards Track, January 2010.=20 RFC3280 Internet X.509 Public Key Infrastructure Certificate and Certificat= e Revocation List (CRL) Profile, IETF Standards Track, April 2002. RFC2289. A One-Time Password System. IETF Standards Track, February 1998. From eran@hueniverse.com Thu Apr 14 14:56:32 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 468E2E0796 for ; Thu, 14 Apr 2011 14:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyPMipboU0E3 for ; Thu, 14 Apr 2011 14:56:30 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 81327E0715 for ; Thu, 14 Apr 2011 14:56:27 -0700 (PDT) Received: (qmail 1419 invoked from network); 14 Apr 2011 21:56:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Apr 2011 21:56:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 14 Apr 2011 14:56:19 -0700 From: Eran Hammer-Lahav To: Thomas Hardjono , oauth Date: Thu, 14 Apr 2011 14:56:07 -0700 Thread-Topic: Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAAGLA/A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72344656744185@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Revised Section 3 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, 14 Apr 2011 21:56:32 -0000 Thanks Thomas! My notes below are not aimed specifically at Thomas but at those seeking to= have this section included. I'm going to skip any editorial feedback as I = will make those changes if and when incorporating this text into the v2 spe= cification. I will say that the new section 3.2 belongs largely in the intr= oduction of section 3. > [NOTE: Text for the following Section 3 is based on OAUTH draft-11] >=20 >=20 > 3. Client Credentials >=20 > When interacting with the authorization server, the client identifies > itself using a set of client credentials which include a client > identifier and other properties for client authentication. The means > through which the client obtains its credentials are beyond the scope > of this specification. Some authentication > schemes require the client to undergo registration with the > authorization server. >=20 > Due to the nature of some clients, authorization servers SHOULD NOT > make assumptions about the confidentiality of client secrets without > establishing trust with the client. Although it is difficult for > servers to ascertain the security capabilities of clients, in general > authorization servers SHOULD NOT issue client secrets to clients incap= able > of keeping their secrets confidential. >=20 > The authorization server MAY authenticate the client using any > appropriate set of credentials and authentication schemes. The > client MUST NOT include more than one set of credentials or > authentication mechanism with each request. Need to make it explicit that no client authentication scheme is mandatory = to implement. > Although authentication schemes and their protocol implementations > are out of scope, this specification seeks to support a broad > selection of authentication schemes that are currently deployed > today and that may be deployed in the future. This statement is just not true. This specification may seek to keep client= authentication out of scope but by defining two such mechanisms in section= 3, it clearly fails to keep them out of scope. >=20 > 3.1. Client Password Credentials This section should be named "Using HTTP Basic access authentication scheme= ". The parameters defined are just a hack to align Basic with the deployed = reality of using parameters instead of the header. > Client password credentials use a shared symmetric secret to > authenticate the client. The client identifier and password are > included in the request using the HTTP Basic authentication scheme as > defined in [RFC2617] by including the client identifier as the > username and client password as the password. >=20 > For example (line breaks are for display purposes only): >=20 >=20 > POST /token HTTP/1.1 > Host: server.example.com > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > Content-Type: application/x-www-form-urlencoded >=20 > grant_type=3Dauthorization_code&code=3Di1WsRn1uB1& > redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb >=20 >=20 > Alternatively, the client MAY include the password in the request > body using the following parameters: Need to add a note here that using the parameter alternative is deprecated = or NOT RECOMMENDED. If we are going to bastardize HTTP Basic, we should do = it in a responsible way and discourage people from using it. There is not a= single reason why clients can't use HTTP Basic to transmit these credentia= ls (if you have requirements showing otherwise, please share). > client_id > REQUIRED. The client identifier. >=20 > client_secret REQUIRED. The client password. >=20 > For example (line breaks are for display purposes only): >=20 >=20 > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded >=20 > grant_type=3Dauthorization_code&client_id=3Ds6BhdRkqt3& > client_secret=3DgX1fBat3bV&code=3Di1WsRn1uB1& > redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb >=20 >=20 > The authorization server MUST accept the client credentials using > both request parameters and the HTTP Basic authentication scheme. > The authorization server MAY support additional authentication > schemes suitable for the transmission of password credentials. This is not true. There are no requirements for what authentication schemes= the authorization server MUST or SHOULD accept. > 3.2. Shared Secret Credentials >=20 > Beyond client password credentials, there is a broad family > of authentication schemes based on the notion of shared secrets. > In these schemes the primary aim is for the client to prove > possession of the shared secret. In the current OAUTH 2.0 context, > shared secret credentials are different from assertion credentials > (see below) in that here the client does not have to > provide any assertions or claims. >=20 > Within the family of authentication schemes based on the pairwise > sharing of secrets there are a variety of protocols that have > been deployed. These include challenge-response protocols > (e.g. CHAP [RFC1994]), password-authenticated key agreement > protocols (e.g. EKE [REF]) and various embodiments > of the one-time password (OTP) protocols (e.g. [RFC2289]). >=20 > These authentication protocols > are out of scope of this specification, but in deployment > of these authentication schemes with OAUTH 2.0, the authorization > server MUST accept the client credentials using > both request parameters and the HTTP Basic authentication scheme. I don't understand how these other symmetric secret schemes work with Basic= . > 3.3 Client Assertion Credentials >=20 > The term assertion (or signed assertion) refers to a statement or > claim made by a trusted third party regarding a given subject > at a given moment in time. Typically an assertion is digitally > signed by its issuer in order to provide source-authenticity > and integrity protection. There are a number of vehicles for > the implementation of assertions. > Examples include X.509 subject and attribute certificates > [RFC3280,RFC5755], SAML 2.0 assertions [OASIS.saml-core-2.0-os], > Claims [OASIS.imi-identity-1.0], Kerberos service tickets [RFC4120] an= d > others. > Their differences typically lie in their semantic expressiveness, > syntactic complexity and size. >=20 > In OAUTH, client assertion credentials provide an extension point > by which the authorization server can authenticate a client by validat= ing > a signed assertion issued by a third party (assertion issuer), > which is trusted by both the client and the authorization server. >=20 > A client must obtain an assertion (such as > a SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer > or may in some cases self-issue an assertion. > The format of the assertion, the process by > which an assertion is obtained, and the method of validating an > assertion are defined by the assertion issuer and the authorization > server, and are beyond the scope of this specification. However, for > the purposes of the authorization server validating the identity of > a client, the assertion presented by the client SHOULD contain > at least the following information: >=20 > o Identity of the client. > o Identity of the issuer. > o Method of authentication used by the issuer to > authenticate the client (RECOMMENDED). > o Time of authentication of the client by the issuer (RECOMMENDED). > o Time of assertion issuance and validity period of assertion. > o Digital signature of the issuer. > o An indication (explicit or implied) as to the means by which > the client demonstrates its right to present the assertion > (RECOMMENDED). The entire section is marked as SHOULD which is equal to RECOMMENDED. This = is an odd combination of "double SHOULD" on some items. > When using a client assertion, the client includes the following > parameters: >=20 > client_assertion_type REQUIRED. The format of the assertion as > defined by the authorization server. The value MUST be an > absolute URI. >=20 > client_assertion REQUIRED. The client assertion. Since this section does not claim to be the only valid way to authenticate = a client using assertions (as other *real* HTTP schemes may provide that fa= cility), the REQUIRED parameters should be limited to those using *this* me= chanism, not to 'using a client assertion'. > For example, the client sends the following access token request > using a SAML 2.0 assertion to authenticate itself (line breaks are > for display purposes only): >=20 > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded >=20 > grant_type=3Dauthorization_code&code=3Di1WsRn1uB1& > client_assertion=3DPHNhbWxwOl[...omitted for brevity...]ZT4%3D& > client_assertion_type=3D > urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& > redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb >=20 >=20 > When obtaining an access token using a client assertion together with > an authorization code (as described in Section 5.1.1), a mechanism is > needed to map between the value of "client_id" parameter used to > obtain the authorization code, and the client assertion. Such a > mechanism is beyond the scope of this specification, but MUST > be specified for any client assertion type used in combination with > an authorization code. This MUST is pointless and should be removed. We should not include any MUS= T which cannot be verified and enforced (I need to review the rest of the d= ocument for such normative requirements). Here, since no registration process is provided for assertion types, and no= ne of the vendors demanding this facility have published (or indicated thei= r intention to publish) documents for any particular assertion type, where = exactly is this MUST to be enforced? There is just no point. It is enough t= o say that this is something they need to consider. > The authorization server MUST reject access token requests using > client assertion credentials that do not contain HMAC or signed > values that: >=20 > o State the assertion was specifically issued to be consumed by the > receiving endpoint (typically via an audience or recipient value > containing the receiving endpoint's identifier). >=20 > o Identify the entity that issued the assertion (typically via an > issuer value). >=20 > o Identify when the assertion expires as an absolute time (typically > via an expiration value containing a UTC date/time value). The > authorization server MUST reject expired assertions. This is where things fall apart. This looks like normative language, and cl= early intents to be, but has no real way of being implemented by any genera= l purpose library. If this section (client assertions) is to be added to th= e specification, this entire last part should be converted to a security co= nsideration section, not a pretend attempt to define real security requirem= ents. The security of this entire proposal rests on being able to enforce these r= equirements, but the specification does not offer any useful information fo= r implementers to do so. In practice, this invents a new HTTP authentication scheme. The test we mus= t apply here before adding this section to the document is whether it would= pass IETF scrutiny if it was presented as a new, standalone, HTTP authenti= cation scheme (regardless of how it transmits the credentials using paramet= ers or header). Before including it, I would like to see a statement from t= he AD stating that the text is acceptable to the IETF security standards, a= nd that it is suitable for use as a generic HTTP authentication scheme. If = it is acceptable here but not with other HTTP requests, we need to make tha= t clear (though that would be pretty bad). Here is one counter proposal to this. Define the two parameters 'client_ass= ertion_type' and 'client_assertion', and specify a required process for pub= lishing specifications using them for use with well-defined assertion forma= ts. This way, the community can enforce sane security standards which this = section clearly fails to accomplish (no matter hard it tries, and it does t= ry). How is this different from the grant type extension point (which does not r= equire any such publication)? With the grant type extension point, we clear= ly label it an extension, and take no position as to what it may contain an= d to its level of security. Here however, the text clearly creates the illu= sion of security, but doesn't provide enough detail as how to specifically = accomplish that in practice. EHL From stpeter@stpeter.im Thu Apr 14 15:06:49 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C026EE0791 for ; Thu, 14 Apr 2011 15:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNVoLlwVFdTb for ; Thu, 14 Apr 2011 15:06:49 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id 23E1DE0688 for ; Thu, 14 Apr 2011 15:06:49 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E0F6D40D68; Thu, 14 Apr 2011 16:09:56 -0600 (MDT) Message-ID: <4DA76FF6.2070105@stpeter.im> Date: Thu, 14 Apr 2011 16:06:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72344656744185@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72344656744185@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060209030708080508040508" Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 14 Apr 2011 22:06:49 -0000 This is a cryptographically signed message in MIME format. --------------ms060209030708080508040508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/14/11 3:56 PM, Eran Hammer-Lahav wrote: > In practice, this invents a new HTTP authentication scheme. Eran, during the WG meeting in Prague you said the same thing, and I tend to agree. Yes, client authentication is a good thing, but given that OAuth happens over HTTP I don't see why we can't just use existing HTTP authentication schemes. If BASIC and DIGEST aren't good enough, then someone needs to develop a new HTTP authentication scheme. However that's not a job for the OAuth WG as far as I can see... Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060209030708080508040508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQx NDIyMDY0NlowIwYJKoZIhvcNAQkEMRYEFC8122aRSKVKmrK3Z5XTaVaZdkSSMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAgeDg7YiXqYygnM/Ga8QADqHvW4ni2PbqoHnUzO9h8xL77dRLmCtvz9SMg aFkUZbjhVBm4tv2tu+nqZ1apojR9hDCmClKTq4acAw+/bNr4ipHmchKlXVemBD78A31cQ5vk n55FqMHDcFN7Cv4RnMw/IuWB55Z0covDEnvWQeZa5dQglGx4rsW4ViYf1+zCpG3V5vAvTqiZ cjDLhP94BNZfWPhthj9F5BlQswMvO9oXR4oxgTg1Zk23HK9EasfzGvS/ocBDJQt8b47CnbaE M3pxF1VYn0PdrnyBmO7piaopHxMsWo1quAHwx8IThpvjuJVdwJbVelVGDZ5X32JEhUcaAAAA AAAA --------------ms060209030708080508040508-- From eran@hueniverse.com Thu Apr 14 15:16:53 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8B6C3E0904 for ; Thu, 14 Apr 2011 15:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA82eB5884zG for ; Thu, 14 Apr 2011 15:16:52 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id A94D0E0721 for ; Thu, 14 Apr 2011 15:16:52 -0700 (PDT) Received: (qmail 24146 invoked from network); 14 Apr 2011 22:16:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Apr 2011 22:16:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 14 Apr 2011 15:16:45 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre Date: Thu, 14 Apr 2011 15:16:35 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv68EFtxiPK+szKTwOClrf0vecE6wAAPKNQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72344656744195@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72344656744185@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DA76FF6.2070105@stpeter.im> In-Reply-To: <4DA76FF6.2070105@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 14 Apr 2011 22:16:53 -0000 V2hpY2ggcmVtaW5kcyBtZToNCg0KU2VjdGlvbiAzLjEgbmVlZHMgdG8gaW5jbHVkZSBhIGNsZWFy IE1VU1QgdXNlIFRMUyB3aGVuIHVzaW5nIHRoaXMgYXV0aGVudGljYXRpb24gbWV0aG9kLiBXaGls ZSB0aGlzIGlzIGNvdmVyZWQgYnkgdGhlIHJlcXVpcmVtZW50IHRvIHVzZSBUTFMgd2hlcmUgT0F1 dGggdXRpbGl6ZWQgdGhpcyBjbGllbnQgYXV0aGVudGljYXRpb24gc2NoZW1lICh0b2tlbiBlbmRw b2ludCksIHRoZSBpbnRyb2R1Y3Rpb24gb2YgY2xpZW50X2lkIGFuZCBjbGllbnRfc2VjcmV0IGRv IGludmVudCBhIG5ldyBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBhbG9uZ3NpZGUgQmFzaWMs IGFuZCB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSBwZW9wbGUgZG9uJ3QgdHJ5IGFuZCBhcHBseSBpdCBl bHNld2hlcmUgd2l0aG91dCBUTFMgKHdlIGtub3cgc29tZW9uZSB3aWxsKS4NCg0KRUhMDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGV0ZXIgU2FpbnQtQW5kcmUgW21h aWx0bzpzdHBldGVyQHN0cGV0ZXIuaW1dDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNCwgMjAx MSAzOjA3IFBNDQo+IFRvOiBFcmFuIEhhbW1lci1MYWhhdg0KPiBDYzogVGhvbWFzIEhhcmRqb25v OyBvYXV0aA0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZXZpc2VkIFNlY3Rpb24gMw0KPiAN Cj4gT24gNC8xNC8xMSAzOjU2IFBNLCBFcmFuIEhhbW1lci1MYWhhdiB3cm90ZToNCj4gDQo+IDxz bmlwLz4NCj4gDQo+ID4gSW4gcHJhY3RpY2UsIHRoaXMgaW52ZW50cyBhIG5ldyBIVFRQIGF1dGhl bnRpY2F0aW9uIHNjaGVtZS4NCj4gDQo+IEVyYW4sIGR1cmluZyB0aGUgV0cgbWVldGluZyBpbiBQ cmFndWUgeW91IHNhaWQgdGhlIHNhbWUgdGhpbmcsIGFuZCBJDQo+IHRlbmQgdG8gYWdyZWUuIFll cywgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIGEgZ29vZCB0aGluZywgYnV0IGdpdmVuDQo+IHRo YXQgT0F1dGggaGFwcGVucyBvdmVyIEhUVFAgSSBkb24ndCBzZWUgd2h5IHdlIGNhbid0IGp1c3Qg dXNlIGV4aXN0aW5nDQo+IEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcy4gSWYgQkFTSUMgYW5k IERJR0VTVCBhcmVuJ3QgZ29vZCBlbm91Z2gsDQo+IHRoZW4gc29tZW9uZSBuZWVkcyB0byBkZXZl bG9wIGEgbmV3IEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lLg0KPiBIb3dldmVyDQo+IHRoYXQn cyBub3QgYSBqb2IgZm9yIHRoZSBPQXV0aCBXRyBhcyBmYXIgYXMgSSBjYW4gc2VlLi4uDQo+IA0K PiBQZXRlcg0KPiANCj4gLS0NCj4gUGV0ZXIgU2FpbnQtQW5kcmUNCj4gaHR0cHM6Ly9zdHBldGVy LmltLw0KPiANCj4gDQoNCg== From phil.hunt@oracle.com Thu Apr 14 15:41:38 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E0040E06F1 for ; Thu, 14 Apr 2011 15:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx62pQW38dbJ for ; Thu, 14 Apr 2011 15:41:38 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfc.amsl.com (Postfix) with ESMTP id D4C49E06AC for ; Thu, 14 Apr 2011 15:41:37 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p3EMfZbC029722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Apr 2011 22:41:36 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p3EMfYGx008650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Apr 2011 22:41:34 GMT Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p3EMeXf5006546; Thu, 14 Apr 2011 17:40:33 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Apr 2011 15:40:33 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <4DA76FF6.2070105@stpeter.im> Date: Thu, 14 Apr 2011 15:40:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4C1DF2DE-64A4-42BA-99D1-778D7AD9EEC7@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72344656744185@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DA76FF6.2070105@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4DA7781F.005C:SCFSTAT5015188,ss=1,fgs=0 Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 14 Apr 2011 22:41:39 -0000 +1 There is the issue of how a client app 'bootstraps' its own credential. = It could be that it authenticates by some other RFC (like 2617 Basic = Auth), or some other method. E.g. would be nice to have a way for = client apps to obtain either the equivalent of client_assertion, or even = a MAC token representing just the client security context (a = turtles-all-the-way-down approach). Regardless, I agree this isn't part of the core OAuth specification. Phil phil.hunt@oracle.com On 2011-04-14, at 3:06 PM, Peter Saint-Andre wrote: > On 4/14/11 3:56 PM, Eran Hammer-Lahav wrote: >=20 > >=20 >> In practice, this invents a new HTTP authentication scheme. >=20 > Eran, during the WG meeting in Prague you said the same thing, and I > tend to agree. Yes, client authentication is a good thing, but given > that OAuth happens over HTTP I don't see why we can't just use = existing > HTTP authentication schemes. If BASIC and DIGEST aren't good enough, > then someone needs to develop a new HTTP authentication scheme. = However > that's not a job for the OAuth WG as far as I can see... >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Apr 14 15:46:59 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 926C6E07A6 for ; Thu, 14 Apr 2011 15:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EuXqgPdQpKl for ; Thu, 14 Apr 2011 15:46:58 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 9B8A2E0785 for ; Thu, 14 Apr 2011 15:46:58 -0700 (PDT) Received: (qmail 29954 invoked from network); 14 Apr 2011 22:46:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Apr 2011 22:46:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 14 Apr 2011 15:46:48 -0700 From: Eran Hammer-Lahav To: Phil Hunt , Peter Saint-Andre Date: Thu, 14 Apr 2011 15:46:37 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv69R55i16+ieZVTEGSWJpJjqei5gAAFT6w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723446567441A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72344656744185@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DA76FF6.2070105@stpeter.im> <4C1DF2DE-64A4-42BA-99D1-778D7AD9EEC7@oracle.com> In-Reply-To: <4C1DF2DE-64A4-42BA-99D1-778D7AD9EEC7@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 14 Apr 2011 22:46:59 -0000 My current project uses MAC authentication for client authentication at the= token endpoint. I would be helpful if people explicitly express their view= s on the proposed text, and whether they support or object to it. EHL > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Thursday, April 14, 2011 3:41 PM > To: Peter Saint-Andre > Cc: Eran Hammer-Lahav; oauth > Subject: Re: [OAUTH-WG] Revised Section 3 >=20 > +1 >=20 > There is the issue of how a client app 'bootstraps' its own credential. = It could > be that it authenticates by some other RFC (like 2617 Basic Auth), or som= e > other method. E.g. would be nice to have a way for client apps to obtain > either the equivalent of client_assertion, or even a MAC token representi= ng > just the client security context (a turtles-all-the-way-down approach). >=20 > Regardless, I agree this isn't part of the core OAuth specification. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-04-14, at 3:06 PM, Peter Saint-Andre wrote: >=20 > > On 4/14/11 3:56 PM, Eran Hammer-Lahav wrote: > > > > > > > >> In practice, this invents a new HTTP authentication scheme. > > > > Eran, during the WG meeting in Prague you said the same thing, and I > > tend to agree. Yes, client authentication is a good thing, but given > > that OAuth happens over HTTP I don't see why we can't just use > > existing HTTP authentication schemes. If BASIC and DIGEST aren't good > > enough, then someone needs to develop a new HTTP authentication > > scheme. However that's not a job for the OAuth WG as far as I can see..= . > > > > Peter > > > > -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Apr 14 15:49:55 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CC9CBE0711 for ; Thu, 14 Apr 2011 15:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ot4aEbjGYjs0 for ; Thu, 14 Apr 2011 15:49:55 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id E0E28E06AC for ; Thu, 14 Apr 2011 15:49:54 -0700 (PDT) Received: (qmail 768 invoked from network); 14 Apr 2011 22:49:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Apr 2011 22:49:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 14 Apr 2011 15:49:42 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , Phil Hunt , Peter Saint-Andre Date: Thu, 14 Apr 2011 15:49:32 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv69R55i16+ieZVTEGSWJpJjqei5gAAFT6wAAAbkgA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723446567441AB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72344656744185@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DA76FF6.2070105@stpeter.im> <4C1DF2DE-64A4-42BA-99D1-778D7AD9EEC7@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723446567441A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723446567441A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 14 Apr 2011 22:49:55 -0000 (sorry for the fragmented post) And to be clear, my feedback is in no way an endorsement of including this = text. I am still strongly opposed to it for the primary reason that it is n= one of this WG business in general, and the OAuth specification in particul= ar, to invent new HTTP authentication schemes. My feedback is provided in c= ase there is overwhelming support for inclusion, to make it less damaging, = if I'm instructed by the chairs to include it (and yes, I will require clea= r instructions from the chairs before I touch this). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Thursday, April 14, 2011 3:47 PM > To: Phil Hunt; Peter Saint-Andre > Cc: oauth > Subject: Re: [OAUTH-WG] Revised Section 3 >=20 > My current project uses MAC authentication for client authentication at t= he > token endpoint. I would be helpful if people explicitly express their vie= ws on > the proposed text, and whether they support or object to it. >=20 > EHL >=20 > > -----Original Message----- > > From: Phil Hunt [mailto:phil.hunt@oracle.com] > > Sent: Thursday, April 14, 2011 3:41 PM > > To: Peter Saint-Andre > > Cc: Eran Hammer-Lahav; oauth > > Subject: Re: [OAUTH-WG] Revised Section 3 > > > > +1 > > > > There is the issue of how a client app 'bootstraps' its own credential.= It > could > > be that it authenticates by some other RFC (like 2617 Basic Auth), or s= ome > > other method. E.g. would be nice to have a way for client apps to obta= in > > either the equivalent of client_assertion, or even a MAC token > representing > > just the client security context (a turtles-all-the-way-down approach). > > > > Regardless, I agree this isn't part of the core OAuth specification. > > > > Phil > > phil.hunt@oracle.com > > > > > > > > > > On 2011-04-14, at 3:06 PM, Peter Saint-Andre wrote: > > > > > On 4/14/11 3:56 PM, Eran Hammer-Lahav wrote: > > > > > > > > > > > >> In practice, this invents a new HTTP authentication scheme. > > > > > > Eran, during the WG meeting in Prague you said the same thing, and I > > > tend to agree. Yes, client authentication is a good thing, but given > > > that OAuth happens over HTTP I don't see why we can't just use > > > existing HTTP authentication schemes. If BASIC and DIGEST aren't good > > > enough, then someone needs to develop a new HTTP authentication > > > scheme. However that's not a job for the OAuth WG as far as I can see= ... > > > > > > Peter > > > > > > -- > > > Peter Saint-Andre > > > https://stpeter.im/ > > > > > > > > > > > > _______________________________________________ > > > 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 James.H.Manger@team.telstra.com Thu Apr 14 20:47:19 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6E1CBE0715 for ; Thu, 14 Apr 2011 20:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKtN0CkUs5AX for ; Thu, 14 Apr 2011 20:47:18 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfc.amsl.com (Postfix) with ESMTP id 71CD5E06A6 for ; Thu, 14 Apr 2011 20:47:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,215,1301839200"; d="scan'208";a="30292462" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 15 Apr 2011 13:47:15 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6316"; a="23748613" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbvi.tcif.telstra.com.au with ESMTP; 15 Apr 2011 13:47:15 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Fri, 15 Apr 2011 13:47:13 +1000 From: "Manger, James H" To: oauth Date: Fri, 15 Apr 2011 13:47:11 +1000 Thread-Topic: Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9A= Message-ID: <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Revised Section 3 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, 15 Apr 2011 03:47:19 -0000 I'm certainly in favour of excluding client auth from OAuth. Dropping secti= on 3 and just having a paragraph like the following would be preferable (wi= th no capitalized keywords): In many cases an authorization server will require client authentication for requests to a token endpoint. Consequently, a client app that has credentials appropriate for that server should proactively use them for such requests. The actual mechanism for client authentication, and any provisioning of the associated credentials, is outside the scope of OAuth 2. =20 I am not a fan of the client_id/client_secret parameters, but was resigned = to their inclusion given existing deployments. Given those parameters are m= entioned, OAuth2 should say: Various early deployments of the OAuth 2.0 concepts authenticated clients to the token endpoint using client_id and client_secret parameters in the request (alongside the grant_type parameter for instance). A server that accepts client_id/client_secret parameters MUST also accept the same credentials presented using the HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." request header). The last paragraph of Thomas's "3.2 Shared Secret Credentials" is crazy (ty= po?). A server supporting some strong authentication mechanism must not be = mandated to also support weaker BASIC and client_id/client_secret mechanism= s -- and certainly not with the same secret! "3.3 Client Assertion Credentials". OAuth2 currently supports the concept o= f a client app swapping an assertion for an access token. Do people want th= e additional functionality of using assertions for generic client authentic= ation? I assumed servers would prefer that clients swap an assertion for a = token at one specific endpoint, then use the token for generic client auth = in other requests -- in which case section 3.3 "Client Assertion Credential= s" can be dropped. -- James Manger From wmills@yahoo-inc.com Thu Apr 14 20:56:20 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 23F75E06A6 for ; Thu, 14 Apr 2011 20:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEvqHD8vjULw for ; Thu, 14 Apr 2011 20:56:19 -0700 (PDT) Received: from nm9-vm0.bullet.mail.sp2.yahoo.com (nm9-vm0.bullet.mail.sp2.yahoo.com [98.139.91.196]) by ietfc.amsl.com (Postfix) with SMTP id 97C63E0668 for ; Thu, 14 Apr 2011 20:56:18 -0700 (PDT) Received: from [98.139.91.65] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 15 Apr 2011 03:56:13 -0000 Received: from [98.139.91.20] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 15 Apr 2011 03:56:13 -0000 Received: from [127.0.0.1] by omp1020.mail.sp2.yahoo.com with NNFMP; 15 Apr 2011 03:56:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 339817.14631.bm@omp1020.mail.sp2.yahoo.com Received: (qmail 50977 invoked by uid 60001); 15 Apr 2011 03:56:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302839772; bh=3rjuapnuS0DsQxDVmQZ3Ygjv2+v6hKfAL2B9LTK2hqU=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=EHAFvSphmjxKJv45oPAyM7Gf6cJ+qJ+dH2yTg7lu/ijPM9ADS+IIpJNK6Z4sg38UjeXao69mvMbFuiHVRTLHIgqL8E1ZGhDj3n5M5tK2Z3flpv0MLrmBCFvqdJPUTAaOZxsbEX5LPXqcJIPQDepNMXadCFklxml7LdtnVetNcLA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=U08wq2K5/PhLytoiVal5f2b2V8cHno2hlypNQP9aukefzCZu1TE70tKYJ71OQ70Hp/4RTFU+MqME6L45i872syRuNUgjfZl1l0QsYqHXbWAlVk91nSNiAOfhfEcJBQbm26ZdwKMqRA6tQ7bTmw5zQS1j6dfKrISkYRfHLHgE5KI=; Message-ID: <775615.76801.qm@web31801.mail.mud.yahoo.com> X-YMail-OSG: uYugnj4VM1kV9UVCZCOU1SWScGxD_9QybC_m6Obzjp2bAPO 9TGNbcIZjA_wu9HKoyElPb3J1jtYk_MZXWS5xmg8bcPLkLkpetGlIG_9iuTt 1_DHTel7hSe5eVtPpsp_L.r1VhPKBLcHOtln2rA897ap5anU.ZT8jS_3kW5O 6chIvVyUsCkQG7fQhltnceQ9DOwVQJ.RWdC430nXNC7K0_ZfsVFsGKyLS0jk hx2.Z84e8rthvaoR8X5tQeF8s3Pnvb6poseSQuuJp1qfg4yA1Z1aY2q9oXHb OJGvz8sHwmUSTkYBSSiKYL3i7p27AnHS5pB62rXC8NqFEZniJr47RDNiX1kn sFGmziwJXqhte79nYqUHr Received: from [99.31.212.42] by web31801.mail.mud.yahoo.com via HTTP; Thu, 14 Apr 2011 20:56:12 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 14 Apr 2011 20:56:12 -0700 (PDT) From: "William J. Mills" To: "Manger, James H" , oauth In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-927765824-1302839772=:76801" Subject: Re: [OAUTH-WG] Revised Section 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 03:56:20 -0000 --0-927765824-1302839772=:76801 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Authenticating a piece of software isn't how I view the utility of the clie= nt id and secret.=A0 It is extremely useful for site to site authentication= where a trust relationship CAN be maintained.=A0 We really don't want to l= ose that functionality.=0A=0A=0A=0A________________________________=0AFrom:= "Manger, James H" =0ATo: oauth =0ASent: Thursday, April 14, 2011 8:47 PM=0ASubject: Re: [OAUTH-WG] R= evised Section 3=0A=0AI'm certainly in favour of excluding client auth from= OAuth. Dropping section 3 and just having a paragraph like the following w= ould be preferable (with no capitalized keywords):=0A=0A=A0 In many cases a= n authorization server will require client=0A=A0 authentication for request= s to a token endpoint.=0A=A0 Consequently, a client app that has credential= s appropriate=0A=A0 for that server should proactively use them for such re= quests.=0A=A0 The actual mechanism for client authentication, and any=0A=A0= provisioning of the associated credentials, is outside=0A=A0 the scope of = OAuth 2.=0A=0A=0AI am not a fan of the client_id/client_secret parameters, = but was resigned to their inclusion given existing deployments. Given those= parameters are mentioned, OAuth2 should say:=0A=0A=A0 Various early deploy= ments of the OAuth 2.0 concepts authenticated=0A=A0 clients to the token en= dpoint using client_id and client_secret=0A=A0 parameters in the request (a= longside the grant_type parameter=0A=A0 for instance). A server that accept= s client_id/client_secret=0A=A0 parameters MUST also accept the same creden= tials presented using the=0A=A0 HTTP BASIC scheme instead (ie in an "Author= ization: BASIC ..." request=0A=A0 header).=0A=0A=0AThe last paragraph of Th= omas's "3.2 Shared Secret Credentials" is crazy (typo?). A server supportin= g some strong authentication mechanism must not be mandated to also support= weaker BASIC and client_id/client_secret mechanisms -- and certainly not w= ith the same secret!=0A=0A"3.3 Client Assertion Credentials". OAuth2 curren= tly supports the concept of a client app swapping an assertion for an acces= s token. Do people want the additional functionality of using assertions fo= r generic client authentication? I assumed servers would prefer that client= s swap an assertion for a token at one specific endpoint, then use the toke= n for generic client auth in other requests -- in which case section 3.3 "C= lient Assertion Credentials" can be dropped.=0A=0A--=0AJames Manger=0A=0A__= _____________________________________________=0AOAuth mailing list=0AOAuth@= ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-927765824-1302839772=:76801 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Authenticating a piece of software isn't how I view the utility of the cl= ient id and secret.  It is extremely useful for site to site authentic= ation where a trust relationship CAN be maintained.  We really don't w= ant to lose that functionality.

From: "Manger, James H" <James.H.M= anger@team.telstra.com>
To: oauth <oauth@ietf.org>
Sent: Thursday, April 14, 2011 8:47 PM
Subject: Re: [OAUTH-WG] Revised Section 3

= =0AI'm certainly in favour of excluding client auth from OAuth. Dropping se= ction 3 and just having a paragraph like the following would be preferable = (with no capitalized keywords):

  In many cases an authorizatio= n server will require client
  authentication for requests to a tok= en endpoint.
  Consequently, a client app that has credentials appr= opriate
  for that server should proactively use them for such requ= ests.
  The actual mechanism for client authentication, and any
=   provisioning of the associated credentials, is outside
  the= scope of OAuth 2.


I am not a fan of the client_id/client_secre= t parameters, but was resigned to their inclusion given existing deployment= s. Given those parameters are mentioned, OAuth2 should say:

  V= arious early deployments of the OAuth 2.0 concepts authenticated
  = clients to the token endpoint using client_id and client_secret
  parameters in the request (alongside the grant_typ= e parameter
  for instance). A server that accepts client_id/client= _secret
  parameters MUST also accept the same credentials presente= d using the
  HTTP BASIC scheme instead (ie in an "Authorization: B= ASIC ..." request
  header).


The last paragraph of Thoma= s's "3.2 Shared Secret Credentials" is crazy (typo?). A server supporting s= ome strong authentication mechanism must not be mandated to also support we= aker BASIC and client_id/client_secret mechanisms -- and certainly not with= the same secret!

"3.3 Client Assertion Credentials". OAuth2 current= ly supports the concept of a client app swapping an assertion for an access= token. Do people want the additional functionality of using assertions for= generic client authentication? I assumed servers would prefer that clients= swap an assertion for a token at one specific endpoint, then use the token for generic client auth in other requests -- in which case secti= on 3.3 "Client Assertion Credentials" can be dropped.

--
James Ma= nger

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

--0-927765824-1302839772=:76801-- From eran@hueniverse.com Thu Apr 14 22:14:32 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7A9B0E074B for ; Thu, 14 Apr 2011 22:14:32 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xorgwulHyWPY for ; Thu, 14 Apr 2011 22:14:28 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id 77C0AE06E1 for ; Thu, 14 Apr 2011 22:14:28 -0700 (PDT) Received: (qmail 12763 invoked from network); 15 Apr 2011 05:14:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Apr 2011 05:14:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 14 Apr 2011 22:13:49 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , "Manger, James H" , oauth Date: Thu, 14 Apr 2011 22:13:40 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv7IRb+abRTahdKRLeXfVNE6GyiSwACefOw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723446567441F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <775615.76801.qm@web31801.mail.mud.yahoo.com> In-Reply-To: <775615.76801.qm@web31801.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723446567441F7P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Revised Section 3 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, 15 Apr 2011 05:14:32 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723446567441F7P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The key here is that client authentication in this context is clearly HTTP = authentication. This isn't about changing any functionality, but about how = to be provide it. The two opposing views (generalized) are: 1. Limit section 3: the specification should simply rely on HTTP authentica= tion and any new authentication scheme, such as the proposed client asserti= on credentials, be defined as new HTTP authentication schemes. There is not= hing unique to client authentication in OAuth that isn't already present in= other HTTP authentication schemes (and framework). 2. Expand section 3: the specification should explicitly define methods for= authenticating the client using parameters instead of the HTTP authenticat= ion headers. The client password credentials reflects an existing, deployed= practice, and the client assertion credentials provide an extension point = desired by existing enterprise use cases. At the end, the resolution of this issue is going to be around where to dra= w the line between specifying no custom client authentication to inventing = 2 or more parameter-based methods, and potentially calling out specific HTT= P schemes as well (e.g. Basic). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of W= illiam J. Mills Sent: Thursday, April 14, 2011 8:56 PM To: Manger, James H; oauth Subject: Re: [OAUTH-WG] Revised Section 3 Authenticating a piece of software isn't how I view the utility of the clie= nt id and secret. It is extremely useful for site to site authentication w= here a trust relationship CAN be maintained. We really don't want to lose = that functionality. ________________________________ From: "Manger, James H" To: oauth Sent: Thursday, April 14, 2011 8:47 PM Subject: Re: [OAUTH-WG] Revised Section 3 I'm certainly in favour of excluding client auth from OAuth. Dropping secti= on 3 and just having a paragraph like the following would be preferable (wi= th no capitalized keywords): In many cases an authorization server will require client authentication for requests to a token endpoint. Consequently, a client app that has credentials appropriate for that server should proactively use them for such requests. The actual mechanism for client authentication, and any provisioning of the associated credentials, is outside the scope of OAuth 2. I am not a fan of the client_id/client_secret parameters, but was resigned = to their inclusion given existing deployments. Given those parameters are m= entioned, OAuth2 should say: Various early deployments of the OAuth 2.0 concepts authenticated clients to the token endpoint using client_id and client_secret parameters in the request (alongside the grant_type parameter for instance). A server that accepts client_id/client_secret parameters MUST also accept the same credentials presented using the HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." request header). The last paragraph of Thomas's "3.2 Shared Secret Credentials" is crazy (ty= po?). A server supporting some strong authentication mechanism must not be = mandated to also support weaker BASIC and client_id/client_secret mechanism= s -- and certainly not with the same secret! "3.3 Client Assertion Credentials". OAuth2 currently supports the concept o= f a client app swapping an assertion for an access token. Do people want th= e additional functionality of using assertions for generic client authentic= ation? I assumed servers would prefer that clients swap an assertion for a = token at one specific endpoint, then use the token for generic client auth = in other requests -- in which case section 3.3 "Client Assertion Credential= s" can be dropped. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723446567441F7P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The key h= ere is that client authentication in this context is clearly HTTP authentic= ation. This isn’t about changing any functionality, but about how to = be provide it. The two opposing views (generalized) are:<= /p>

 

1. Limit section 3: the specification should simply rely on HTT= P authentication and any new authentication scheme, such as the proposed cl= ient assertion credentials, be defined as new HTTP authentication schemes. = There is nothing unique to client authentication in OAuth that isn’t = already present in other HTTP authentication schemes (and framework).<= /o:p>

 

2. Expand section 3: the specification should expl= icitly define methods for authenticating the client using parameters instea= d of the HTTP authentication headers. The client password credentials refle= cts an existing, deployed practice, and the client assertion credentials pr= ovide an extension point desired by existing enterprise use cases.

 

At the end, the resolution of this issue is going to = be around where to draw the line between specifying no custom client authen= tication to inventing 2 or more parameter-based methods, and potentially ca= lling out specific HTTP schemes as well (e.g. Basic).

=

 

EHL

 

 

 

<= p class=3DMsoNormal>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.o= rg] On Behalf Of William J. Mills
Sent: Thursday, April 14= , 2011 8:56 PM
To: Manger, James H; oauth
Subject: Re: = [OAUTH-WG] Revised Section 3

 

Authentic= ating a piece of software isn't how I view the utility of the client id and= secret.  It is extremely useful for site to site authentication where= a trust relationship CAN be maintained.  We really don't want to lose= that functionality.

 

From: "Manger, = James H" <James.H.Manger@team.telstra.com>
To: oauth &= lt;oauth@ietf.org>
Sent: Thursday, April 14, 2011 8:47 PM
<= b>Subject: Re: [OAUTH-WG] Revised Section 3

I'm certainly in favour of excluding client auth from OAuth.= Dropping section 3 and just having a paragraph like the following would be= preferable (with no capitalized keywords):

  In many cases an = authorization server will require client
  authentication for reque= sts to a token endpoint.
  Consequently, a client app that has cred= entials appropriate
  for that server should proactively use them f= or such requests.
  The actual mechanism for client authentication,= and any
  provisioning of the associated credentials, is outside  the scope of OAuth 2.


I am not a fan of the client_id/c= lient_secret parameters, but was resigned to their inclusion given existing= deployments. Given those parameters are mentioned, OAuth2 should say:
<= br>  Various early deployments of the OAuth 2.0 concepts authenticated=
  clients to the token endpoint using client_id and client_secret<= br>  parameters in the request (alongside the grant_type parameter
=   for instance). A server that accepts client_id/client_secret
&nbs= p; parameters MUST also accept the same credentials presented using the
=   HTTP BASIC scheme instead (ie in an "Authorization: BASIC ...&q= uot; request
  header).


The last paragraph of Thomas's &= quot;3.2 Shared Secret Credentials" is crazy (typo?). A server support= ing some strong authentication mechanism must not be mandated to also suppo= rt weaker BASIC and client_id/client_secret mechanisms -- and certainly not= with the same secret!

"3.3 Client Assertion Credentials".= OAuth2 currently supports the concept of a client app swapping an assertio= n for an access token. Do people want the additional functionality of using= assertions for generic client authentication? I assumed servers would pref= er that clients swap an assertion for a token at one specific endpoint, the= n use the token for generic client auth in other requests -- in which case = section 3.3 "Client Assertion Credentials" can be dropped.
--
James Manger

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

= --_000_90C41DD21FB7C64BB94121FBBC2E723446567441F7P3PW5EX1MB01E_-- From eran@hueniverse.com Thu Apr 14 22:14:58 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6E832E077C for ; Thu, 14 Apr 2011 22:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCCRQsAsbXlL for ; Thu, 14 Apr 2011 22:14:57 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 95C69E0781 for ; Thu, 14 Apr 2011 22:14:57 -0700 (PDT) Received: (qmail 592 invoked from network); 15 Apr 2011 05:14:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Apr 2011 05:14:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 14 Apr 2011 22:14:56 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , oauth Date: Thu, 14 Apr 2011 22:14:47 -0700 Thread-Topic: Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AABP5UkA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723446567441F8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Revised Section 3 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, 15 Apr 2011 05:14:58 -0000 I would be very happy with this approach, with the addition of discussing t= he role of the client identifier and that a binding to any client authentic= ation is needed. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Thursday, April 14, 2011 8:47 PM > To: oauth > Subject: Re: [OAUTH-WG] Revised Section 3 >=20 > I'm certainly in favour of excluding client auth from OAuth. Dropping sec= tion > 3 and just having a paragraph like the following would be preferable (wit= h no > capitalized keywords): >=20 > In many cases an authorization server will require client > authentication for requests to a token endpoint. > Consequently, a client app that has credentials appropriate > for that server should proactively use them for such requests. > The actual mechanism for client authentication, and any > provisioning of the associated credentials, is outside > the scope of OAuth 2. >=20 >=20 > I am not a fan of the client_id/client_secret parameters, but was resigne= d to > their inclusion given existing deployments. Given those parameters are > mentioned, OAuth2 should say: >=20 > Various early deployments of the OAuth 2.0 concepts authenticated > clients to the token endpoint using client_id and client_secret > parameters in the request (alongside the grant_type parameter > for instance). A server that accepts client_id/client_secret > parameters MUST also accept the same credentials presented using the > HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." request > header). >=20 >=20 > The last paragraph of Thomas's "3.2 Shared Secret Credentials" is crazy > (typo?). A server supporting some strong authentication mechanism must > not be mandated to also support weaker BASIC and client_id/client_secret > mechanisms -- and certainly not with the same secret! >=20 > "3.3 Client Assertion Credentials". OAuth2 currently supports the concept= of > a client app swapping an assertion for an access token. Do people want th= e > additional functionality of using assertions for generic client authentic= ation? I > assumed servers would prefer that clients swap an assertion for a token a= t > one specific endpoint, then use the token for generic client auth in othe= r > requests -- in which case section 3.3 "Client Assertion Credentials" can = be > dropped. >=20 > -- > James Manger >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From barryleiba.mailing.lists@gmail.com Fri Apr 15 07:29:08 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 47D25E0745 for ; Fri, 15 Apr 2011 07:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.603 X-Spam-Level: X-Spam-Status: No, score=-103.603 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0f0W8XTlkrC for ; Fri, 15 Apr 2011 07:29:04 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id E1A4FE0840 for ; Fri, 15 Apr 2011 07:29:03 -0700 (PDT) Received: by wwa36 with SMTP id 36so2205522wwa.13 for ; Fri, 15 Apr 2011 07:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=/tBzPU7qYOKVeaIEKaxoDqgrQUxDCJx7KhzrxJR7o4Q=; b=G3N2pEGzPWkbC6uS5x5iKiGoAkfONqYJmjNilYAO6FsIRZt/HcRUI0xhNqexSS2Yfj 07L2kY4xtw8eTe0coHOJdhx86kn3HPLg0G1aMJgK94nKZGODOaLFn9NW316vKBvfek0N PDFX1kz+yZSnHVUK5VKWK1jZU1rJKqPmM/JtM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=mextsSCaqpZpDhlF87kNHxtBt2mYI/QRi340fppG+LOr4SMhEXZvQ07Z/FnlB6dTUS uqZvms6JpWQuweLZUrTKuo4A7jBjT0Cxt0Kt/qcaB8bA1axpdABAfjRLGoUxs1UUxUAI pJlrGDHux85NXWLfG93ImdCTs1rYhZ1KwY6F0= MIME-Version: 1.0 Received: by 10.216.69.131 with SMTP id n3mr2090457wed.47.1302877741429; Fri, 15 Apr 2011 07:29:01 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.216.242.71 with HTTP; Fri, 15 Apr 2011 07:29:01 -0700 (PDT) In-Reply-To: <4DA5F50F.6050109@cs.tcd.ie> References: <4DA5F50F.6050109@cs.tcd.ie> Date: Fri, 15 Apr 2011 10:29:01 -0400 X-Google-Sender-Auth: 5nlQFG3jsI-ECctzZG0bfKi9-F8 Message-ID: From: Barry Leiba To: "oauth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] 3rd oauth co-chair - Barry Leiba 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, 15 Apr 2011 14:29:08 -0000 > After chatting with Hannes and Blaine in Prague we figured that > it might help to get a 3rd co-chair for oauth to get the wg over > the line with the base spec and thereafter. Well, we got lucky, > so I'm glad to say Barry Leiba has agreed to take on the role > alongside Hannes and Blaine. ... > I've just mailed the secretariat adding Barry so it might take > a day or so for things to show up on the WG page. To those who have commented, thanks... and I hope I can help with the management workload. I see that the updates have been made, and I'm showing up as a chair now. The next two things we (the chairs) will be doing is drafting a charter update to focus the remaining near-term work reflect where we current are, and putting open issues into the tools issue tracker ( http://trac.tools.ietf.org/wg/oauth/trac/report/1 ), which right now just has two year-old issues open. I'll be sorting that part out over the next few days, starting with issues that Eran has flagged in the -15 draft version, along with some others. I'll post about the issue tracker again when we think we've gotten the open issues in there, so people can review them and see if we've missed some. And then we can all work on getting them closed, and getting the OAuth v2 spec finished. Barry, as new chair From trac+oauth@trac.tools.ietf.org Fri Apr 15 07:51:17 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 28895E06C2 for ; Fri, 15 Apr 2011 07:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.308 X-Spam-Level: X-Spam-Status: No, score=-101.308 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx2t7V+IsIjt for ; Fri, 15 Apr 2011 07:51:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 79EDDE07C1 for ; Fri, 15 Apr 2011 07:51:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAkMZ-0000aW-HI for oauth@ietf.org; Fri, 15 Apr 2011 07:51:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Cc: oauth@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software X-Trac-Project: oauth Date: Fri, 15 Apr 2011 14:51:11 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/7 Message-ID: <051.83a0addeca9e2959f66b5e6b1c472d61@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 15 Apr 2011 07:52:04 -0700 Subject: [OAUTH-WG] [oauth] #7: Incorporate Security Considerations draft into OAuth base X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 14:51:17 -0000 #7: Incorporate Security Considerations draft into OAuth base -- --------------------------------+------------------------------------------- Reporter: Barry Leiba | Owner: Type: task | Status: new Priority: blocker | Milestone: Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Apr 15 08:03:20 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5D6AEE08A8 for ; Fri, 15 Apr 2011 08:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.308 X-Spam-Level: X-Spam-Status: No, score=-101.308 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuQad4sMpoUR for ; Fri, 15 Apr 2011 08:03:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id ECFB8E08B6 for ; Fri, 15 Apr 2011 08:03:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAkYC-0007K5-Bk for oauth@ietf.org; Fri, 15 Apr 2011 08:03:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Cc: oauth@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software X-Trac-Project: oauth Date: Fri, 15 Apr 2011 15:03:12 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/8 Message-ID: <057.9a63990a1cb32cd95c16da6d299242c5@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 15 Apr 2011 08:03:57 -0700 Subject: [OAUTH-WG] [oauth] #8: 4.1.2.1, text for 4xx or 5xx HTTP status code X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:03:20 -0000 #8: 4.1.2.1, text for 4xx or 5xx HTTP status code Pending Consensus: The authorization server MAY set the "error" parameter value to a numerical HTTP status code from the 4xx or 5xx range, with the exception of the 400 (Bad Request) and 401 (Unauthorized) status codes. For example, if the service is temporarily unavailable, the authorization server MAY return an error response with "error" set to "503". -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Apr 15 08:05:48 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 763EBE08C8 for ; Fri, 15 Apr 2011 08:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.308 X-Spam-Level: X-Spam-Status: No, score=-101.308 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIECM9QzbxGw for ; Fri, 15 Apr 2011 08:05:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id E6DA7E0796 for ; Fri, 15 Apr 2011 08:05:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAkad-0007Tq-CX for oauth@ietf.org; Fri, 15 Apr 2011 08:05:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Cc: oauth@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software X-Trac-Project: oauth Date: Fri, 15 Apr 2011 15:05:43 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/9 Message-ID: <057.80f2953d4a1049111596933a3f8cff2e@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 15 Apr 2011 08:06:59 -0700 Subject: [OAUTH-WG] [oauth] #9: 5.2, text for non-400 & 401 error conditions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:05:48 -0000 #9: 5.2, text for non-400 & 401 error conditions Pending Consensus: If the authorization server encounters an error condition other than the 400 (Bad Request) and 401 (Unauthorized) responses described above (e.g. the service is temporarily unavailable), the authorization server SHOULD include an error response in the entity body, and set the "error" parameter value to the numerical HTTP status code returned. -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Apr 15 08:08:12 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C082EE08AE for ; Fri, 15 Apr 2011 08:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.308 X-Spam-Level: X-Spam-Status: No, score=-101.308 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9wwNS12l24o for ; Fri, 15 Apr 2011 08:08:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 43ED7E0796 for ; Fri, 15 Apr 2011 08:08:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAkcx-0007XI-Ps for oauth@ietf.org; Fri, 15 Apr 2011 08:08:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Cc: oauth@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software X-Trac-Project: oauth Date: Fri, 15 Apr 2011 15:08:07 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 Message-ID: <057.27a13fb0813ce1eff49107833d51ba4c@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Subject: [OAUTH-WG] [oauth] #10: 8.4. Defining Additional Error Codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:08:12 -0000 #10: 8.4. Defining Additional Error Codes Pending Consensus: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the token error response (Section 5.2), such error codes MAY be defined. Extension error codes MUST be registered (following the procedures in Section 10.3) if the extension they are used in conjunction with is registered. Additional error codes used with unregistered extensions MAY be registered. Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" should be named "example_invalid". error-code = ALPHA *error-char error-char = "-" / "." / "_" / DIGIT / ALPHA -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Apr 15 08:11:13 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A05C8E0906 for ; Fri, 15 Apr 2011 08:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.308 X-Spam-Level: X-Spam-Status: No, score=-101.308 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQZnOPrjYlr5 for ; Fri, 15 Apr 2011 08:11:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 9DFE7E0699 for ; Fri, 15 Apr 2011 08:11:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAkfs-0007lC-2x for oauth@ietf.org; Fri, 15 Apr 2011 08:11:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Cc: oauth@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software X-Trac-Project: oauth Date: Fri, 15 Apr 2011 15:11:08 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/11 Message-ID: <057.87dfe70ac9df8542cc9518e11f11bb27@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Subject: [OAUTH-WG] [oauth] #11: 10.3. The OAuth Extensions Error Registry X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:11:13 -0000 #11: 10.3. The OAuth Extensions Error Registry Pending Consensus: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app- ads@tools.ietf.org email address or directly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Apr 15 08:16:13 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 93EF1E0709 for ; Fri, 15 Apr 2011 08:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tnJiVRcC7wk for ; Fri, 15 Apr 2011 08:16:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 8A609E0754 for ; Fri, 15 Apr 2011 08:16:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAkkg-0005Wj-OD; Fri, 15 Apr 2011 08:16:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Fri, 15 Apr 2011 15:16:06 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/8#comment:1 Message-ID: <066.5116960ce16741ad21acc4b43f039186@trac.tools.ietf.org> References: <057.9a63990a1cb32cd95c16da6d299242c5@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <057.9a63990a1cb32cd95c16da6d299242c5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #8: 4.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code (was: 4.1.2.1, text for 4xx or 5xx HTTP status code) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:16:13 -0000 #8: 4.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Apr 15 08:21:11 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 017A9E087C for ; Fri, 15 Apr 2011 08:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.062 X-Spam-Level: X-Spam-Status: No, score=-102.062 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NzTpCNC8jOx for ; Fri, 15 Apr 2011 08:21:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 55A93E0874 for ; Fri, 15 Apr 2011 08:21:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAkpP-0004cs-RS; Fri, 15 Apr 2011 08:20:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Fri, 15 Apr 2011 15:20:59 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/7#comment:1 Message-ID: <060.cb81a932bba1ae6a9bbcf612c44b6668@trac.tools.ietf.org> References: <051.83a0addeca9e2959f66b5e6b1c472d61@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <051.83a0addeca9e2959f66b5e6b1c472d61@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #7: Incorporate Security Considerations draft into OAuth base X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:21:11 -0000 #7: Incorporate Security Considerations draft into OAuth base Changes (by barryleiba@…): * milestone: => Deliver OAuth 2.0 spec -- --------------------------------+------------------------------------------- Reporter: Barry Leiba | Owner: Type: task | Status: new Priority: blocker | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Apr 15 08:28:10 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6A5D5E071E for ; Fri, 15 Apr 2011 08:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.493 X-Spam-Level: X-Spam-Status: No, score=-101.493 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 152rZ-wpe-BZ for ; Fri, 15 Apr 2011 08:28:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id BA033E070B for ; Fri, 15 Apr 2011 08:28:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAkwF-000317-Kp for oauth@ietf.org; Fri, 15 Apr 2011 08:28:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Cc: oauth@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software X-Trac-Project: oauth Date: Fri, 15 Apr 2011 15:28:03 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/12 Message-ID: <050.5a45fca9b64c743145764baea0d685c6@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Subject: [OAUTH-WG] [oauth] #12: Restore WWW-Authenticate response to the framework specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:28:10 -0000 #12: Restore WWW-Authenticate response to the framework specification This is a capability that was present in WRAP and earlier OAuth drafts that was removed without consensus to do so. The result has been that there is different and incompatible WWW-Authenticate response functionality in multiple related drafts – specifically draft-hammer- oauth-v2-mac-token-02 and draft-ietf-oauth-v2-bearer-04. Interoperability and developers would both be better served by moving this functionality back into the core. We don’t believe that each related OAuth specification should have to separately specify this functionality. http://www.ietf.org/mail-archive/web/oauth/current/msg06057.html Mike Jones: Having thought about it overnight and discussed it, I’m willing to drop my objection the WWW-Authenticate response not being in the framework specification, so as to close an open issue that could delay completion of the specifications. -- --------------------------------+------------------------------------------- Reporter: Mike Jones | Owner: Type: defect | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Apr 15 08:34:12 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 33E32E0867 for ; Fri, 15 Apr 2011 08:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldiBbxKz7BzW for ; Fri, 15 Apr 2011 08:34:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 8232BE069F for ; Fri, 15 Apr 2011 08:34:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAl25-00041F-Uy; Fri, 15 Apr 2011 08:34:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Fri, 15 Apr 2011 15:34:05 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/11#comment:1 Message-ID: <066.ebeef6e09c34b53133453bd5240c7942@trac.tools.ietf.org> References: <057.87dfe70ac9df8542cc9518e11f11bb27@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <057.87dfe70ac9df8542cc9518e11f11bb27@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #11: 10.3. The OAuth Extensions Error Registry X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:34:12 -0000 #11: 10.3. The OAuth Extensions Error Registry Description changed by barryleiba@…: Old description: > Pending Consensus: > > 10.3. The OAuth Extensions Error Registry > > This specification establishes the OAuth extensions error registry. > > Additional error codes used together with other protocol extensions (i.e. > extension grant types, access token types, or extension parameters) are > registered on the advice of one or more Designated Experts (appointed by > the IESG or their delegate), with a Specification Required (using > terminology from [RFC5226]). However, to allow for the allocation of > values prior to publication, the Designated Expert(s) may approve > registration once they are satisfied that such a specification will be > published. > > Registration requests should be sent to the [TBD]@ietf.org mailing list > for review and comment, with an appropriate subject (e.g., "Request for > error code: example"). [[ Note to RFC-EDITOR: The name of the mailing > list should be determined in consultation with the IESG and IANA. > Suggested name: oauth-ext-review. ]] > > Within at most 14 days of the request, the Designated Expert(s) will > either approve or deny the registration request, communicating this > decision to the review list and IANA. Denials should include an > explanation and, if applicable, suggestions as to how to make the request > successful. > > Decisions (or lack thereof) made by the Designated Expert can be first > appealed to Application Area Directors (contactable using app- > ads@tools.ietf.org email address or directly by looking up their email > addresses on http://www.iesg.org/ website) and, if the appellant is not > satisfied with the response, to the full IESG (using the iesg@iesg.org > mailing list). > > IANA should only accept registry updates from the Designated Expert(s), > and should direct all requests for registration to the review mailing > list. New description: Pending Consensus: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app- ads@tools.ietf.org email address or directly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. ---------------------------------------------- Tony Nadalin: The remaining technical issue in this regard is the need to expand the scope of the registry to encompass errors returned from resource servers. The error registry was introduced to address a requirement that existed in the working group documents prior to the split. This requirement was expressed in draft 10, Section 3.2.1 and draft 11, Section 4.3.1 as "[[ Add mechanism for extending error codes ]]". -- -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Apr 15 08:36:11 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 04E8FE0745 for ; Fri, 15 Apr 2011 08:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.523 X-Spam-Level: X-Spam-Status: No, score=-101.523 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y81gRQkW3WM for ; Fri, 15 Apr 2011 08:36:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 7417EE069F for ; Fri, 15 Apr 2011 08:36:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAl41-0000nl-WA for oauth@ietf.org; Fri, 15 Apr 2011 08:36:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Cc: oauth@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software X-Trac-Project: oauth Date: Fri, 15 Apr 2011 15:36:05 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/13 Message-ID: <052.b8247962e9bedfe0bbb8d9832d0308ce@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Subject: [OAUTH-WG] [oauth] #13: Description of how native applications can use OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:36:11 -0000 #13: Description of how native applications can use OAuth 2.0 This was a description that was important to developers and deployers that was present in the specification and was removed without consensus to do so. -- --------------------------------+------------------------------------------- Reporter: Tony Nadalin | Owner: Type: defect | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Apr 15 08:37:28 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 19404E08CD for ; Fri, 15 Apr 2011 08:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.502 X-Spam-Level: X-Spam-Status: No, score=-101.502 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erKMABJpoprh for ; Fri, 15 Apr 2011 08:37:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 8E3A3E070B for ; Fri, 15 Apr 2011 08:37:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAl5H-0003oA-2a for oauth@ietf.org; Fri, 15 Apr 2011 08:37:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Cc: oauth@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software X-Trac-Project: oauth Date: Fri, 15 Apr 2011 15:37:23 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/14 Message-ID: <052.1c28e50da24b0bd8d7c90fd6220e3475@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Subject: [OAUTH-WG] [oauth] #14: Restoring Client Assertion Credentials to the framework specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:37:28 -0000 #14: Restoring Client Assertion Credentials to the framework specification There was no clear consensus on the list to remove this. -- --------------------------------+------------------------------------------- Reporter: Tony Nadalin | Owner: Type: defect | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From phil.hunt@oracle.com Fri Apr 15 09:32:31 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8E6A113001A for ; Fri, 15 Apr 2011 09:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crcmE-is0RHb for ; Fri, 15 Apr 2011 09:32:27 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfc.amsl.com (Postfix) with ESMTP id 6F703E0681 for ; Fri, 15 Apr 2011 09:32:27 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p3FGWLwa015258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Apr 2011 16:32:22 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p3FGWKWj021013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2011 16:32:20 GMT Received: from abhmt013.oracle.com (abhmt013.oracle.com [141.146.116.22]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p3FGVJEA009153; Fri, 15 Apr 2011 11:31:19 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Apr 2011 09:31:18 -0700 From: Phil Hunt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-33-307846459 Date: Fri, 15 Apr 2011 09:31:17 -0700 References: <052.1c28e50da24b0bd8d7c90fd6220e3475@trac.tools.ietf.org> To: Barry Leiba , romeda@gmail.com, Hannes Tschofenig Message-Id: X-Mailer: Apple Mail (2.1084) X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4DA87315.001E:SCFSTAT5015188,ss=1,fgs=0 Cc: oauth WG Subject: [OAUTH-WG] Consensus process 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, 15 Apr 2011 16:32:31 -0000 --Apple-Mail-33-307846459 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Chairs, I want to thank you for the re-introduction of the issues tracker. This = will greatly assist in tracking issues and building consensus. Below is = an example of a case where I thought consensus had been achieved, but = arguably where the Tony and Mike continued to disagree. We always hope = to have everyone agree, but in some cases, unanimous consensus may not = be possible. In other cases, we may not have explored the problem far = enough. It's clear to me, that the consensus process is important. I hope that the issue tracker will help a lot in this area--but it may = not be sufficient. In the past, we have had email votes, but the feedback was these email = votes are guidance only. This leaves me confused as to how consensus is = being achieved. Can the chairs clarify on what you believe the process = is for the OAuth WG? There is also an issue that at times consensus is asked for far too = early when the proposals to be voted on are often unacceptable to a = significant community (case in point, the scenario below). As everyone = knows, I've been in the same position several times myself. I often have = the view that the problem isn't being addressed. Before moving to a = vote, there may need to be agreement on the problem definition first, = any necessary constraints, and the requirements for a solution. =20 I want to acknowledge everyone's efforts here. This has been a big = specification with lots of issues to solve. We're at the end-game and it = can be frustrating ironing out the final issues. I have greater = confidence that items will be properly tracked and handled but would = like to see the consensus process improved/communicated as well. Best Regards, Phil Begin forwarded message: > From: "oauth issue tracker" > Date: April 15, 2011 8:37:23 AM PDT > Cc: oauth@ietf.org > Subject: [OAUTH-WG] [oauth] #14: Restoring Client Assertion = Credentials to the framework specification >=20 > #14: Restoring Client Assertion Credentials to the framework = specification >=20 > There was no clear consensus on the list to remove this. >=20 > --=20 > = --------------------------------+-----------------------------------------= -- > Reporter: Tony Nadalin | Owner: =20= > Type: defect | Status: new =20= > Priority: major | Milestone: Deliver OAuth 2.0 spec > Component: v2 | Version: =20= > Severity: Active WG Document | Keywords: =20= > = --------------------------------+-----------------------------------------= -- >=20 > Ticket URL: > oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-33-307846459 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Phil

Begin forwarded message:

From: "oauth issue = tracker" <trac+oauth@zinfandel.t= ools.ietf.org>
Date: April 15, 2011 8:37:23 AM PDT
Subject: [OAUTH-WG] = [oauth] #14: Restoring Client Assertion Credentials to the framework = specification

#14: Restoring Client = Assertion Credentials to the framework specification

There was = no clear consensus on the list to remove this.

-- =
--------------------------------+-------------------------------------= ------
Reporter:  Tony Nadalin =        | =       Owner: =             &n= bsp;          
=     Type:  defect =             &n= bsp;|      Status:  new =             &n= bsp;     
Priority:  major =             &n= bsp; |   Milestone:  Deliver OAuth 2.0 = spec
Component:  v2 =             &n= bsp;    |     Version: =             &n= bsp;          
= Severity:  Active WG Document  |    Keywords: =             &n= bsp;          
------= --------------------------+-------------------------------------------
=
Ticket URL: <http://trac.to= ols.ietf.org/wg/oauth/trac/ticket/14>
oauth <http://tools.ietf.org/oauth/>=

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

= --Apple-Mail-33-307846459-- From barryleiba@gmail.com Fri Apr 15 14:45:20 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6E481E06BA for ; Fri, 15 Apr 2011 14:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.749 X-Spam-Level: X-Spam-Status: No, score=-102.749 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wnp8QtAbaB16 for ; Fri, 15 Apr 2011 14:45:19 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 1F520E0674 for ; Fri, 15 Apr 2011 14:45:18 -0700 (PDT) Received: by iye19 with SMTP id 19so3250281iye.31 for ; Fri, 15 Apr 2011 14:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NFoOItZia8lv9KUy9uUaw7/jQY1WMzOXozE94y/q6pY=; b=jt3zHxgQCfX7gqHNOFQDWxupOPxAA+FjlF5mgDZYKqt5zVMc6BAuXHIPn/7bSaWZew rILkGdMkGbJG1FP2vFpVy6iuW5SGSxSaRbwy5uSmRqKekzKHMgUezn0BVZiilBT9glbm Coy9QjYYpYmrPnVQOJ0hqTx0FZC2rlalbkR9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MNteImjMppaTYM26umd3zYhZh0u1iTbwx5+z/k+r0kWtkcIVn0+912JtB64pZElj7z K1jxKABZVl+plBZUJKHTsqoEq7Zjw4nAR5uLf8F9X9Keox8GGzxMLc/SztwSuFeqgcwp J05IfrF70pxbzDC8V7/PCDU8IG87HBwWJyMA4= MIME-Version: 1.0 Received: by 10.42.133.1 with SMTP id f1mr3453704ict.129.1302903917584; Fri, 15 Apr 2011 14:45:17 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.231.36.199 with HTTP; Fri, 15 Apr 2011 14:45:17 -0700 (PDT) In-Reply-To: References: <052.1c28e50da24b0bd8d7c90fd6220e3475@trac.tools.ietf.org> Date: Fri, 15 Apr 2011 17:45:17 -0400 X-Google-Sender-Auth: F-wDW0Xq3OzHNBCOD30-V1ubTIQ Message-ID: From: Barry Leiba To: Phil Hunt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth WG Subject: Re: [OAUTH-WG] Consensus process 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, 15 Apr 2011 21:45:20 -0000 Hi, Phil. I'm glad you brought up this question, because it gives me a good opportunity to clear up some points of IETF process. > I want to thank you for the re-introduction of the issues tracker. This w= ill > greatly assist in tracking issues and building consensus. We hope it will. But, as you say, it's just a tool, and it's really the participants who develop consensus, and the chairs who manage the process. Sometimes, again, as you say, we can come to agreement after some discussion... but sometimes we get to a point where there's still disagreement, and we have to see where the rough consensus is. Not everyone will always be happy, but we hope we can get a result that most of us think will work and is technically sound. > In the past, we have had email votes, but the feedback was these email vo= tes > are guidance only. This leaves me confused as to how consensus is being > achieved. =A0Can the chairs clarify on what you believe the process is fo= r the > OAuth WG? > There is also an issue that at times consensus is asked for far too early > when the proposals to be voted on are often unacceptable to a significant > community Let me start by saying that people sometimes use the word "vote" as a sort of shorthand term, but we need to be clear here: we do not "vote" in the usual sense. It's not just a semantic point, but something that's central to how the IETF works. We work on "rough consensus", and judging that is one of the jobs the chairs have. It doesn't go on a "one participant, one vote" line -- and remember, too, that participants here participate as individuals, so let's not make the mistake of thinking about one or another company's view (or, heavens, "vote"). Here's an example of what I mean by that: suppose we get to a point where, say, 15 people have expressed opinions, and 8 of them fall on one side of an issue, with 7 on the other. If we were "voting", we might say that the 8 votes win. But in most cases we'd say "We don't have rough consensus on this point." In fact, depending upon the issue and the arguments, 9 to 6, or even 10 to 5 might not be enough for "rough consensus". On the other hand, it doesn't have to be 15 to 0. Where rough consensus falls is a judgment the chairs have to make, on an issue-by-issue basis. We might make that differently for a cosmetic issue (the name of a protocol element, say) than for a technical point that has a significant effect on the interoperability, extensibility, or security of the protocol. It's also up to the chairs to decide how long to let the discussion go on, and when to make a consensus decision. Participants are, of course, free to offer their opinions on the matter, and I'm sure you won't be shy about that. But please, everyone: when someone does make such a suggestion, take that as a message to the chairs, and don't act on it unless it's the chairs who say it. We will be the ones issuing "last calls" for comments on issues, requesting straw polls when we think we need to, and so on. And, indeed, we might decide we need a straw poll to tease out the support for particular points. Remember that if we do that, it's not a formal vote, and a slim majority won't necessarily "win". See above. We also need your cooperation on reaching consensus. If you see an opportunity to accede to someone else's view in order to help reach consensus on an issue, please do so. There may be the occasional issue you really feel it's important to dig your heels in on, but most issues aren't like that, and some give and take will help get things finished while keeping the result technically sound -- even if it's not exactly as you'd like it to be. Finally, the chairs don't always get it right, and if you think we're cutting off discussion too soon -- or letting it run too long, beyond the point where it's useful and productive -- please let us know. Most of the time, it'll be best to tell us that *off* the mailing list, to avoid adding to the already busy list traffic with meta-discussion. We'd rather keep the discussion on the list to that which addresses the issues directly. We'll make sure things are recorded on the list for openness and archival purposes. The most convenient way to contact all the chairs together is with the tool alias: Mostly, you needn't copy us on anything that's posted to the mailing list, because we're all subscribed to it. Barry, as chair From trac+oauth@trac.tools.ietf.org Fri Apr 15 15:17:43 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B1D0EE0698 for ; Fri, 15 Apr 2011 15:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.13 X-Spam-Level: X-Spam-Status: No, score=-102.13 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D8IddPaoOyP for ; Fri, 15 Apr 2011 15:17:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 9E577E0688 for ; Fri, 15 Apr 2011 15:17:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QArKU-00028I-VE; Fri, 15 Apr 2011 15:17:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org, eve@xmlgrrl.com, recordond@gmail.com X-Trac-Project: oauth Date: Fri, 15 Apr 2011 22:17:30 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/6#comment:3 Message-ID: <064.da8ada8a50c216ba29d2ab8155bc7e7d@trac.tools.ietf.org> References: <055.9fb7c0e846fc7c9e0cd7acd9189d21e8@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <055.9fb7c0e846fc7c9e0cd7acd9189d21e8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, eve@xmlgrrl.com, recordond@gmail.com, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #6: Make automated self-registration of unique clients possible X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 22:17:43 -0000 #6: Make automated self-registration of unique clients possible Changes (by barryleiba@…): * status: new => closed * resolution: => dead -- -----------------------------+---------------------------------------------- Reporter: eve@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: authentication | Version: Severity: - | Resolution: dead Keywords: | -----------------------------+---------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Apr 15 15:18:37 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1186BE06B1 for ; Fri, 15 Apr 2011 15:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.169 X-Spam-Level: X-Spam-Status: No, score=-102.169 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae0w1BzKVAkP for ; Fri, 15 Apr 2011 15:18:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 81AA5E0688 for ; Fri, 15 Apr 2011 15:18:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QArLV-0003ZZ-JF; Fri, 15 Apr 2011 15:18:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org, james@manger.com.au X-Trac-Project: oauth Date: Fri, 15 Apr 2011 22:18:33 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/5#comment:2 Message-ID: <068.7586b32f8b0d53c2ae61ccfc87a12c6c@trac.tools.ietf.org> References: <059.db44ca9c6a99be8265550c67a11484c4@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <059.db44ca9c6a99be8265550c67a11484c4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, james@manger.com.au, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #5: Separate scheme names for bearer tokens, request signing, and delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 22:18:37 -0000 #5: Separate scheme names for bearer tokens, request signing, and delegation Changes (by barryleiba@…): * status: new => closed * resolution: => dead -- ---------------------------------+------------------------------------------ Reporter: james@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: v2 | Version: 2.0 Severity: - | Resolution: dead Keywords: | ---------------------------------+------------------------------------------ Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Fri Apr 15 15:22:09 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C693DE06B1 for ; Fri, 15 Apr 2011 15:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.202 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZUFN3xGih4K for ; Fri, 15 Apr 2011 15:22:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 37B69E0692 for ; Fri, 15 Apr 2011 15:22:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QArOx-0002Fj-U9; Fri, 15 Apr 2011 15:22:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org, james@manger.com.au X-Trac-Project: oauth Date: Fri, 15 Apr 2011 22:22:07 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/5#comment:3 Message-ID: <068.e6255176d6148e6bf3968a985adc3248@trac.tools.ietf.org> References: <059.db44ca9c6a99be8265550c67a11484c4@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <059.db44ca9c6a99be8265550c67a11484c4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, james@manger.com.au, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #5: Separate scheme names for bearer tokens, request signing, and delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 22:22:10 -0000 #5: Separate scheme names for bearer tokens, request signing, and delegation Changes (by barryleiba@…): * component: v2 => z-dead -- ---------------------------------+------------------------------------------ Reporter: james@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: z-dead | Version: 2.0 Severity: - | Resolution: dead Keywords: | ---------------------------------+------------------------------------------ Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Sat Apr 16 08:02:37 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D4CD9E0685 for ; Sat, 16 Apr 2011 08:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.231 X-Spam-Level: X-Spam-Status: No, score=-102.231 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aEAFyniLtes for ; Sat, 16 Apr 2011 08:02:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 3148CE0670 for ; Sat, 16 Apr 2011 08:02:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QB70x-0004DI-Ny; Sat, 16 Apr 2011 08:02:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 16 Apr 2011 15:02:23 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/8#comment:2 Message-ID: <066.a7d8f950d5ef67ca08839dc1278c7383@trac.tools.ietf.org> References: <057.9a63990a1cb32cd95c16da6d299242c5@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <057.9a63990a1cb32cd95c16da6d299242c5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #8: 4.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 15:02:38 -0000 #8: 4.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code Description changed by barryleiba@…: Old description: > Pending Consensus: > The authorization server MAY set the "error" parameter value to a > numerical HTTP status code from the 4xx or 5xx range, with the exception > of the 400 (Bad Request) and 401 (Unauthorized) status codes. For > example, if the service is temporarily unavailable, the authorization > server MAY return an error response with "error" set to "503". New description: Pending Consensus: The authorization server MAY set the "error" parameter value to a numerical HTTP status code from the 4xx or 5xx range, with the exception of the 400 (Bad Request) and 401 (Unauthorized) status codes. For example, if the service is temporarily unavailable, the authorization server MAY return an error response with "error" set to "503". ---------------------------------------------------- Related to ticket 9: http://trac.tools.ietf.org/wg/oauth/trac/ticket/9 -- -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Sat Apr 16 08:03:00 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1017EE070A for ; Sat, 16 Apr 2011 08:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.255 X-Spam-Level: X-Spam-Status: No, score=-102.255 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wyjADV3xUu7 for ; Sat, 16 Apr 2011 08:02:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 6BDDFE0670 for ; Sat, 16 Apr 2011 08:02:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QB71W-0004HD-W4; Sat, 16 Apr 2011 08:02:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 16 Apr 2011 15:02:58 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/oauth/trac/ticket/9#comment:1 Message-ID: <066.d99e13d00935fa4a5c5d671193c1e6bc@trac.tools.ietf.org> References: <057.80f2953d4a1049111596933a3f8cff2e@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <057.80f2953d4a1049111596933a3f8cff2e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #9: 5.2, text for non-400 & 401 error conditions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 15:03:00 -0000 #9: 5.2, text for non-400 & 401 error conditions Description changed by barryleiba@…: Old description: > Pending Consensus: > If the authorization server encounters an error condition other than the > 400 (Bad Request) and 401 (Unauthorized) responses described above (e.g. > the service is temporarily unavailable), the authorization server SHOULD > include an error response in the entity body, and set the "error" > parameter value to the numerical HTTP status code returned. New description: Pending Consensus: If the authorization server encounters an error condition other than the 400 (Bad Request) and 401 (Unauthorized) responses described above (e.g. the service is temporarily unavailable), the authorization server SHOULD include an error response in the entity body, and set the "error" parameter value to the numerical HTTP status code returned. ---------------------------------------------------- Related to ticket 8: http://trac.tools.ietf.org/wg/oauth/trac/ticket/8 -- -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Sat Apr 16 08:03:37 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 19725E0685 for ; Sat, 16 Apr 2011 08:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+y9MeT+Qk5G for ; Sat, 16 Apr 2011 08:03:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 58D99E0670 for ; Sat, 16 Apr 2011 08:03:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QB727-0004IH-Sq; Sat, 16 Apr 2011 08:03:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 16 Apr 2011 15:03:35 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/10#comment:1 Message-ID: <066.9926c9c90098ba4e5819fe37b086c1ea@trac.tools.ietf.org> References: <057.27a13fb0813ce1eff49107833d51ba4c@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <057.27a13fb0813ce1eff49107833d51ba4c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #10: 8.4. Defining Additional Error Codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 15:03:37 -0000 #10: 8.4. Defining Additional Error Codes Description changed by barryleiba@…: Old description: > Pending Consensus: > > 8.4. Defining Additional Error Codes > > In cases where protocol extensions (i.e. access token types, extension > parameters, or extension grant types) require additional error codes to > be used with the authorization code grant error response (Section > 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the > token error response (Section 5.2), such error codes MAY be defined. > > Extension error codes MUST be registered (following the procedures in > Section 10.3) if the extension they are used in conjunction with is > registered. Additional error codes used with unregistered extensions MAY > be registered. > > Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed > by an identifying name when possible. For example, an error identifying > an invalid value set to the extension parameter "example" should be named > "example_invalid". > > error-code = ALPHA *error-char > error-char = "-" / "." / "_" / DIGIT / ALPHA New description: Pending Consensus: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the token error response (Section 5.2), such error codes MAY be defined. ------------------------------------------------- Related to ticket 11: http://trac.tools.ietf.org/wg/oauth/trac/ticket/11 Extension error codes MUST be registered (following the procedures in Section 10.3) if the extension they are used in conjunction with is registered. Additional error codes used with unregistered extensions MAY be registered. Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" should be named "example_invalid". error-code = ALPHA *error-char error-char = "-" / "." / "_" / DIGIT / ALPHA -- -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Sat Apr 16 08:03:58 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D9E67E0707 for ; Sat, 16 Apr 2011 08:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.296 X-Spam-Level: X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB2+jvSz+Z+C for ; Sat, 16 Apr 2011 08:03:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 265BEE0670 for ; Sat, 16 Apr 2011 08:03:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QB72T-0004J2-N3; Sat, 16 Apr 2011 08:03:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 16 Apr 2011 15:03:57 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/10#comment:2 Message-ID: <066.348a23fd66fdd2bf9058537b18159030@trac.tools.ietf.org> References: <057.27a13fb0813ce1eff49107833d51ba4c@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <057.27a13fb0813ce1eff49107833d51ba4c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #10: 8.4. Defining Additional Error Codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 15:03:59 -0000 #10: 8.4. Defining Additional Error Codes Description changed by barryleiba@…: Old description: > Pending Consensus: > > 8.4. Defining Additional Error Codes > > In cases where protocol extensions (i.e. access token types, extension > parameters, or extension grant types) require additional error codes to > be used with the authorization code grant error response (Section > 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the > token error response (Section 5.2), such error codes MAY be defined. > ------------------------------------------------- > Related to ticket 11: > http://trac.tools.ietf.org/wg/oauth/trac/ticket/11 > Extension error codes MUST be registered (following the procedures in > Section 10.3) if the extension they are used in conjunction with is > registered. Additional error codes used with unregistered extensions MAY > be registered. > > Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed > by an identifying name when possible. For example, an error identifying > an invalid value set to the extension parameter "example" should be named > "example_invalid". > > error-code = ALPHA *error-char > error-char = "-" / "." / "_" / DIGIT / ALPHA New description: Pending Consensus: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the token error response (Section 5.2), such error codes MAY be defined. Extension error codes MUST be registered (following the procedures in Section 10.3) if the extension they are used in conjunction with is registered. Additional error codes used with unregistered extensions MAY be registered. Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" should be named "example_invalid". error-code = ALPHA *error-char error-char = "-" / "." / "_" / DIGIT / ALPHA ------------------------------------------------- Related to ticket 11: http://trac.tools.ietf.org/wg/oauth/trac/ticket/11 -- -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Sat Apr 16 08:04:30 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 67245E0685 for ; Sat, 16 Apr 2011 08:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LddTRQMfYvyK for ; Sat, 16 Apr 2011 08:04:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 4C9BEE0670 for ; Sat, 16 Apr 2011 08:04:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QB72y-0004JS-O6; Sat, 16 Apr 2011 08:04:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Sat, 16 Apr 2011 15:04:28 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/11#comment:2 Message-ID: <066.de39b678139904b61f9a9dd06c0fc263@trac.tools.ietf.org> References: <057.87dfe70ac9df8542cc9518e11f11bb27@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <057.87dfe70ac9df8542cc9518e11f11bb27@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #11: 10.3. The OAuth Extensions Error Registry X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 15:04:30 -0000 #11: 10.3. The OAuth Extensions Error Registry Description changed by barryleiba@…: Old description: > Pending Consensus: > > 10.3. The OAuth Extensions Error Registry > > This specification establishes the OAuth extensions error registry. > > Additional error codes used together with other protocol extensions (i.e. > extension grant types, access token types, or extension parameters) are > registered on the advice of one or more Designated Experts (appointed by > the IESG or their delegate), with a Specification Required (using > terminology from [RFC5226]). However, to allow for the allocation of > values prior to publication, the Designated Expert(s) may approve > registration once they are satisfied that such a specification will be > published. > > Registration requests should be sent to the [TBD]@ietf.org mailing list > for review and comment, with an appropriate subject (e.g., "Request for > error code: example"). [[ Note to RFC-EDITOR: The name of the mailing > list should be determined in consultation with the IESG and IANA. > Suggested name: oauth-ext-review. ]] > > Within at most 14 days of the request, the Designated Expert(s) will > either approve or deny the registration request, communicating this > decision to the review list and IANA. Denials should include an > explanation and, if applicable, suggestions as to how to make the request > successful. > > Decisions (or lack thereof) made by the Designated Expert can be first > appealed to Application Area Directors (contactable using app- > ads@tools.ietf.org email address or directly by looking up their email > addresses on http://www.iesg.org/ website) and, if the appellant is not > satisfied with the response, to the full IESG (using the iesg@iesg.org > mailing list). > > IANA should only accept registry updates from the Designated Expert(s), > and should direct all requests for registration to the review mailing > list. > > ---------------------------------------------- > > Tony Nadalin: > The remaining technical issue in this regard is the need to expand the > scope of the registry to encompass errors returned from resource servers. > The error registry was introduced to address a requirement that existed > in the working group documents prior to the split. This requirement was > expressed in draft 10, Section 3.2.1 and draft 11, Section 4.3.1 as "[[ > Add mechanism for extending error codes ]]". New description: Pending Consensus: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app- ads@tools.ietf.org email address or directly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. ---------------------------------------------- Tony Nadalin: The remaining technical issue in this regard is the need to expand the scope of the registry to encompass errors returned from resource servers. The error registry was introduced to address a requirement that existed in the working group documents prior to the split. This requirement was expressed in draft 10, Section 3.2.1 and draft 11, Section 4.3.1 as "[[ Add mechanism for extending error codes ]]". ------------------------------------------------- Related to ticket 10: http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 -- -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From eran@hueniverse.com Sat Apr 16 09:58:18 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CC197E0681 for ; Sat, 16 Apr 2011 09:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ+a7rQ8VGHa for ; Sat, 16 Apr 2011 09:58:17 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 8D4C1E00BE for ; Sat, 16 Apr 2011 09:58:17 -0700 (PDT) Received: (qmail 14025 invoked from network); 16 Apr 2011 16:58:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Apr 2011 16:58:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 16 Apr 2011 09:58:12 -0700 From: Eran Hammer-Lahav To: oauth issue tracker , "barryleiba@computer.org" Date: Sat, 16 Apr 2011 09:58:02 -0700 Thread-Topic: [OAUTH-WG] [oauth] #11: 10.3. The OAuth Extensions Error Registry Thread-Index: Acv8R5rXXdFufe1JRpmyFvULTAEcsAAD0k6Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BB358@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <057.87dfe70ac9df8542cc9518e11f11bb27@trac.tools.ietf.org> <066.de39b678139904b61f9a9dd06c0fc263@trac.tools.ietf.org> In-Reply-To: <066.de39b678139904b61f9a9dd06c0fc263@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] [oauth] #11: 10.3. The OAuth Extensions Error Registry 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, 16 Apr 2011 16:58:18 -0000 VGhpcyB3YXMgbmV2ZXIgYW4gYWN0dWFsIHJlcXVpcmVtZW50LiBBbnkgdGV4dCBpbiBbWyBdXSAg aXMgc3RyaWN0bHkgYW4gZWRpdG9yaWFsIGNvbW1lbnQsIGFuZCB1c2VkIGJ5IHRoZSBlZGl0b3Ig dG8gZG9jdW1lbnQgY29tbWVudHMgdGhhdCBhcmUgbm90IHBhcnQgb2YgdGhlIHNwZWNpZmljYXRp b24uDQoNCkluIHRoaXMgY2FzZSwgd2hlbiBleHRlbnNpYmlsaXR5IHdhcyBmaXJzdCBkaXNjdXNz ZWQsIEkgYWRkZWQgdGhlc2UgY29tbWVudHMgZXZlcnl3aGVyZSB3aGVyZSBleHRlbnNpYmlsaXR5 ICptaWdodCogYmUgYXBwcm9wcmlhdGUuIFRvIGVsZXZhdGUgdGhpcyB0byBhIFdHIHJlcXVpcmVt ZW50IGlzIG1pc3JlcHJlc2VudGluZyB0aGUgZmFjdHMuIFRoZSBXRyBtdXN0IGRlY2lkZSB3aGF0 IGFyZSB0aGUgcmVxdWlyZW1lbnRzIGZvciBlcnJvciBleHRlbnNpYmlsaXR5IGFuZCB0YWlsb3Ig YSBzb2x1dGlvbiBiYXNlZCBvbiB0aGF0Lg0KDQpFSEwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIG9hdXRoIGlzc3VlIHRyYWNrZXINCj4gU2Vu dDogU2F0dXJkYXksIEFwcmlsIDE2LCAyMDExIDg6MDQgQU0NCj4gVG86IGJhcnJ5bGVpYmFAY29t cHV0ZXIub3JnDQo+IENjOiBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdH XSBbb2F1dGhdICMxMTogMTAuMy4gVGhlIE9BdXRoIEV4dGVuc2lvbnMgRXJyb3INCj4gUmVnaXN0 cnkNCj4gDQo+ICMxMTogMTAuMy4gVGhlIE9BdXRoIEV4dGVuc2lvbnMgRXJyb3IgUmVnaXN0cnkN Cj4gDQo+IERlc2NyaXB0aW9uIGNoYW5nZWQgYnkgYmFycnlsZWliYUDigKY6DQo+IA0KPiBPbGQg ZGVzY3JpcHRpb246DQo+IA0KPiA+IFBlbmRpbmcgQ29uc2Vuc3VzOg0KPiA+DQo+ID4gMTAuMy4g VGhlIE9BdXRoIEV4dGVuc2lvbnMgRXJyb3IgUmVnaXN0cnkNCj4gPg0KPiA+IFRoaXMgc3BlY2lm aWNhdGlvbiBlc3RhYmxpc2hlcyB0aGUgT0F1dGggZXh0ZW5zaW9ucyBlcnJvciByZWdpc3RyeS4N Cj4gPg0KPiA+IEFkZGl0aW9uYWwgZXJyb3IgY29kZXMgdXNlZCB0b2dldGhlciB3aXRoIG90aGVy IHByb3RvY29sIGV4dGVuc2lvbnMgKGkuZS4NCj4gPiBleHRlbnNpb24gZ3JhbnQgdHlwZXMsIGFj Y2VzcyB0b2tlbiB0eXBlcywgb3IgZXh0ZW5zaW9uIHBhcmFtZXRlcnMpDQo+ID4gYXJlIHJlZ2lz dGVyZWQgb24gdGhlIGFkdmljZSBvZiBvbmUgb3IgbW9yZSBEZXNpZ25hdGVkIEV4cGVydHMNCj4g PiAoYXBwb2ludGVkIGJ5IHRoZSBJRVNHIG9yIHRoZWlyIGRlbGVnYXRlKSwgd2l0aCBhIFNwZWNp ZmljYXRpb24NCj4gPiBSZXF1aXJlZCAodXNpbmcgdGVybWlub2xvZ3kgZnJvbSBbUkZDNTIyNl0p LiAgSG93ZXZlciwgdG8gYWxsb3cgZm9yDQo+ID4gdGhlIGFsbG9jYXRpb24gb2YgdmFsdWVzIHBy aW9yIHRvIHB1YmxpY2F0aW9uLCB0aGUgRGVzaWduYXRlZA0KPiA+IEV4cGVydChzKSBtYXkgYXBw cm92ZSByZWdpc3RyYXRpb24gb25jZSB0aGV5IGFyZSBzYXRpc2ZpZWQgdGhhdCBzdWNoIGENCj4g PiBzcGVjaWZpY2F0aW9uIHdpbGwgYmUgcHVibGlzaGVkLg0KPiA+DQo+ID4gUmVnaXN0cmF0aW9u IHJlcXVlc3RzIHNob3VsZCBiZSBzZW50IHRvIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nDQo+ ID4gbGlzdCBmb3IgcmV2aWV3IGFuZCBjb21tZW50LCB3aXRoIGFuIGFwcHJvcHJpYXRlIHN1Ympl Y3QgKGUuZy4sDQo+ID4gIlJlcXVlc3QgZm9yIGVycm9yIGNvZGU6IGV4YW1wbGUiKS4gW1sgTm90 ZSB0byBSRkMtRURJVE9SOiBUaGUgbmFtZSBvZg0KPiA+IHRoZSBtYWlsaW5nIGxpc3Qgc2hvdWxk IGJlIGRldGVybWluZWQgaW4gY29uc3VsdGF0aW9uIHdpdGggdGhlIElFU0cgYW5kDQo+IElBTkEu DQo+ID4gU3VnZ2VzdGVkIG5hbWU6IG9hdXRoLWV4dC1yZXZpZXcuIF1dDQo+ID4NCj4gPiBXaXRo aW4gYXQgbW9zdCAxNCBkYXlzIG9mIHRoZSByZXF1ZXN0LCB0aGUgRGVzaWduYXRlZCBFeHBlcnQo cykgd2lsbA0KPiA+IGVpdGhlciBhcHByb3ZlIG9yIGRlbnkgdGhlIHJlZ2lzdHJhdGlvbiByZXF1 ZXN0LCBjb21tdW5pY2F0aW5nIHRoaXMNCj4gPiBkZWNpc2lvbiB0byB0aGUgcmV2aWV3IGxpc3Qg YW5kIElBTkEuICBEZW5pYWxzIHNob3VsZCBpbmNsdWRlIGFuDQo+ID4gZXhwbGFuYXRpb24gYW5k LCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8gbWFrZSB0aGUNCj4gPiBy ZXF1ZXN0IHN1Y2Nlc3NmdWwuDQo+ID4NCj4gPiBEZWNpc2lvbnMgKG9yIGxhY2sgdGhlcmVvZikg bWFkZSBieSB0aGUgRGVzaWduYXRlZCBFeHBlcnQgY2FuIGJlIGZpcnN0DQo+ID4gYXBwZWFsZWQg dG8gQXBwbGljYXRpb24gQXJlYSBEaXJlY3RvcnMgKGNvbnRhY3RhYmxlIHVzaW5nIGFwcC0NCj4g PiBhZHNAdG9vbHMuaWV0Zi5vcmcgZW1haWwgYWRkcmVzcyBvciBkaXJlY3RseSBieSBsb29raW5n IHVwIHRoZWlyIGVtYWlsDQo+ID4gYWRkcmVzc2VzIG9uIGh0dHA6Ly93d3cuaWVzZy5vcmcvIHdl YnNpdGUpIGFuZCwgaWYgdGhlIGFwcGVsbGFudCBpcw0KPiA+IG5vdCBzYXRpc2ZpZWQgd2l0aCB0 aGUgcmVzcG9uc2UsIHRvIHRoZSBmdWxsIElFU0cgKHVzaW5nIHRoZQ0KPiA+IGllc2dAaWVzZy5v cmcgbWFpbGluZyBsaXN0KS4NCj4gPg0KPiA+IElBTkEgc2hvdWxkIG9ubHkgYWNjZXB0IHJlZ2lz dHJ5IHVwZGF0ZXMgZnJvbSB0aGUgRGVzaWduYXRlZA0KPiA+IEV4cGVydChzKSwgYW5kIHNob3Vs ZCBkaXJlY3QgYWxsIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24gdG8gdGhlDQo+ID4gcmV2aWV3 IG1haWxpbmcgbGlzdC4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+IFRvbnkgTmFkYWxpbjoNCj4gPiBUaGUgcmVtYWluaW5n IHRlY2huaWNhbCBpc3N1ZSBpbiB0aGlzIHJlZ2FyZCBpcyB0aGUgbmVlZCB0byBleHBhbmQgdGhl DQo+ID4gc2NvcGUgb2YgdGhlIHJlZ2lzdHJ5IHRvIGVuY29tcGFzcyBlcnJvcnMgcmV0dXJuZWQg ZnJvbSByZXNvdXJjZSBzZXJ2ZXJzLg0KPiA+IFRoZSBlcnJvciByZWdpc3RyeSB3YXMgaW50cm9k dWNlZCB0byBhZGRyZXNzIGEgcmVxdWlyZW1lbnQgdGhhdA0KPiA+IGV4aXN0ZWQgaW4gdGhlIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnRzIHByaW9yIHRvIHRoZSBzcGxpdC4gVGhpcw0KPiA+IHJlcXVp cmVtZW50IHdhcyBleHByZXNzZWQgaW4gZHJhZnQgMTAsIFNlY3Rpb24gMy4yLjEgYW5kIGRyYWZ0 IDExLA0KPiA+IFNlY3Rpb24gNC4zLjEgYXMgIltbIEFkZCBtZWNoYW5pc20gZm9yIGV4dGVuZGlu ZyBlcnJvciBjb2RlcyBdXSIuDQo+IA0KPiBOZXcgZGVzY3JpcHRpb246DQo+IA0KPiAgUGVuZGlu ZyBDb25zZW5zdXM6DQo+IA0KPiAgMTAuMy4gVGhlIE9BdXRoIEV4dGVuc2lvbnMgRXJyb3IgUmVn aXN0cnkNCj4gDQo+ICBUaGlzIHNwZWNpZmljYXRpb24gZXN0YWJsaXNoZXMgdGhlIE9BdXRoIGV4 dGVuc2lvbnMgZXJyb3IgcmVnaXN0cnkuDQo+IA0KPiAgQWRkaXRpb25hbCBlcnJvciBjb2RlcyB1 c2VkIHRvZ2V0aGVyIHdpdGggb3RoZXIgcHJvdG9jb2wgZXh0ZW5zaW9ucyAoaS5lLg0KPiAgZXh0 ZW5zaW9uIGdyYW50IHR5cGVzLCBhY2Nlc3MgdG9rZW4gdHlwZXMsIG9yIGV4dGVuc2lvbiBwYXJh bWV0ZXJzKSBhcmUNCj4gcmVnaXN0ZXJlZCBvbiB0aGUgYWR2aWNlIG9mIG9uZSBvciBtb3JlIERl c2lnbmF0ZWQgRXhwZXJ0cyAoYXBwb2ludGVkIGJ5DQo+IHRoZSBJRVNHIG9yIHRoZWlyIGRlbGVn YXRlKSwgd2l0aCBhIFNwZWNpZmljYXRpb24gUmVxdWlyZWQgKHVzaW5nICB0ZXJtaW5vbG9neQ0K PiBmcm9tIFtSRkM1MjI2XSkuICBIb3dldmVyLCB0byBhbGxvdyBmb3IgdGhlIGFsbG9jYXRpb24g b2YgIHZhbHVlcyBwcmlvciB0bw0KPiBwdWJsaWNhdGlvbiwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0 KHMpIG1heSBhcHByb3ZlICByZWdpc3RyYXRpb24gb25jZSB0aGV5DQo+IGFyZSBzYXRpc2ZpZWQg dGhhdCBzdWNoIGEgc3BlY2lmaWNhdGlvbiB3aWxsIGJlICBwdWJsaXNoZWQuDQo+IA0KPiAgUmVn aXN0cmF0aW9uIHJlcXVlc3RzIHNob3VsZCBiZSBzZW50IHRvIHRoZSBbVEJEXUBpZXRmLm9yZyBt YWlsaW5nIGxpc3QgIGZvcg0KPiByZXZpZXcgYW5kIGNvbW1lbnQsIHdpdGggYW4gYXBwcm9wcmlh dGUgc3ViamVjdCAoZS5nLiwgIlJlcXVlc3QgZm9yICBlcnJvcg0KPiBjb2RlOiBleGFtcGxlIiku IFtbIE5vdGUgdG8gUkZDLUVESVRPUjogVGhlIG5hbWUgb2YgdGhlIG1haWxpbmcgbGlzdCAgc2hv dWxkDQo+IGJlIGRldGVybWluZWQgaW4gY29uc3VsdGF0aW9uIHdpdGggdGhlIElFU0cgYW5kIElB TkEuICBTdWdnZXN0ZWQNCj4gIG5hbWU6IG9hdXRoLWV4dC1yZXZpZXcuIF1dDQo+IA0KPiAgV2l0 aGluIGF0IG1vc3QgMTQgZGF5cyBvZiB0aGUgcmVxdWVzdCwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0 KHMpIHdpbGwgIGVpdGhlcg0KPiBhcHByb3ZlIG9yIGRlbnkgdGhlIHJlZ2lzdHJhdGlvbiByZXF1 ZXN0LCBjb21tdW5pY2F0aW5nIHRoaXMgIGRlY2lzaW9uIHRvIHRoZQ0KPiByZXZpZXcgbGlzdCBh bmQgSUFOQS4gIERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4gIGV4cGxhbmF0aW9uIGFuZCwgaWYN Cj4gYXBwbGljYWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8gaG93IHRvIG1ha2UgdGhlIHJlcXVlc3Qg IHN1Y2Nlc3NmdWwuDQo+IA0KPiAgRGVjaXNpb25zIChvciBsYWNrIHRoZXJlb2YpIG1hZGUgYnkg dGhlIERlc2lnbmF0ZWQgRXhwZXJ0IGNhbiBiZSBmaXJzdA0KPiBhcHBlYWxlZCB0byBBcHBsaWNh dGlvbiBBcmVhIERpcmVjdG9ycyAoY29udGFjdGFibGUgdXNpbmcgYXBwLQ0KPiBhZHNAdG9vbHMu aWV0Zi5vcmcgZW1haWwgYWRkcmVzcyBvciBkaXJlY3RseSBieSBsb29raW5nIHVwIHRoZWlyIGVt YWlsDQo+IGFkZHJlc3NlcyBvbiBodHRwOi8vd3d3Lmllc2cub3JnLyB3ZWJzaXRlKSBhbmQsIGlm IHRoZSBhcHBlbGxhbnQgaXMgbm90DQo+IHNhdGlzZmllZCB3aXRoIHRoZSByZXNwb25zZSwgdG8g dGhlIGZ1bGwgSUVTRyAodXNpbmcgdGhlIGllc2dAaWVzZy5vcmcgIG1haWxpbmcNCj4gbGlzdCku DQo+IA0KPiAgSUFOQSBzaG91bGQgb25seSBhY2NlcHQgcmVnaXN0cnkgdXBkYXRlcyBmcm9tIHRo ZSBEZXNpZ25hdGVkIEV4cGVydChzKSwNCj4gYW5kIHNob3VsZCBkaXJlY3QgYWxsIHJlcXVlc3Rz IGZvciByZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBtYWlsaW5nICBsaXN0Lg0KPiANCj4gIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ICBUb255 IE5hZGFsaW46DQo+ICBUaGUgcmVtYWluaW5nIHRlY2huaWNhbCBpc3N1ZSBpbiB0aGlzIHJlZ2Fy ZCBpcyB0aGUgbmVlZCB0byBleHBhbmQgdGhlICBzY29wZQ0KPiBvZiB0aGUgcmVnaXN0cnkgdG8g ZW5jb21wYXNzIGVycm9ycyByZXR1cm5lZCBmcm9tIHJlc291cmNlIHNlcnZlcnMuDQo+ICBUaGUg ZXJyb3IgcmVnaXN0cnkgd2FzIGludHJvZHVjZWQgdG8gYWRkcmVzcyBhIHJlcXVpcmVtZW50IHRo YXQgZXhpc3RlZCBpbg0KPiB0aGUgd29ya2luZyBncm91cCBkb2N1bWVudHMgcHJpb3IgdG8gdGhl IHNwbGl0LiBUaGlzIHJlcXVpcmVtZW50IHdhcw0KPiBleHByZXNzZWQgaW4gZHJhZnQgMTAsIFNl Y3Rpb24gMy4yLjEgYW5kIGRyYWZ0IDExLCBTZWN0aW9uIDQuMy4xIGFzICJbWyAgQWRkDQo+IG1l Y2hhbmlzbSBmb3IgZXh0ZW5kaW5nIGVycm9yIGNvZGVzIF1dIi4NCj4gIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gIFJlbGF0ZWQgdG8gdGlja2V0 IDEwOg0KPiAgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvb2F1dGgvdHJhYy90aWNrZXQv MTANCj4gDQo+IC0tDQo+IA0KPiAtLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLQ0KPiAgUmVwb3J0ZXI6ICBFcmFuIEhhbW1lci1MYWhh diAgIHwgICAgICAgT3duZXI6DQo+ICAgICAgVHlwZTogIHN1Z2dlc3RlZCBjaGFuZ2UgICAgfCAg ICAgIFN0YXR1czogIG5ldw0KPiAgUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgIHwgICBN aWxlc3RvbmU6ICBEZWxpdmVyIE9BdXRoIDIuMCBzcGVjDQo+IENvbXBvbmVudDogIHYyICAgICAg ICAgICAgICAgICAgfCAgICAgVmVyc2lvbjoNCj4gIFNldmVyaXR5OiAgQWN0aXZlIFdHIERvY3Vt ZW50ICB8ICAgIEtleXdvcmRzOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLQ0KPiANCj4gVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL3dnL29hdXRoL3RyYWMvdGlja2V0LzExI2NvbW1lbnQ6Mj4NCj4gb2F1dGgg PGh0dHA6Ly90b29scy5pZXRmLm9yZy9vYXV0aC8+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1 dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0K From eran@hueniverse.com Mon Apr 18 12:26:48 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E2C97E070C for ; Mon, 18 Apr 2011 12:26:48 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgFZttFhtBfy for ; Mon, 18 Apr 2011 12:26:47 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 78E8FE080C for ; Mon, 18 Apr 2011 12:26:47 -0700 (PDT) Received: (qmail 14226 invoked from network); 18 Apr 2011 19:26:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Apr 2011 19:26:46 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 18 Apr 2011 12:26:44 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 18 Apr 2011 12:26:41 -0700 Thread-Topic: MAC request URI normalization (query parameters) Thread-Index: Acv9/hX7FLwe6UVtQ9aXG8c/gJKxGQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BB59D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723447535BB59DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] MAC request URI normalization (query parameters) 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, 18 Apr 2011 19:26:49 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447535BB59DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to drop all the request URI parameters normalization logic and= just use the raw request URI instead. A year ago during the discussion on = my Token authentication scheme (which had that behavior specified), some pe= ople raised the issue that access to the raw request URI isn't always possi= ble on the client or server. This feels like a limitation that is no longer= a real problem for any modern web development environment. If you know of actual deployment issues with using the raw request URI inst= ead of the parameter parsing and sorting voodoo, please let me know. Otherw= ise, the next draft will drop that entire section. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723447535BB59DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to = drop all the request URI parameters normalization logic and just use the ra= w request URI instead. A year ago during the discussion on my Token authent= ication scheme (which had that behavior specified), some people raised the = issue that access to the raw request URI isn’t always possible on the= client or server. This feels like a limitation that is no longer a real pr= oblem for any modern web development environment.

 

If you know of actual d= eployment issues with using the raw request URI instead of the parameter pa= rsing and sorting voodoo, please let me know. Otherwise, the next draft wil= l drop that entire section.

 <= /o:p>

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E723447535BB59DP3PW5EX1MB01E_-- From jricher@mitre.org Mon Apr 18 12:34:42 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8A695E0723 for ; Mon, 18 Apr 2011 12:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2TECdwmX+us for ; Mon, 18 Apr 2011 12:34:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfc.amsl.com (Postfix) with ESMTP id 8C904E070C for ; Mon, 18 Apr 2011 12:34:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 14EAE21B1747; Mon, 18 Apr 2011 15:34:41 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0EEB721B07AB; Mon, 18 Apr 2011 15:34:41 -0400 (EDT) Received: from [129.83.50.23] (129.83.50.23) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Mon, 18 Apr 2011 15:34:40 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB59D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447535BB59D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Mon, 18 Apr 2011 15:35:26 -0400 Message-ID: <1303155326.28040.38.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC request URI normalization (query parameters) 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, 18 Apr 2011 19:34:42 -0000 Any instance of apache's mod_rewrite will bork up the request URL for anything behind the rewrite. The server or client code behind a rewrite will only see the rewritten URL and not the original request URL. Why not just pack the signed string in with the payload? You would then have rules on verification instead of normalization. The client gets to sign the raw URL (or whatever bits, really) however it wants to, and the server can decide if the signed bits adequately cover the full query or not. -- Justin On Mon, 2011-04-18 at 15:26 -0400, Eran Hammer-Lahav wrote: > I would like to drop all the request URI parameters normalization > logic and just use the raw request URI instead. A year ago during the > discussion on my Token authentication scheme (which had that behavior > specified), some people raised the issue that access to the raw > request URI isn’t always possible on the client or server. This feels > like a limitation that is no longer a real problem for any modern web > development environment. > > > > If you know of actual deployment issues with using the raw request URI > instead of the parameter parsing and sorting voodoo, please let me > know. Otherwise, the next draft will drop that entire section. > > > > EHL > > From eran@hueniverse.com Mon Apr 18 12:40:26 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CBDD6E083A for ; Mon, 18 Apr 2011 12:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2JSSmegL32U for ; Mon, 18 Apr 2011 12:40:26 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 0CE28E0847 for ; Mon, 18 Apr 2011 12:40:25 -0700 (PDT) Received: (qmail 15629 invoked from network); 18 Apr 2011 19:40:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Apr 2011 19:40:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 18 Apr 2011 12:40:07 -0700 From: Eran Hammer-Lahav To: Justin Richer Date: Mon, 18 Apr 2011 12:40:05 -0700 Thread-Topic: [OAUTH-WG] MAC request URI normalization (query parameters) Thread-Index: Acv9/6oWIW+1zLu+TDKe7qSgB5Lz7AAAB5fA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BB5AB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447535BB59D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1303155326.28040.38.camel@ground> In-Reply-To: <1303155326.28040.38.camel@ground> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC request URI normalization (query parameters) 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, 18 Apr 2011 19:40:27 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSnVzdGluIFJpY2hlciBb bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnXQ0KPiBTZW50OiBNb25kYXksIEFwcmlsIDE4LCAyMDEx IDEyOjM1IFBNDQo+IFRvOiBFcmFuIEhhbW1lci1MYWhhdg0KPiBDYzogT0F1dGggV0cNCj4gU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gTUFDIHJlcXVlc3QgVVJJIG5vcm1hbGl6YXRpb24gKHF1ZXJ5 DQo+IHBhcmFtZXRlcnMpDQo+IA0KPiBBbnkgaW5zdGFuY2Ugb2YgYXBhY2hlJ3MgbW9kX3Jld3Jp dGUgd2lsbCBib3JrIHVwIHRoZSByZXF1ZXN0IFVSTCBmb3INCj4gYW55dGhpbmcgYmVoaW5kIHRo ZSByZXdyaXRlLiBUaGUgc2VydmVyIG9yIGNsaWVudCBjb2RlIGJlaGluZCBhIHJld3JpdGUgd2ls bA0KPiBvbmx5IHNlZSB0aGUgcmV3cml0dGVuIFVSTCBhbmQgbm90IHRoZSBvcmlnaW5hbCByZXF1 ZXN0IFVSTC4NCg0KVGhhdCdzIHRydWUgZm9yIGFueSBub3JtYWxpemF0aW9uIHNvIG5vdCBhIHZh bGlkIGlzc3VlIChmb3IgdGhpcyBwYXJ0aWN1bGFyIHF1ZXN0aW9uKS4NCg0KPiBXaHkgbm90IGp1 c3QgcGFjayB0aGUgc2lnbmVkIHN0cmluZyBpbiB3aXRoIHRoZSBwYXlsb2FkPyBZb3Ugd291bGQg dGhlbg0KPiBoYXZlIHJ1bGVzIG9uIHZlcmlmaWNhdGlvbiBpbnN0ZWFkIG9mIG5vcm1hbGl6YXRp b24uIFRoZSBjbGllbnQgZ2V0cyB0byBzaWduIHRoZQ0KPiByYXcgVVJMIChvciB3aGF0ZXZlciBi aXRzLCByZWFsbHkpIGhvd2V2ZXIgaXQgd2FudHMgdG8sIGFuZCB0aGUgc2VydmVyIGNhbg0KPiBk ZWNpZGUgaWYgdGhlIHNpZ25lZCBiaXRzIGFkZXF1YXRlbHkgY292ZXIgdGhlIGZ1bGwgcXVlcnkg b3Igbm90Lg0KDQpBbnkgZHVwbGljYXRpb24gb2YgSFRUUCByZXF1ZXN0IGJpdHMgZm9yIHRoZSBw dXJwb3NlIG9mIHNpZ25hdHVyZXMgKG9yIE1BQykgaXMgYSByZWFsbHkgYmFkIGlkZWEgKHRtKS4g VGhpcyBpcyBteSBtYWluIG9iamVjdGlvbiB0byB0aGUgSldUIGZhbWlseSBvZiBwcm9wb3NhbHMg aW4gd2hpY2ggSFRUUCByZXF1ZXN0IGNvbXBvbmVudHMgYXJlIGR1cGxpY2F0ZWQgaW4gZWFjaCBy ZXF1ZXN0LiBXaHkgdXNlIGFueSBIVFRQIGNvbXBvbmVudHMgYXQgYWxsPyBKdXN0IHVzZSBvbmUg VVJJIHdpdGggR0VUIGZvciBhbGwgeW91ciBBUEkgbmVlZHMgYW5kIGRlZmluZSBhbiBpbnRlcm5h bCBzaWduZWQgc3RydWN0dXJlIGZvciB0aGUgcmVxdWVzdC4uLiBJZiB5b3UgZG8gdGhhdCwgeW91 IGFyZSBiYXNpY2FsbHkgbW92aW5nIGF3YXkgZnJvbSBSRVNUIGFuZCBpbnRvIFNPQVAuIFRvIG1l LCB0aGlzIGlzIGEgdmVyeSBjbGVhciBsaW5lIC0gYWJzb2x1dGVseSBubyBkdXBsaWNhdGlvbiB3 aGF0LXNvLWV2ZXIuDQoNCkVITA0KDQo+ICAtLSBKdXN0aW4NCj4gDQo+IE9uIE1vbiwgMjAxMS0w NC0xOCBhdCAxNToyNiAtMDQwMCwgRXJhbiBIYW1tZXItTGFoYXYgd3JvdGU6DQo+ID4gSSB3b3Vs ZCBsaWtlIHRvIGRyb3AgYWxsIHRoZSByZXF1ZXN0IFVSSSBwYXJhbWV0ZXJzIG5vcm1hbGl6YXRp b24NCj4gPiBsb2dpYyBhbmQganVzdCB1c2UgdGhlIHJhdyByZXF1ZXN0IFVSSSBpbnN0ZWFkLiBB IHllYXIgYWdvIGR1cmluZyB0aGUNCj4gPiBkaXNjdXNzaW9uIG9uIG15IFRva2VuIGF1dGhlbnRp Y2F0aW9uIHNjaGVtZSAod2hpY2ggaGFkIHRoYXQgYmVoYXZpb3INCj4gPiBzcGVjaWZpZWQpLCBz b21lIHBlb3BsZSByYWlzZWQgdGhlIGlzc3VlIHRoYXQgYWNjZXNzIHRvIHRoZSByYXcNCj4gPiBy ZXF1ZXN0IFVSSSBpc27igJl0IGFsd2F5cyBwb3NzaWJsZSBvbiB0aGUgY2xpZW50IG9yIHNlcnZl ci4gVGhpcyBmZWVscw0KPiA+IGxpa2UgYSBsaW1pdGF0aW9uIHRoYXQgaXMgbm8gbG9uZ2VyIGEg cmVhbCBwcm9ibGVtIGZvciBhbnkgbW9kZXJuIHdlYg0KPiA+IGRldmVsb3BtZW50IGVudmlyb25t ZW50Lg0KPiA+DQo+ID4NCj4gPg0KPiA+IElmIHlvdSBrbm93IG9mIGFjdHVhbCBkZXBsb3ltZW50 IGlzc3VlcyB3aXRoIHVzaW5nIHRoZSByYXcgcmVxdWVzdCBVUkkNCj4gPiBpbnN0ZWFkIG9mIHRo ZSBwYXJhbWV0ZXIgcGFyc2luZyBhbmQgc29ydGluZyB2b29kb28sIHBsZWFzZSBsZXQgbWUNCj4g PiBrbm93LiBPdGhlcndpc2UsIHRoZSBuZXh0IGRyYWZ0IHdpbGwgZHJvcCB0aGF0IGVudGlyZSBz ZWN0aW9uLg0KPiA+DQo+ID4NCj4gPg0KPiA+IEVITA0KPiA+DQo+ID4NCj4gDQoNCg== From kris.selden@gmail.com Mon Apr 18 13:44:17 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DCDE0E08A2 for ; Mon, 18 Apr 2011 13:44:17 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFMync9qtP08 for ; Mon, 18 Apr 2011 13:44:17 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id E74EDE0701 for ; Mon, 18 Apr 2011 13:44:16 -0700 (PDT) Received: by pwi5 with SMTP id 5so3164176pwi.31 for ; Mon, 18 Apr 2011 13:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=ch/OsJFooPlvP5+ovY+WAVedjVyEly8UU9r60qVtbdI=; b=wrB4qzHAxG+bE1WIeVqdoE5yxTaBYa9Yp06MEU0dl3S4CNEIktS2J66uQJS4dScRfz wN8qzS+2csfrbL9KYR8QFSKtkNildTM7VBp4s1pYOwgCI/uk4h8xUuTVRdmOaCIzw9Bh V/HOUM1WkePvCo38PASgT7xlDTsYFTR96t6hc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=G0W5jTNQ3S13SXziRY7sbsbSRjdUE4SGm7zjSA/apeNqZf7mC6Zgx6ZZJuJf5FRCcq kkTzxtsA+FkeZjo2HVoDMTg3pN566jiOSPfjUyqC0zOu+hoktLQcRzOBEg9erHi0ajBt zX9Tp+vuSs7AsuZHyDvqg9tPnM0sb4D18Ghm8= Received: by 10.68.47.102 with SMTP id c6mr7180776pbn.265.1303159456452; Mon, 18 Apr 2011 13:44:16 -0700 (PDT) Received: from [172.16.176.22] ([74.212.130.213]) by mx.google.com with ESMTPS id g2sm2510269pbk.87.2011.04.18.13.44.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2011 13:44:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Kris Selden In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB5AB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 18 Apr 2011 13:44:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723447535BB59D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1303155326.28040.38.camel@ground> <90C41DD21FB7C64BB94121FBBC2E723447535BB5AB@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC request URI normalization (query parameters) 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, 18 Apr 2011 20:44:18 -0000 Can't the mod_rewrite in Apache set an environment variable with the = original request? [E=3DORIG_PATH:$1] Or set a header if proxying the request after rewrite (similar to = X-Forwarded-For or X-Forwarded-Proto) to preserve the original request = path? ----- Everyone's main interest, I'm guessing, in OAuth 2 and MAC is in = protecting REST APIs. It would be weird for MAC to treat HTTP as a = transport protocol like SOAP. If you keep it closer to HTTP, maybe we'll eventually have modules = created for verifying the signature of MAC signed requests just in the = web server without dealing with the backend web framework. How cool would it be just to have a nginx module to verify the signature = using the secret looked up via something like the HttpRedis or Drizzle = modules. On Apr 18, 2011, at 12:40 PM, Eran Hammer-Lahav wrote: >=20 >=20 >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mitre.org] >> Sent: Monday, April 18, 2011 12:35 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] MAC request URI normalization (query >> parameters) >>=20 >> Any instance of apache's mod_rewrite will bork up the request URL for >> anything behind the rewrite. The server or client code behind a = rewrite will >> only see the rewritten URL and not the original request URL. >=20 > That's true for any normalization so not a valid issue (for this = particular question). >=20 >> Why not just pack the signed string in with the payload? You would = then >> have rules on verification instead of normalization. The client gets = to sign the >> raw URL (or whatever bits, really) however it wants to, and the = server can >> decide if the signed bits adequately cover the full query or not. >=20 > Any duplication of HTTP request bits for the purpose of signatures (or = MAC) is a really bad idea (tm). This is my main objection to the JWT = family of proposals in which HTTP request components are duplicated in = each request. Why use any HTTP components at all? Just use one URI with = GET for all your API needs and define an internal signed structure for = the request... If you do that, you are basically moving away from REST = and into SOAP. To me, this is a very clear line - absolutely no = duplication what-so-ever. >=20 > EHL >=20 >> -- Justin >>=20 >> On Mon, 2011-04-18 at 15:26 -0400, Eran Hammer-Lahav wrote: >>> I would like to drop all the request URI parameters normalization >>> logic and just use the raw request URI instead. A year ago during = the >>> discussion on my Token authentication scheme (which had that = behavior >>> specified), some people raised the issue that access to the raw >>> request URI isn=92t always possible on the client or server. This = feels >>> like a limitation that is no longer a real problem for any modern = web >>> development environment. >>>=20 >>>=20 >>>=20 >>> If you know of actual deployment issues with using the raw request = URI >>> instead of the parameter parsing and sorting voodoo, please let me >>> know. Otherwise, the next draft will drop that entire section. >>>=20 >>>=20 >>>=20 >>> EHL >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Mon Apr 18 14:53:14 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8D441E06A4 for ; Mon, 18 Apr 2011 14:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T0+tig0Q4w2 for ; Mon, 18 Apr 2011 14:53:13 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id 70DF9E069D for ; Mon, 18 Apr 2011 14:53:10 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2622640D6A; Mon, 18 Apr 2011 15:56:39 -0600 (MDT) Message-ID: <4DACB2C3.2070302@stpeter.im> Date: Mon, 18 Apr 2011 15:53:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <057.87dfe70ac9df8542cc9518e11f11bb27@trac.tools.ietf.org> <066.de39b678139904b61f9a9dd06c0fc263@trac.tools.ietf.org> <90C41DD21FB7C64BB94121FBBC2E723447535BB358@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB358@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030705030106050502020105" Cc: "barryleiba@computer.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [oauth] #11: 10.3. The OAuth Extensions Error Registry 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, 18 Apr 2011 21:53:14 -0000 This is a cryptographically signed message in MIME format. --------------ms030705030106050502020105 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eran, that is my recollection as well. Possibly there could be consensus to add text like this if list discussion leads in that direction, but as I recall there was no such consensus when you provisionally added the text in [[...]] to the base sp= ec. Peter On 4/16/11 10:58 AM, Eran Hammer-Lahav wrote: > This was never an actual requirement. Any text in [[ ]] is strictly > an editorial comment, and used by the editor to document comments > that are not part of the specification. >=20 > In this case, when extensibility was first discussed, I added these > comments everywhere where extensibility *might* be appropriate. To > elevate this to a WG requirement is misrepresenting the facts. The WG > must decide what are the requirements for error extensibility and > tailor a solution based on that. >=20 > EHL >=20 >> -----Original Message----- From: oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org] On Behalf Of oauth issue tracker=20 >> Sent: Saturday, April 16, 2011 8:04 AM To: barryleiba@computer.org=20 >> Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #11: 10.3. The >> OAuth Extensions Error Registry >>=20 >> #11: 10.3. The OAuth Extensions Error Registry >>=20 >> Description changed by barryleiba@=E2=80=A6: >>=20 >> Old description: >>=20 >>> Pending Consensus: >>>=20 >>> 10.3. The OAuth Extensions Error Registry >>>=20 >>> This specification establishes the OAuth extensions error >>> registry. >>>=20 >>> Additional error codes used together with other protocol >>> extensions (i.e. extension grant types, access token types, or >>> extension parameters) are registered on the advice of one or more >>> Designated Experts (appointed by the IESG or their delegate), >>> with a Specification Required (using terminology from [RFC5226]). >>> However, to allow for the allocation of values prior to >>> publication, the Designated Expert(s) may approve registration >>> once they are satisfied that such a specification will be >>> published. >>>=20 >>> Registration requests should be sent to the [TBD]@ietf.org >>> mailing list for review and comment, with an appropriate subject >>> (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: >>> The name of the mailing list should be determined in consultation >>> with the IESG and >> IANA. >>> Suggested name: oauth-ext-review. ]] >>>=20 >>> Within at most 14 days of the request, the Designated Expert(s) >>> will either approve or deny the registration request, >>> communicating this decision to the review list and IANA. Denials >>> should include an explanation and, if applicable, suggestions as >>> to how to make the request successful. >>>=20 >>> Decisions (or lack thereof) made by the Designated Expert can be >>> first appealed to Application Area Directors (contactable using >>> app- ads@tools.ietf.org email address or directly by looking up >>> their email addresses on http://www.iesg.org/ website) and, if >>> the appellant is not satisfied with the response, to the full >>> IESG (using the iesg@iesg.org mailing list). >>>=20 >>> IANA should only accept registry updates from the Designated=20 >>> Expert(s), and should direct all requests for registration to >>> the review mailing list. >>>=20 >>> ---------------------------------------------- >>>=20 >>> Tony Nadalin: The remaining technical issue in this regard is the >>> need to expand the scope of the registry to encompass errors >>> returned from resource servers. The error registry was introduced >>> to address a requirement that existed in the working group >>> documents prior to the split. This requirement was expressed in >>> draft 10, Section 3.2.1 and draft 11, Section 4.3.1 as "[[ Add >>> mechanism for extending error codes ]]". >>=20 >> New description: >>=20 >> Pending Consensus: >>=20 >> 10.3. The OAuth Extensions Error Registry >>=20 >> This specification establishes the OAuth extensions error >> registry. >>=20 >> Additional error codes used together with other protocol extensions >> (i.e. extension grant types, access token types, or extension >> parameters) are registered on the advice of one or more Designated >> Experts (appointed by the IESG or their delegate), with a >> Specification Required (using terminology from [RFC5226]). >> However, to allow for the allocation of values prior to=20 >> publication, the Designated Expert(s) may approve registration >> once they are satisfied that such a specification will be >> published. >>=20 >> Registration requests should be sent to the [TBD]@ietf.org mailing >> list for review and comment, with an appropriate subject (e.g., >> "Request for error code: example"). [[ Note to RFC-EDITOR: The >> name of the mailing list should be determined in consultation with >> the IESG and IANA. Suggested name: oauth-ext-review. ]] >>=20 >> Within at most 14 days of the request, the Designated Expert(s) >> will either approve or deny the registration request, >> communicating this decision to the review list and IANA. Denials >> should include an explanation and, if applicable, suggestions as >> to how to make the request successful. >>=20 >> Decisions (or lack thereof) made by the Designated Expert can be >> first appealed to Application Area Directors (contactable using >> app- ads@tools.ietf.org email address or directly by looking up >> their email addresses on http://www.iesg.org/ website) and, if the >> appellant is not satisfied with the response, to the full IESG >> (using the iesg@iesg.org mailing list). >>=20 >> IANA should only accept registry updates from the Designated >> Expert(s), and should direct all requests for registration to the >> review mailing list. >>=20 >> ---------------------------------------------- >>=20 >> Tony Nadalin: The remaining technical issue in this regard is the >> need to expand the scope of the registry to encompass errors >> returned from resource servers. The error registry was introduced >> to address a requirement that existed in the working group >> documents prior to the split. This requirement was expressed in >> draft 10, Section 3.2.1 and draft 11, Section 4.3.1 as "[[ Add=20 >> mechanism for extending error codes ]]".=20 >> ------------------------------------------------- Related to ticket >> 10: http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 >>=20 >> -- >>=20 >> --=20 >> --------------------------------+-------------------------------------= -- >> >>=20 --------------------------------+---- >> Reporter: Eran Hammer-Lahav | Owner: Type: suggested >> change | Status: new Priority: major | >> Milestone: Deliver OAuth 2.0 spec Component: v2 >> | Version: Severity: Active WG Document | Keywords:=20 >> --------------------------------+-------------------------------------= -- >> >>=20 --------------------------------+---- >>=20 >> Ticket URL: >> =20 >> oauth >>=20 >> _______________________________________________ OAuth mailing list=20 >> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list=20 > OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --------------ms030705030106050502020105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQx ODIxNTMwN1owIwYJKoZIhvcNAQkEMRYEFCtMCpT78slMp5MOzWyCMvrdhzJ5MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBcWi9pn7tPYh2ICMRe4+uvimSyBecMHC3De7Yw9unZ38iFYwUp/ayr83hj Zo6LPs8F+LyMLJZDFkWa0ao0Gsi0S7bP55NIgqm5FcejTg9a9jO+ej33YOHOmfTrA5lSlO2O AxN63dVPzE7o5RGf2OTmYSskIOTp8XBnniNnkA9CnWoFCqNZ50jYWOvEmGLvTkJ9/mvFWD89 xSDV/zp2zIyVTJolZaSL9ykNOKzgxmfvTOKiV/lSobYt1lalkuomZ7DNTfrYHXHgl3FbQlQ4 Jh7H4TCyi0D8Ho5ypaOnf/tt3PMZBBNEWk51yRWG5rrarlrR9UiD0lUWnB56L3IzOjSVAAAA AAAA --------------ms030705030106050502020105-- From tonynad@microsoft.com Mon Apr 18 14:54:44 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EF6B4E06F7 for ; Mon, 18 Apr 2011 14:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWqha1d-h1Lm for ; Mon, 18 Apr 2011 14:54:44 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id E6476E06A4 for ; Mon, 18 Apr 2011 14:54:43 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 18 Apr 2011 14:54:43 -0700 Received: from TX2EHSOBE006.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 18 Apr 2011 14:54:42 -0700 Received: from mail198-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.8; Mon, 18 Apr 2011 21:53:52 +0000 Received: from mail198-tx2 (localhost.localdomain [127.0.0.1]) by mail198-tx2-R.bigfish.com (Postfix) with ESMTP id 56F4C13683B6 for ; Mon, 18 Apr 2011 21:53:52 +0000 (UTC) X-SpamScore: -34 X-BigFish: PS-34(zz9371O542MzzdafM1202h1082kzz1033IL8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:SN1PRD0302HT003.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail198-tx2 (localhost.localdomain [127.0.0.1]) by mail198-tx2 (MessageSwitch) id 1303163632120340_4888; Mon, 18 Apr 2011 21:53:52 +0000 (UTC) Received: from TX2EHSMHS001.bigfish.com (unknown [10.9.14.251]) by mail198-tx2.bigfish.com (Postfix) with ESMTP id 18242FD8051; Mon, 18 Apr 2011 21:53:52 +0000 (UTC) Received: from SN1PRD0302HT003.namprd03.prod.outlook.com (65.55.94.9) by TX2EHSMHS001.bigfish.com (10.9.99.101) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 18 Apr 2011 21:53:36 +0000 Received: from SN1PRD0302MB100.namprd03.prod.outlook.com ([169.254.10.162]) by SN1PRD0302HT003.namprd03.prod.outlook.com ([10.14.148.113]) with mapi id 14.01.0225.042; Mon, 18 Apr 2011 21:53:29 +0000 From: Anthony Nadalin To: "Manger, James H" , oauth Thread-Topic: Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMA== Date: Mon, 18 Apr 2011 21:53:28 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN1PRD0302HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEAM.TELSTRA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] Revised Section 3 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, 18 Apr 2011 21:54:45 -0000 >"3.3 Client Assertion Credentials". OAuth2 currently supports the concept = of a client app swapping an assertion for an access token. Do people want t= he additional functionality of using assertions for generic client authenti= cation? I assumed servers would >prefer that clients swap an assertion for = a token at one specific endpoint, then use the token for generic client aut= h in other requests -- in which case section 3.3 "Client Assertion Credenti= als" can be dropped. We have the case where signed assertions are used for authentication and ot= her cases where just client_id and secrets are used. I don't agree that cli= ent assertion credentials should be dropped or that HTTP Basic Authenticati= on can do everything that we want/need and having to go the route of sugges= ting a new HTTP Authentication scheme while nice does not help us with the = current OAUTH that we have been developing. Removing is a breaking issue. -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Thursday, April 14, 2011 8:47 PM To: oauth Subject: Re: [OAUTH-WG] Revised Section 3 I'm certainly in favour of excluding client auth from OAuth. Dropping secti= on 3 and just having a paragraph like the following would be preferable (wi= th no capitalized keywords): In many cases an authorization server will require client authentication for requests to a token endpoint. Consequently, a client app that has credentials appropriate for that server should proactively use them for such requests. The actual mechanism for client authentication, and any provisioning of the associated credentials, is outside the scope of OAuth 2. =20 I am not a fan of the client_id/client_secret parameters, but was resigned = to their inclusion given existing deployments. Given those parameters are m= entioned, OAuth2 should say: Various early deployments of the OAuth 2.0 concepts authenticated clients to the token endpoint using client_id and client_secret parameters in the request (alongside the grant_type parameter for instance). A server that accepts client_id/client_secret parameters MUST also accept the same credentials presented using the HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." request header). The last paragraph of Thomas's "3.2 Shared Secret Credentials" is crazy (ty= po?). A server supporting some strong authentication mechanism must not be = mandated to also support weaker BASIC and client_id/client_secret mechanism= s -- and certainly not with the same secret! "3.3 Client Assertion Credentials". OAuth2 currently supports the concept o= f a client app swapping an assertion for an access token. Do people want th= e additional functionality of using assertions for generic client authentic= ation? I assumed servers would prefer that clients swap an assertion for a = token at one specific endpoint, then use the token for generic client auth = in other requests -- in which case section 3.3 "Client Assertion Credential= s" can be dropped. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Apr 18 15:46:25 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A5FDEE0878 for ; Mon, 18 Apr 2011 15:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAjFDHRw+6lq for ; Mon, 18 Apr 2011 15:46:24 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id 6A288E085E for ; Mon, 18 Apr 2011 15:46:24 -0700 (PDT) Received: (qmail 2239 invoked from network); 18 Apr 2011 22:46:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Apr 2011 22:46:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 18 Apr 2011 15:46:17 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , "Manger, James H" , oauth Date: Mon, 18 Apr 2011 15:46:13 -0700 Thread-Topic: Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Revised Section 3 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, 18 Apr 2011 22:46:25 -0000 There are two separate issues here, procedural and technical. We need to ad= dress both. Procedural issue: The issue is how should this use case be addressed by this working group. T= here were always three options: 1. Not address by the WG - leaving it up to those interested to submit an i= ndividual I-D to register their extension parameters and use them as define= d. 2. Address within v2 - add a section with similar functionality to the Clie= nt Assertion Credentials section present in -11. 3. Publish a companion specification - basically #1 and #2 combined, using = the text from #2, published as a standalone working group document. The *technical* end result of all three options is exactly the same. The sa= me two parameters (or any other solution) will be defined in the same way a= nd used the same way. The issue in picking an option from the above three i= s purely *political* and is about giving the solution a higher degree of en= dorsement. The companies interested in this work have already showed intere= st in other companion specification so the argument of having to point deve= lopers to multiple documents is completely without merit. Beyond that, it i= s nothing but perceived level of endorsement. The benefit of going with #1 or #3 is that we can close this issue for v2 a= nd move on without delaying the publication of the specification. Again, al= l three options lead to the exact same end solution and same "compliant" im= plementation. I would also point out that given the extensibility model we have adopted, = the authors of the proposed text could easily register the two parameters w= ithout the need to build the same level of WG consensus. Publishing a separ= ate document is the only guaranteed method of getting the two parameters to= be officially registered (no RFC is required, just a specification publish= ed somewhere which can be anywhere). Technical issue: As documented in my reply to this thread, there are many issues with the pr= oposed text and solution which must be resolved before any route is taken. = The biggest issue is that inventing a new HTTP authentication method based = on assertions is clearly outside the scope of this working group. It is als= o far from established that the proposed solution is the right solution for= authenticating HTTP requests using an assertion. It doesn't matter if this is defined narrowly for use with the OAuth token = endpoint because what it does in practice is invent a new HTTP authenticati= on scheme, and doesn't even use the existing HTTP authentication framework. The claim that "removing is a breaking issue" is patently wrong. This claim= was made many times before and is baseless. A breaking change would cause = current implementations using these two parameters to break. This is clearl= y not the case here since the v2 specification already provides a simple me= thod for defining additional request parameters as well as client authentic= ation methods. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Anthony Nadalin > Sent: Monday, April 18, 2011 2:53 PM > To: Manger, James H; oauth > Subject: Re: [OAUTH-WG] Revised Section 3 >=20 > >"3.3 Client Assertion Credentials". OAuth2 currently supports the concep= t of > a client app swapping an assertion for an access token. Do people want th= e > additional functionality of using assertions for generic client authentic= ation? I > assumed servers would >prefer that clients swap an assertion for a token = at > one specific endpoint, then use the token for generic client auth in othe= r > requests -- in which case section 3.3 "Client Assertion Credentials" can = be > dropped. >=20 > We have the case where signed assertions are used for authentication and > other cases where just client_id and secrets are used. I don't agree that > client assertion credentials should be dropped or that HTTP Basic > Authentication can do everything that we want/need and having to go the > route of suggesting a new HTTP Authentication scheme while nice does not > help us with the current OAUTH that we have been developing. Removing is > a breaking issue. >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Thursday, April 14, 2011 8:47 PM > To: oauth > Subject: Re: [OAUTH-WG] Revised Section 3 >=20 > I'm certainly in favour of excluding client auth from OAuth. Dropping sec= tion > 3 and just having a paragraph like the following would be preferable (wit= h no > capitalized keywords): >=20 > In many cases an authorization server will require client > authentication for requests to a token endpoint. > Consequently, a client app that has credentials appropriate > for that server should proactively use them for such requests. > The actual mechanism for client authentication, and any > provisioning of the associated credentials, is outside > the scope of OAuth 2. >=20 >=20 > I am not a fan of the client_id/client_secret parameters, but was resigne= d to > their inclusion given existing deployments. Given those parameters are > mentioned, OAuth2 should say: >=20 > Various early deployments of the OAuth 2.0 concepts authenticated > clients to the token endpoint using client_id and client_secret > parameters in the request (alongside the grant_type parameter > for instance). A server that accepts client_id/client_secret > parameters MUST also accept the same credentials presented using the > HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." request > header). >=20 >=20 > The last paragraph of Thomas's "3.2 Shared Secret Credentials" is crazy > (typo?). A server supporting some strong authentication mechanism must > not be mandated to also support weaker BASIC and client_id/client_secret > mechanisms -- and certainly not with the same secret! >=20 > "3.3 Client Assertion Credentials". OAuth2 currently supports the concept= of > a client app swapping an assertion for an access token. Do people want th= e > additional functionality of using assertions for generic client authentic= ation? I > assumed servers would prefer that clients swap an assertion for a token a= t > one specific endpoint, then use the token for generic client auth in othe= r > requests -- in which case section 3.3 "Client Assertion Credentials" can = be > dropped. >=20 > -- > James Manger >=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 From tonynad@microsoft.com Mon Apr 18 15:55:18 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F64AE082A for ; Mon, 18 Apr 2011 15:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCcCWiP3iKr6 for ; Mon, 18 Apr 2011 15:55:17 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id 03DB6E0865 for ; Mon, 18 Apr 2011 15:55:16 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 18 Apr 2011 15:55:16 -0700 Received: from DB3EHSOBE004.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 18 Apr 2011 15:55:16 -0700 Received: from mail87-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.8; Mon, 18 Apr 2011 22:55:14 +0000 Received: from mail87-db3 (localhost.localdomain [127.0.0.1]) by mail87-db3-R.bigfish.com (Postfix) with ESMTP id 3AC8F2282DE for ; Mon, 18 Apr 2011 22:55:14 +0000 (UTC) X-SpamScore: -45 X-BigFish: PS-45(zz9371O542M1432N1418MzzdafM1202h1082kzz1033IL8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:SN1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail87-db3 (localhost.localdomain [127.0.0.1]) by mail87-db3 (MessageSwitch) id 1303167313816025_30253; Mon, 18 Apr 2011 22:55:13 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.250]) by mail87-db3.bigfish.com (Postfix) with ESMTP id C33611B28050; Mon, 18 Apr 2011 22:55:13 +0000 (UTC) Received: from SN1PRD0302HT002.namprd03.prod.outlook.com (65.55.94.9) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 18 Apr 2011 22:55:13 +0000 Received: from SN1PRD0302MB100.namprd03.prod.outlook.com ([169.254.10.162]) by SN1PRD0302HT002.namprd03.prod.outlook.com ([10.14.149.46]) with mapi id 14.01.0225.042; Mon, 18 Apr 2011 22:54:55 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , "Manger, James H" , oauth Thread-Topic: Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAAEw7YA= Date: Mon, 18 Apr 2011 22:54:54 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN1PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEAM.TELSTRA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] Revised Section 3 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, 18 Apr 2011 22:55:18 -0000 > The claim that "removing is a breaking issue" is patently wrong. This cla= im was made many times before and is baseless. A breaking change would caus= e current implementations using these two parameters to break. This is clea= rly not the case here since >the v2 specification already provides a simple= method for defining additional request parameters as well as client authen= tication methods. It's clearly the case that we are on v10 wanting to rev our implementation = and the removal is a breaking change for us. So it's not baseless as you co= ntinue to say. I think that the text that Thomas has resurrected is just f= ine and I would support getting that text back into the document. -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Monday, April 18, 2011 3:46 PM To: Anthony Nadalin; Manger, James H; oauth Subject: RE: Revised Section 3 There are two separate issues here, procedural and technical. We need to ad= dress both. Procedural issue: The issue is how should this use case be addressed by this working group. T= here were always three options: 1. Not address by the WG - leaving it up to those interested to submit an i= ndividual I-D to register their extension parameters and use them as define= d. 2. Address within v2 - add a section with similar functionality to the Clie= nt Assertion Credentials section present in -11. 3. Publish a companion specification - basically #1 and #2 combined, using = the text from #2, published as a standalone working group document. The *technical* end result of all three options is exactly the same. The sa= me two parameters (or any other solution) will be defined in the same way a= nd used the same way. The issue in picking an option from the above three i= s purely *political* and is about giving the solution a higher degree of en= dorsement. The companies interested in this work have already showed intere= st in other companion specification so the argument of having to point deve= lopers to multiple documents is completely without merit. Beyond that, it i= s nothing but perceived level of endorsement. The benefit of going with #1 or #3 is that we can close this issue for v2 a= nd move on without delaying the publication of the specification. Again, al= l three options lead to the exact same end solution and same "compliant" im= plementation. I would also point out that given the extensibility model we have adopted, = the authors of the proposed text could easily register the two parameters w= ithout the need to build the same level of WG consensus. Publishing a separ= ate document is the only guaranteed method of getting the two parameters to= be officially registered (no RFC is required, just a specification publish= ed somewhere which can be anywhere). Technical issue: As documented in my reply to this thread, there are many issues with the pr= oposed text and solution which must be resolved before any route is taken. = The biggest issue is that inventing a new HTTP authentication method based = on assertions is clearly outside the scope of this working group. It is als= o far from established that the proposed solution is the right solution for= authenticating HTTP requests using an assertion. It doesn't matter if this is defined narrowly for use with the OAuth token = endpoint because what it does in practice is invent a new HTTP authenticati= on scheme, and doesn't even use the existing HTTP authentication framework. The claim that "removing is a breaking issue" is patently wrong. This claim= was made many times before and is baseless. A breaking change would cause = current implementations using these two parameters to break. This is clearl= y not the case here since the v2 specification already provides a simple me= thod for defining additional request parameters as well as client authentic= ation methods. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Anthony Nadalin > Sent: Monday, April 18, 2011 2:53 PM > To: Manger, James H; oauth > Subject: Re: [OAUTH-WG] Revised Section 3 >=20 > >"3.3 Client Assertion Credentials". OAuth2 currently supports the=20 > >concept of > a client app swapping an assertion for an access token. Do people want=20 > the additional functionality of using assertions for generic client=20 > authentication? I assumed servers would >prefer that clients swap an=20 > assertion for a token at one specific endpoint, then use the token for=20 > generic client auth in other requests -- in which case section 3.3=20 > "Client Assertion Credentials" can be dropped. >=20 > We have the case where signed assertions are used for authentication=20 > and other cases where just client_id and secrets are used. I don't=20 > agree that client assertion credentials should be dropped or that HTTP=20 > Basic Authentication can do everything that we want/need and having to=20 > go the route of suggesting a new HTTP Authentication scheme while nice=20 > does not help us with the current OAUTH that we have been developing.=20 > Removing is a breaking issue. >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Manger, James H > Sent: Thursday, April 14, 2011 8:47 PM > To: oauth > Subject: Re: [OAUTH-WG] Revised Section 3 >=20 > I'm certainly in favour of excluding client auth from OAuth. Dropping=20 > section > 3 and just having a paragraph like the following would be preferable=20 > (with no capitalized keywords): >=20 > In many cases an authorization server will require client > authentication for requests to a token endpoint. > Consequently, a client app that has credentials appropriate > for that server should proactively use them for such requests. > The actual mechanism for client authentication, and any > provisioning of the associated credentials, is outside > the scope of OAuth 2. >=20 >=20 > I am not a fan of the client_id/client_secret parameters, but was=20 > resigned to their inclusion given existing deployments. Given those=20 > parameters are mentioned, OAuth2 should say: >=20 > Various early deployments of the OAuth 2.0 concepts authenticated > clients to the token endpoint using client_id and client_secret > parameters in the request (alongside the grant_type parameter > for instance). A server that accepts client_id/client_secret > parameters MUST also accept the same credentials presented using the > HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." request > header). >=20 >=20 > The last paragraph of Thomas's "3.2 Shared Secret Credentials" is=20 > crazy (typo?). A server supporting some strong authentication=20 > mechanism must not be mandated to also support weaker BASIC and=20 > client_id/client_secret mechanisms -- and certainly not with the same sec= ret! >=20 > "3.3 Client Assertion Credentials". OAuth2 currently supports the=20 > concept of a client app swapping an assertion for an access token. Do=20 > people want the additional functionality of using assertions for=20 > generic client authentication? I assumed servers would prefer that=20 > clients swap an assertion for a token at one specific endpoint, then=20 > use the token for generic client auth in other requests -- in which=20 > case section 3.3 "Client Assertion Credentials" can be dropped. >=20 > -- > James Manger >=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 From eran@hueniverse.com Mon Apr 18 16:10:10 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9E206E08A9 for ; Mon, 18 Apr 2011 16:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZbFXeyEtPRe for ; Mon, 18 Apr 2011 16:10:09 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 2732BE08A2 for ; Mon, 18 Apr 2011 16:10:09 -0700 (PDT) Received: (qmail 11574 invoked from network); 18 Apr 2011 23:10:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Apr 2011 23:10:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 18 Apr 2011 16:10:06 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , "Manger, James H" , oauth Date: Mon, 18 Apr 2011 16:10:03 -0700 Thread-Topic: Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAAEw7YAAAG590A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BB679@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Revised Section 3 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, 18 Apr 2011 23:10:10 -0000 I don't think you understand what 'breaking' means. Breaking would be if we= assigned a different meaning or syntax to the two parameters, or changed t= heir name. Breaking requires code changes. There is nothing to prevent you = from defining these parameters just like the SAML grant type did. Was the relocation of the SAML assertion grant type to another document a "= breaking" change? Clearly not according to the SAML grant type authors. The= SAML specification is using the exact same extensibility framework this pr= oposal can use. So technical issues aside, this is purely political to give= this mechanism a stronger endorsement. My objections, on the other hand, are purely technical. As for consensus, (not wearing my editor hat) I am opposed to including tha= t text. I have taken the time and effort to give my feedback in detail (mor= e than once). So far no one has offered any rebuttals. I will hold off with= any additional comments on this issue until the chairs decide how they wan= t to proceed with this issue. EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Monday, April 18, 2011 3:55 PM > To: Eran Hammer-Lahav; Manger, James H; oauth > Subject: RE: Revised Section 3 >=20 > > The claim that "removing is a breaking issue" is patently wrong. This c= laim > was made many times before and is baseless. A breaking change would > cause current implementations using these two parameters to break. This i= s > clearly not the case here since >the v2 specification already provides a = simple > method for defining additional request parameters as well as client > authentication methods. >=20 > It's clearly the case that we are on v10 wanting to rev our implementatio= n > and the removal is a breaking change for us. So it's not baseless as you > continue to say. I think that the text that Thomas has resurrected is ju= st fine > and I would support getting that text back into the document. >=20 >=20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Monday, April 18, 2011 3:46 PM > To: Anthony Nadalin; Manger, James H; oauth > Subject: RE: Revised Section 3 >=20 > There are two separate issues here, procedural and technical. We need to > address both. >=20 > Procedural issue: >=20 > The issue is how should this use case be addressed by this working group. > There were always three options: >=20 > 1. Not address by the WG - leaving it up to those interested to submit an > individual I-D to register their extension parameters and use them as > defined. > 2. Address within v2 - add a section with similar functionality to the Cl= ient > Assertion Credentials section present in -11. > 3. Publish a companion specification - basically #1 and #2 combined, usin= g the > text from #2, published as a standalone working group document. >=20 > The *technical* end result of all three options is exactly the same. The = same > two parameters (or any other solution) will be defined in the same way an= d > used the same way. The issue in picking an option from the above three is > purely *political* and is about giving the solution a higher degree of > endorsement. The companies interested in this work have already showed > interest in other companion specification so the argument of having to po= int > developers to multiple documents is completely without merit. Beyond that= , > it is nothing but perceived level of endorsement. >=20 > The benefit of going with #1 or #3 is that we can close this issue for v2= and > move on without delaying the publication of the specification. Again, all= three > options lead to the exact same end solution and same "compliant" > implementation. >=20 > I would also point out that given the extensibility model we have adopted= , > the authors of the proposed text could easily register the two parameters > without the need to build the same level of WG consensus. Publishing a > separate document is the only guaranteed method of getting the two > parameters to be officially registered (no RFC is required, just a specif= ication > published somewhere which can be anywhere). >=20 > Technical issue: >=20 > As documented in my reply to this thread, there are many issues with the > proposed text and solution which must be resolved before any route is > taken. The biggest issue is that inventing a new HTTP authentication meth= od > based on assertions is clearly outside the scope of this working group. I= t is > also far from established that the proposed solution is the right solutio= n for > authenticating HTTP requests using an assertion. >=20 > It doesn't matter if this is defined narrowly for use with the OAuth toke= n > endpoint because what it does in practice is invent a new HTTP > authentication scheme, and doesn't even use the existing HTTP > authentication framework. >=20 > The claim that "removing is a breaking issue" is patently wrong. This cla= im was > made many times before and is baseless. A breaking change would cause > current implementations using these two parameters to break. This is clea= rly > not the case here since the v2 specification already provides a simple me= thod > for defining additional request parameters as well as client authenticati= on > methods. >=20 > EHL >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Anthony Nadalin > > Sent: Monday, April 18, 2011 2:53 PM > > To: Manger, James H; oauth > > Subject: Re: [OAUTH-WG] Revised Section 3 > > > > >"3.3 Client Assertion Credentials". OAuth2 currently supports the > > >concept of > > a client app swapping an assertion for an access token. Do people want > > the additional functionality of using assertions for generic client > > authentication? I assumed servers would >prefer that clients swap an > > assertion for a token at one specific endpoint, then use the token for > > generic client auth in other requests -- in which case section 3.3 > > "Client Assertion Credentials" can be dropped. > > > > We have the case where signed assertions are used for authentication > > and other cases where just client_id and secrets are used. I don't > > agree that client assertion credentials should be dropped or that HTTP > > Basic Authentication can do everything that we want/need and having to > > go the route of suggesting a new HTTP Authentication scheme while nice > > does not help us with the current OAUTH that we have been developing. > > Removing is a breaking issue. > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Manger, James H > > Sent: Thursday, April 14, 2011 8:47 PM > > To: oauth > > Subject: Re: [OAUTH-WG] Revised Section 3 > > > > I'm certainly in favour of excluding client auth from OAuth. Dropping > > section > > 3 and just having a paragraph like the following would be preferable > > (with no capitalized keywords): > > > > In many cases an authorization server will require client > > authentication for requests to a token endpoint. > > Consequently, a client app that has credentials appropriate > > for that server should proactively use them for such requests. > > The actual mechanism for client authentication, and any > > provisioning of the associated credentials, is outside > > the scope of OAuth 2. > > > > > > I am not a fan of the client_id/client_secret parameters, but was > > resigned to their inclusion given existing deployments. Given those > > parameters are mentioned, OAuth2 should say: > > > > Various early deployments of the OAuth 2.0 concepts authenticated > > clients to the token endpoint using client_id and client_secret > > parameters in the request (alongside the grant_type parameter > > for instance). A server that accepts client_id/client_secret > > parameters MUST also accept the same credentials presented using the > > HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." reques= t > > header). > > > > > > The last paragraph of Thomas's "3.2 Shared Secret Credentials" is > > crazy (typo?). A server supporting some strong authentication > > mechanism must not be mandated to also support weaker BASIC and > > client_id/client_secret mechanisms -- and certainly not with the same > secret! > > > > "3.3 Client Assertion Credentials". OAuth2 currently supports the > > concept of a client app swapping an assertion for an access token. Do > > people want the additional functionality of using assertions for > > generic client authentication? I assumed servers would prefer that > > clients swap an assertion for a token at one specific endpoint, then > > use the token for generic client auth in other requests -- in which > > case section 3.3 "Client Assertion Credentials" can be dropped. > > > > -- > > James Manger > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 From tonynad@microsoft.com Mon Apr 18 16:22:09 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 33D11E06FE for ; Mon, 18 Apr 2011 16:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mszCikVf5h3B for ; Mon, 18 Apr 2011 16:22:07 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id 8A91AE067C for ; Mon, 18 Apr 2011 16:22:07 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 18 Apr 2011 16:22:07 -0700 Received: from DB3EHSOBE003.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 18 Apr 2011 16:22:06 -0700 Received: from mail16-db3-R.bigfish.com (10.3.81.254) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.8; Mon, 18 Apr 2011 23:22:05 +0000 Received: from mail16-db3 (localhost.localdomain [127.0.0.1]) by mail16-db3-R.bigfish.com (Postfix) with ESMTP id B1579149011B for ; Mon, 18 Apr 2011 23:22:04 +0000 (UTC) X-SpamScore: -45 X-BigFish: PS-45(zz9371O542M1432N1418MzzdafM1202h1082kzz1033IL8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:SN1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail16-db3 (localhost.localdomain [127.0.0.1]) by mail16-db3 (MessageSwitch) id 130316892459893_23352; Mon, 18 Apr 2011 23:22:04 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.254]) by mail16-db3.bigfish.com (Postfix) with ESMTP id 018B3175804F; Mon, 18 Apr 2011 23:22:04 +0000 (UTC) Received: from SN1PRD0302HT002.namprd03.prod.outlook.com (65.55.94.9) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 18 Apr 2011 23:22:03 +0000 Received: from SN1PRD0302MB100.namprd03.prod.outlook.com ([169.254.10.162]) by SN1PRD0302HT002.namprd03.prod.outlook.com ([10.14.149.46]) with mapi id 14.01.0225.042; Mon, 18 Apr 2011 23:22:01 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , "Manger, James H" , oauth Thread-Topic: Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAAEw7YAAAG590AAAYrUQ Date: Mon, 18 Apr 2011 23:22:00 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB679@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB679@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN1PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEAM.TELSTRA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] Revised Section 3 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, 18 Apr 2011 23:22:09 -0000 I'm certainly glad you gave us your definition of "breaking" but sadly your= definition is not in line with ours. When a developer sits down and codes = to the spec and then goes to rev the code with the latest spec and things a= re removed the developer now either has to drop that feature or find an add= itional specification that has the same feature. Can this be done in a sepa= rate specification; sure it can just like we have been creating separate sp= ecifications to make the base useable. -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Monday, April 18, 2011 4:10 PM To: Anthony Nadalin; Manger, James H; oauth Subject: RE: Revised Section 3 I don't think you understand what 'breaking' means. Breaking would be if we= assigned a different meaning or syntax to the two parameters, or changed t= heir name. Breaking requires code changes. There is nothing to prevent you = from defining these parameters just like the SAML grant type did. Was the relocation of the SAML assertion grant type to another document a "= breaking" change? Clearly not according to the SAML grant type authors. The= SAML specification is using the exact same extensibility framework this pr= oposal can use. So technical issues aside, this is purely political to give= this mechanism a stronger endorsement. My objections, on the other hand, are purely technical. As for consensus, (not wearing my editor hat) I am opposed to including tha= t text. I have taken the time and effort to give my feedback in detail (mor= e than once). So far no one has offered any rebuttals. I will hold off with= any additional comments on this issue until the chairs decide how they wan= t to proceed with this issue. EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Monday, April 18, 2011 3:55 PM > To: Eran Hammer-Lahav; Manger, James H; oauth > Subject: RE: Revised Section 3 >=20 > > The claim that "removing is a breaking issue" is patently wrong.=20 > > This claim > was made many times before and is baseless. A breaking change would=20 > cause current implementations using these two parameters to break.=20 > This is clearly not the case here since >the v2 specification already=20 > provides a simple method for defining additional request parameters as=20 > well as client authentication methods. >=20 > It's clearly the case that we are on v10 wanting to rev our=20 > implementation and the removal is a breaking change for us. So it's=20 > not baseless as you continue to say. I think that the text that=20 > Thomas has resurrected is just fine and I would support getting that text= back into the document. >=20 >=20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Monday, April 18, 2011 3:46 PM > To: Anthony Nadalin; Manger, James H; oauth > Subject: RE: Revised Section 3 >=20 > There are two separate issues here, procedural and technical. We need=20 > to address both. >=20 > Procedural issue: >=20 > The issue is how should this use case be addressed by this working group. > There were always three options: >=20 > 1. Not address by the WG - leaving it up to those interested to submit=20 > an individual I-D to register their extension parameters and use them=20 > as defined. > 2. Address within v2 - add a section with similar functionality to the=20 > Client Assertion Credentials section present in -11. > 3. Publish a companion specification - basically #1 and #2 combined,=20 > using the text from #2, published as a standalone working group document. >=20 > The *technical* end result of all three options is exactly the same.=20 > The same two parameters (or any other solution) will be defined in the=20 > same way and used the same way. The issue in picking an option from=20 > the above three is purely *political* and is about giving the solution=20 > a higher degree of endorsement. The companies interested in this work=20 > have already showed interest in other companion specification so the=20 > argument of having to point developers to multiple documents is=20 > completely without merit. Beyond that, it is nothing but perceived level = of endorsement. >=20 > The benefit of going with #1 or #3 is that we can close this issue for=20 > v2 and move on without delaying the publication of the specification.=20 > Again, all three options lead to the exact same end solution and same "co= mpliant" > implementation. >=20 > I would also point out that given the extensibility model we have=20 > adopted, the authors of the proposed text could easily register the=20 > two parameters without the need to build the same level of WG=20 > consensus. Publishing a separate document is the only guaranteed=20 > method of getting the two parameters to be officially registered (no=20 > RFC is required, just a specification published somewhere which can be an= ywhere). >=20 > Technical issue: >=20 > As documented in my reply to this thread, there are many issues with=20 > the proposed text and solution which must be resolved before any route=20 > is taken. The biggest issue is that inventing a new HTTP=20 > authentication method based on assertions is clearly outside the scope=20 > of this working group. It is also far from established that the=20 > proposed solution is the right solution for authenticating HTTP requests = using an assertion. >=20 > It doesn't matter if this is defined narrowly for use with the OAuth=20 > token endpoint because what it does in practice is invent a new HTTP=20 > authentication scheme, and doesn't even use the existing HTTP=20 > authentication framework. >=20 > The claim that "removing is a breaking issue" is patently wrong. This=20 > claim was made many times before and is baseless. A breaking change=20 > would cause current implementations using these two parameters to=20 > break. This is clearly not the case here since the v2 specification=20 > already provides a simple method for defining additional request=20 > parameters as well as client authentication methods. >=20 > EHL >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > > Behalf Of Anthony Nadalin > > Sent: Monday, April 18, 2011 2:53 PM > > To: Manger, James H; oauth > > Subject: Re: [OAUTH-WG] Revised Section 3 > > > > >"3.3 Client Assertion Credentials". OAuth2 currently supports the=20 > > >concept of > > a client app swapping an assertion for an access token. Do people=20 > > want the additional functionality of using assertions for generic=20 > > client authentication? I assumed servers would >prefer that clients=20 > > swap an assertion for a token at one specific endpoint, then use the=20 > > token for generic client auth in other requests -- in which case=20 > > section 3.3 "Client Assertion Credentials" can be dropped. > > > > We have the case where signed assertions are used for authentication=20 > > and other cases where just client_id and secrets are used. I don't=20 > > agree that client assertion credentials should be dropped or that=20 > > HTTP Basic Authentication can do everything that we want/need and=20 > > having to go the route of suggesting a new HTTP Authentication=20 > > scheme while nice does not help us with the current OAUTH that we have = been developing. > > Removing is a breaking issue. > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > > Behalf Of Manger, James H > > Sent: Thursday, April 14, 2011 8:47 PM > > To: oauth > > Subject: Re: [OAUTH-WG] Revised Section 3 > > > > I'm certainly in favour of excluding client auth from OAuth.=20 > > Dropping section > > 3 and just having a paragraph like the following would be preferable=20 > > (with no capitalized keywords): > > > > In many cases an authorization server will require client > > authentication for requests to a token endpoint. > > Consequently, a client app that has credentials appropriate > > for that server should proactively use them for such requests. > > The actual mechanism for client authentication, and any > > provisioning of the associated credentials, is outside > > the scope of OAuth 2. > > > > > > I am not a fan of the client_id/client_secret parameters, but was=20 > > resigned to their inclusion given existing deployments. Given those=20 > > parameters are mentioned, OAuth2 should say: > > > > Various early deployments of the OAuth 2.0 concepts authenticated > > clients to the token endpoint using client_id and client_secret > > parameters in the request (alongside the grant_type parameter > > for instance). A server that accepts client_id/client_secret > > parameters MUST also accept the same credentials presented using the > > HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." reques= t > > header). > > > > > > The last paragraph of Thomas's "3.2 Shared Secret Credentials" is=20 > > crazy (typo?). A server supporting some strong authentication=20 > > mechanism must not be mandated to also support weaker BASIC and=20 > > client_id/client_secret mechanisms -- and certainly not with the=20 > > same > secret! > > > > "3.3 Client Assertion Credentials". OAuth2 currently supports the=20 > > concept of a client app swapping an assertion for an access token.=20 > > Do people want the additional functionality of using assertions for=20 > > generic client authentication? I assumed servers would prefer that=20 > > clients swap an assertion for a token at one specific endpoint, then=20 > > use the token for generic client auth in other requests -- in which=20 > > case section 3.3 "Client Assertion Credentials" can be dropped. > > > > -- > > James Manger > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 From eran@hueniverse.com Mon Apr 18 16:24:12 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0B088E0865 for ; Mon, 18 Apr 2011 16:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eS+XI8FnxFG for ; Mon, 18 Apr 2011 16:24:10 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 25CBCE067C for ; Mon, 18 Apr 2011 16:24:10 -0700 (PDT) Received: (qmail 741 invoked from network); 18 Apr 2011 23:24:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Apr 2011 23:24:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 18 Apr 2011 16:24:05 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , "Manger, James H" , oauth Date: Mon, 18 Apr 2011 16:24:02 -0700 Thread-Topic: Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAAEw7YAAAG590AAAYrUQAABw7ZA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BB67E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB679@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Revised Section 3 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, 18 Apr 2011 23:24:12 -0000 At least I finally got you to agree that this can be done in a separate spe= cification. That's progress. EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Monday, April 18, 2011 4:22 PM > To: Eran Hammer-Lahav; Manger, James H; oauth > Subject: RE: Revised Section 3 >=20 > I'm certainly glad you gave us your definition of "breaking" but sadly yo= ur > definition is not in line with ours. When a developer sits down and codes= to > the spec and then goes to rev the code with the latest spec and things ar= e > removed the developer now either has to drop that feature or find an > additional specification that has the same feature. Can this be done in a > separate specification; sure it can just like we have been creating separ= ate > specifications to make the base useable. >=20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Monday, April 18, 2011 4:10 PM > To: Anthony Nadalin; Manger, James H; oauth > Subject: RE: Revised Section 3 >=20 > I don't think you understand what 'breaking' means. Breaking would be if = we > assigned a different meaning or syntax to the two parameters, or changed > their name. Breaking requires code changes. There is nothing to prevent y= ou > from defining these parameters just like the SAML grant type did. >=20 > Was the relocation of the SAML assertion grant type to another document a > "breaking" change? Clearly not according to the SAML grant type authors. > The SAML specification is using the exact same extensibility framework th= is > proposal can use. So technical issues aside, this is purely political to = give this > mechanism a stronger endorsement. >=20 > My objections, on the other hand, are purely technical. >=20 > As for consensus, (not wearing my editor hat) I am opposed to including t= hat > text. I have taken the time and effort to give my feedback in detail (mor= e > than once). So far no one has offered any rebuttals. I will hold off with= any > additional comments on this issue until the chairs decide how they want t= o > proceed with this issue. >=20 > EHL >=20 > > -----Original Message----- > > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > > Sent: Monday, April 18, 2011 3:55 PM > > To: Eran Hammer-Lahav; Manger, James H; oauth > > Subject: RE: Revised Section 3 > > > > > The claim that "removing is a breaking issue" is patently wrong. > > > This claim > > was made many times before and is baseless. A breaking change would > > cause current implementations using these two parameters to break. > > This is clearly not the case here since >the v2 specification already > > provides a simple method for defining additional request parameters as > > well as client authentication methods. > > > > It's clearly the case that we are on v10 wanting to rev our > > implementation and the removal is a breaking change for us. So it's > > not baseless as you continue to say. I think that the text that > > Thomas has resurrected is just fine and I would support getting that te= xt > back into the document. > > > > > > -----Original Message----- > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > > Sent: Monday, April 18, 2011 3:46 PM > > To: Anthony Nadalin; Manger, James H; oauth > > Subject: RE: Revised Section 3 > > > > There are two separate issues here, procedural and technical. We need > > to address both. > > > > Procedural issue: > > > > The issue is how should this use case be addressed by this working grou= p. > > There were always three options: > > > > 1. Not address by the WG - leaving it up to those interested to submit > > an individual I-D to register their extension parameters and use them > > as defined. > > 2. Address within v2 - add a section with similar functionality to the > > Client Assertion Credentials section present in -11. > > 3. Publish a companion specification - basically #1 and #2 combined, > > using the text from #2, published as a standalone working group > document. > > > > The *technical* end result of all three options is exactly the same. > > The same two parameters (or any other solution) will be defined in the > > same way and used the same way. The issue in picking an option from > > the above three is purely *political* and is about giving the solution > > a higher degree of endorsement. The companies interested in this work > > have already showed interest in other companion specification so the > > argument of having to point developers to multiple documents is > > completely without merit. Beyond that, it is nothing but perceived leve= l of > endorsement. > > > > The benefit of going with #1 or #3 is that we can close this issue for > > v2 and move on without delaying the publication of the specification. > > Again, all three options lead to the exact same end solution and same > "compliant" > > implementation. > > > > I would also point out that given the extensibility model we have > > adopted, the authors of the proposed text could easily register the > > two parameters without the need to build the same level of WG > > consensus. Publishing a separate document is the only guaranteed > > method of getting the two parameters to be officially registered (no > > RFC is required, just a specification published somewhere which can be > anywhere). > > > > Technical issue: > > > > As documented in my reply to this thread, there are many issues with > > the proposed text and solution which must be resolved before any route > > is taken. The biggest issue is that inventing a new HTTP > > authentication method based on assertions is clearly outside the scope > > of this working group. It is also far from established that the > > proposed solution is the right solution for authenticating HTTP request= s > using an assertion. > > > > It doesn't matter if this is defined narrowly for use with the OAuth > > token endpoint because what it does in practice is invent a new HTTP > > authentication scheme, and doesn't even use the existing HTTP > > authentication framework. > > > > The claim that "removing is a breaking issue" is patently wrong. This > > claim was made many times before and is baseless. A breaking change > > would cause current implementations using these two parameters to > > break. This is clearly not the case here since the v2 specification > > already provides a simple method for defining additional request > > parameters as well as client authentication methods. > > > > EHL > > > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > Behalf Of Anthony Nadalin > > > Sent: Monday, April 18, 2011 2:53 PM > > > To: Manger, James H; oauth > > > Subject: Re: [OAUTH-WG] Revised Section 3 > > > > > > >"3.3 Client Assertion Credentials". OAuth2 currently supports the > > > >concept of > > > a client app swapping an assertion for an access token. Do people > > > want the additional functionality of using assertions for generic > > > client authentication? I assumed servers would >prefer that clients > > > swap an assertion for a token at one specific endpoint, then use the > > > token for generic client auth in other requests -- in which case > > > section 3.3 "Client Assertion Credentials" can be dropped. > > > > > > We have the case where signed assertions are used for authentication > > > and other cases where just client_id and secrets are used. I don't > > > agree that client assertion credentials should be dropped or that > > > HTTP Basic Authentication can do everything that we want/need and > > > having to go the route of suggesting a new HTTP Authentication > > > scheme while nice does not help us with the current OAUTH that we > have been developing. > > > Removing is a breaking issue. > > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > Behalf Of Manger, James H > > > Sent: Thursday, April 14, 2011 8:47 PM > > > To: oauth > > > Subject: Re: [OAUTH-WG] Revised Section 3 > > > > > > I'm certainly in favour of excluding client auth from OAuth. > > > Dropping section > > > 3 and just having a paragraph like the following would be preferable > > > (with no capitalized keywords): > > > > > > In many cases an authorization server will require client > > > authentication for requests to a token endpoint. > > > Consequently, a client app that has credentials appropriate > > > for that server should proactively use them for such requests. > > > The actual mechanism for client authentication, and any > > > provisioning of the associated credentials, is outside > > > the scope of OAuth 2. > > > > > > > > > I am not a fan of the client_id/client_secret parameters, but was > > > resigned to their inclusion given existing deployments. Given those > > > parameters are mentioned, OAuth2 should say: > > > > > > Various early deployments of the OAuth 2.0 concepts authenticated > > > clients to the token endpoint using client_id and client_secret > > > parameters in the request (alongside the grant_type parameter > > > for instance). A server that accepts client_id/client_secret > > > parameters MUST also accept the same credentials presented using th= e > > > HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." requ= est > > > header). > > > > > > > > > The last paragraph of Thomas's "3.2 Shared Secret Credentials" is > > > crazy (typo?). A server supporting some strong authentication > > > mechanism must not be mandated to also support weaker BASIC and > > > client_id/client_secret mechanisms -- and certainly not with the > > > same > > secret! > > > > > > "3.3 Client Assertion Credentials". OAuth2 currently supports the > > > concept of a client app swapping an assertion for an access token. > > > Do people want the additional functionality of using assertions for > > > generic client authentication? I assumed servers would prefer that > > > clients swap an assertion for a token at one specific endpoint, then > > > use the token for generic client auth in other requests -- in which > > > case section 3.3 "Client Assertion Credentials" can be dropped. > > > > > > -- > > > James Manger > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > >=20 >=20 >=20 >=20 From tim.freeman@hp.com Mon Apr 18 16:28:04 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 41EFAE069A for ; Mon, 18 Apr 2011 16:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCp3f3pPoy2A for ; Mon, 18 Apr 2011 16:28:03 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfc.amsl.com (Postfix) with ESMTP id AC803E067C for ; Mon, 18 Apr 2011 16:28:03 -0700 (PDT) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 5568F3885D for ; Mon, 18 Apr 2011 23:28:03 +0000 (UTC) Received: from G4W1852.americas.hpqcorp.net (16.234.97.230) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Apr 2011 23:25:58 +0000 Received: from GVW0432EXB.americas.hpqcorp.net ([16.234.32.145]) by G4W1852.americas.hpqcorp.net ([16.234.97.230]) with mapi; Mon, 18 Apr 2011 23:25:58 +0000 From: "Freeman, Tim" To: "oauth@ietf.org" Date: Mon, 18 Apr 2011 23:25:55 +0000 Thread-Topic: Can you use POST to access protected resources? Thread-Index: Acv+H/cTCo39lC3CRdm2we908pF/kw== Message-ID: <59DD1BA8FD3C0F4C90771C18F2B5B53A654494B720@GVW0432EXB.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AJBm AeVG A9He A9u0 BD/M D5q4 EUza FjkU FxTi GJfm GhSF HHd+ HgSW HvnW H9ZO IPEl; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {6F3004CA-7F38-43F5-BD2A-9956EB18DDEB}; dABpAG0ALgBmAHIAZQBlAG0AYQBuAEAAaABwAC4AYwBvAG0A; Mon, 18 Apr 2011 23:25:55 GMT; QwBhAG4AIAB5AG8AdQAgAHUAcwBlACAAUABPAFMAVAAgAHQAbwAgAGEAYwBjAGUAcwBzACAAcAByAG8AdABlAGMAdABlAGQAIAByAGUAcwBvAHUAcgBjAGUAcwA/AA== x-cr-puzzleid: {6F3004CA-7F38-43F5-BD2A-9956EB18DDEB} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Can you use POST to access protected resources? 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, 18 Apr 2011 23:28:04 -0000 Section 7 of http://tools.ietf.org/html/draft-ietf-oauth-v2-15 gives exampl= es of how to access protected resources. All of the examples use GET. Our protected resources are identified by a query, which might be a few kil= obytes. I'm concerned that this may not fit inside the length limitation o= n GET's for some web servers. Our present implementation does a POST inste= ad. =20 Definition-by-example is easy to understand, but it is not good at unambigu= ously specifying the boundary of permitted behavior. Was the spec meant to= allow using HTTP operations other than GET to access protected resources?= =20 From tonynad@microsoft.com Mon Apr 18 16:29:51 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 75B8DE0719 for ; Mon, 18 Apr 2011 16:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+A7FycPaO9w for ; Mon, 18 Apr 2011 16:29:50 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id A32DBE0714 for ; Mon, 18 Apr 2011 16:29:49 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 18 Apr 2011 16:29:49 -0700 Received: from AM1EHSOBE006.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 18 Apr 2011 16:29:49 -0700 Received: from mail106-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.8; Mon, 18 Apr 2011 23:29:45 +0000 Received: from mail106-am1 (localhost.localdomain [127.0.0.1]) by mail106-am1-R.bigfish.com (Postfix) with ESMTP id E72008B814E for ; Mon, 18 Apr 2011 23:29:44 +0000 (UTC) X-SpamScore: -45 X-BigFish: PS-45(zz9371O542M1432N1418MzzdafM1202h1082kzz1033IL8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:SN1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail106-am1 (localhost.localdomain [127.0.0.1]) by mail106-am1 (MessageSwitch) id 1303169374414266_1334; Mon, 18 Apr 2011 23:29:34 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.252]) by mail106-am1.bigfish.com (Postfix) with ESMTP id A31CB16E8027; Mon, 18 Apr 2011 23:28:56 +0000 (UTC) Received: from SN1PRD0302HT002.namprd03.prod.outlook.com (65.55.94.9) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 18 Apr 2011 23:28:56 +0000 Received: from SN1PRD0302MB100.namprd03.prod.outlook.com ([169.254.10.162]) by SN1PRD0302HT002.namprd03.prod.outlook.com ([10.14.149.46]) with mapi id 14.01.0225.042; Mon, 18 Apr 2011 23:28:54 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , "Manger, James H" , oauth Thread-Topic: Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAAEw7YAAAG590AAAYrUQAABw7ZAAAApFwA== Date: Mon, 18 Apr 2011 23:28:52 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB67E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB67E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN1PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEAM.TELSTRA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] Revised Section 3 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, 18 Apr 2011 23:29:51 -0000 I guess if making things complicated and dropping features and now having t= o go through the process of creating yet another specification is progress = than maybe we are, but on the other hand looks like we are making reverse p= rogress. -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Monday, April 18, 2011 4:24 PM To: Anthony Nadalin; Manger, James H; oauth Subject: RE: Revised Section 3 At least I finally got you to agree that this can be done in a separate spe= cification. That's progress. EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Monday, April 18, 2011 4:22 PM > To: Eran Hammer-Lahav; Manger, James H; oauth > Subject: RE: Revised Section 3 >=20 > I'm certainly glad you gave us your definition of "breaking" but sadly=20 > your definition is not in line with ours. When a developer sits down=20 > and codes to the spec and then goes to rev the code with the latest=20 > spec and things are removed the developer now either has to drop that=20 > feature or find an additional specification that has the same feature.=20 > Can this be done in a separate specification; sure it can just like we=20 > have been creating separate specifications to make the base useable. >=20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Monday, April 18, 2011 4:10 PM > To: Anthony Nadalin; Manger, James H; oauth > Subject: RE: Revised Section 3 >=20 > I don't think you understand what 'breaking' means. Breaking would be=20 > if we assigned a different meaning or syntax to the two parameters, or=20 > changed their name. Breaking requires code changes. There is nothing=20 > to prevent you from defining these parameters just like the SAML grant ty= pe did. >=20 > Was the relocation of the SAML assertion grant type to another=20 > document a "breaking" change? Clearly not according to the SAML grant typ= e authors. > The SAML specification is using the exact same extensibility framework=20 > this proposal can use. So technical issues aside, this is purely=20 > political to give this mechanism a stronger endorsement. >=20 > My objections, on the other hand, are purely technical. >=20 > As for consensus, (not wearing my editor hat) I am opposed to=20 > including that text. I have taken the time and effort to give my=20 > feedback in detail (more than once). So far no one has offered any=20 > rebuttals. I will hold off with any additional comments on this issue=20 > until the chairs decide how they want to proceed with this issue. >=20 > EHL >=20 > > -----Original Message----- > > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > > Sent: Monday, April 18, 2011 3:55 PM > > To: Eran Hammer-Lahav; Manger, James H; oauth > > Subject: RE: Revised Section 3 > > > > > The claim that "removing is a breaking issue" is patently wrong. > > > This claim > > was made many times before and is baseless. A breaking change would=20 > > cause current implementations using these two parameters to break. > > This is clearly not the case here since >the v2 specification=20 > > already provides a simple method for defining additional request=20 > > parameters as well as client authentication methods. > > > > It's clearly the case that we are on v10 wanting to rev our=20 > > implementation and the removal is a breaking change for us. So it's=20 > > not baseless as you continue to say. I think that the text that=20 > > Thomas has resurrected is just fine and I would support getting that=20 > > text > back into the document. > > > > > > -----Original Message----- > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > > Sent: Monday, April 18, 2011 3:46 PM > > To: Anthony Nadalin; Manger, James H; oauth > > Subject: RE: Revised Section 3 > > > > There are two separate issues here, procedural and technical. We=20 > > need to address both. > > > > Procedural issue: > > > > The issue is how should this use case be addressed by this working grou= p. > > There were always three options: > > > > 1. Not address by the WG - leaving it up to those interested to=20 > > submit an individual I-D to register their extension parameters and=20 > > use them as defined. > > 2. Address within v2 - add a section with similar functionality to=20 > > the Client Assertion Credentials section present in -11. > > 3. Publish a companion specification - basically #1 and #2 combined,=20 > > using the text from #2, published as a standalone working group > document. > > > > The *technical* end result of all three options is exactly the same. > > The same two parameters (or any other solution) will be defined in=20 > > the same way and used the same way. The issue in picking an option=20 > > from the above three is purely *political* and is about giving the=20 > > solution a higher degree of endorsement. The companies interested in=20 > > this work have already showed interest in other companion=20 > > specification so the argument of having to point developers to=20 > > multiple documents is completely without merit. Beyond that, it is=20 > > nothing but perceived level of > endorsement. > > > > The benefit of going with #1 or #3 is that we can close this issue=20 > > for > > v2 and move on without delaying the publication of the specification. > > Again, all three options lead to the exact same end solution and=20 > > same > "compliant" > > implementation. > > > > I would also point out that given the extensibility model we have=20 > > adopted, the authors of the proposed text could easily register the=20 > > two parameters without the need to build the same level of WG=20 > > consensus. Publishing a separate document is the only guaranteed=20 > > method of getting the two parameters to be officially registered (no=20 > > RFC is required, just a specification published somewhere which can=20 > > be > anywhere). > > > > Technical issue: > > > > As documented in my reply to this thread, there are many issues with=20 > > the proposed text and solution which must be resolved before any=20 > > route is taken. The biggest issue is that inventing a new HTTP=20 > > authentication method based on assertions is clearly outside the=20 > > scope of this working group. It is also far from established that=20 > > the proposed solution is the right solution for authenticating HTTP=20 > > requests > using an assertion. > > > > It doesn't matter if this is defined narrowly for use with the OAuth=20 > > token endpoint because what it does in practice is invent a new HTTP=20 > > authentication scheme, and doesn't even use the existing HTTP=20 > > authentication framework. > > > > The claim that "removing is a breaking issue" is patently wrong.=20 > > This claim was made many times before and is baseless. A breaking=20 > > change would cause current implementations using these two=20 > > parameters to break. This is clearly not the case here since the v2=20 > > specification already provides a simple method for defining=20 > > additional request parameters as well as client authentication methods. > > > > EHL > > > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > > > Behalf Of Anthony Nadalin > > > Sent: Monday, April 18, 2011 2:53 PM > > > To: Manger, James H; oauth > > > Subject: Re: [OAUTH-WG] Revised Section 3 > > > > > > >"3.3 Client Assertion Credentials". OAuth2 currently supports the=20 > > > >concept of > > > a client app swapping an assertion for an access token. Do people=20 > > > want the additional functionality of using assertions for generic=20 > > > client authentication? I assumed servers would >prefer that=20 > > > clients swap an assertion for a token at one specific endpoint,=20 > > > then use the token for generic client auth in other requests -- in=20 > > > which case section 3.3 "Client Assertion Credentials" can be dropped. > > > > > > We have the case where signed assertions are used for=20 > > > authentication and other cases where just client_id and secrets=20 > > > are used. I don't agree that client assertion credentials should=20 > > > be dropped or that HTTP Basic Authentication can do everything=20 > > > that we want/need and having to go the route of suggesting a new=20 > > > HTTP Authentication scheme while nice does not help us with the=20 > > > current OAUTH that we > have been developing. > > > Removing is a breaking issue. > > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > > > Behalf Of Manger, James H > > > Sent: Thursday, April 14, 2011 8:47 PM > > > To: oauth > > > Subject: Re: [OAUTH-WG] Revised Section 3 > > > > > > I'm certainly in favour of excluding client auth from OAuth. > > > Dropping section > > > 3 and just having a paragraph like the following would be=20 > > > preferable (with no capitalized keywords): > > > > > > In many cases an authorization server will require client > > > authentication for requests to a token endpoint. > > > Consequently, a client app that has credentials appropriate > > > for that server should proactively use them for such requests. > > > The actual mechanism for client authentication, and any > > > provisioning of the associated credentials, is outside > > > the scope of OAuth 2. > > > > > > > > > I am not a fan of the client_id/client_secret parameters, but was=20 > > > resigned to their inclusion given existing deployments. Given=20 > > > those parameters are mentioned, OAuth2 should say: > > > > > > Various early deployments of the OAuth 2.0 concepts authenticated > > > clients to the token endpoint using client_id and client_secret > > > parameters in the request (alongside the grant_type parameter > > > for instance). A server that accepts client_id/client_secret > > > parameters MUST also accept the same credentials presented using th= e > > > HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." requ= est > > > header). > > > > > > > > > The last paragraph of Thomas's "3.2 Shared Secret Credentials" is=20 > > > crazy (typo?). A server supporting some strong authentication=20 > > > mechanism must not be mandated to also support weaker BASIC and=20 > > > client_id/client_secret mechanisms -- and certainly not with the=20 > > > same > > secret! > > > > > > "3.3 Client Assertion Credentials". OAuth2 currently supports the=20 > > > concept of a client app swapping an assertion for an access token. > > > Do people want the additional functionality of using assertions=20 > > > for generic client authentication? I assumed servers would prefer=20 > > > that clients swap an assertion for a token at one specific=20 > > > endpoint, then use the token for generic client auth in other=20 > > > requests -- in which case section 3.3 "Client Assertion Credentials" = can be dropped. > > > > > > -- > > > James Manger > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > >=20 >=20 >=20 >=20 From eran@hueniverse.com Mon Apr 18 16:30:38 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 45086E0714 for ; Mon, 18 Apr 2011 16:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imNrnr+9Llmt for ; Mon, 18 Apr 2011 16:30:37 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 9FBC5E067C for ; Mon, 18 Apr 2011 16:30:37 -0700 (PDT) Received: (qmail 10682 invoked from network); 18 Apr 2011 23:30:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Apr 2011 23:30:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 18 Apr 2011 16:30:25 -0700 From: Eran Hammer-Lahav To: "Freeman, Tim" , "oauth@ietf.org" Date: Mon, 18 Apr 2011 16:30:22 -0700 Thread-Topic: Can you use POST to access protected resources? Thread-Index: Acv+H/cTCo39lC3CRdm2we908pF/kwAAGlLQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BB680@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <59DD1BA8FD3C0F4C90771C18F2B5B53A654494B720@GVW0432EXB.americas.hpqcorp.net> In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A654494B720@GVW0432EXB.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Can you use POST to access protected resources? 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, 18 Apr 2011 23:30:38 -0000 I'm a bit surprised by this question... Accessing protected resources is outside the scope of v2 but both Bearer an= d MAC clearly allow any HTTP method. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Freeman, Tim > Sent: Monday, April 18, 2011 4:26 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Can you use POST to access protected resources? >=20 > Section 7 of http://tools.ietf.org/html/draft-ietf-oauth-v2-15 gives exam= ples > of how to access protected resources. All of the examples use GET. >=20 > Our protected resources are identified by a query, which might be a few > kilobytes. I'm concerned that this may not fit inside the length limitat= ion on > GET's for some web servers. Our present implementation does a POST > instead. >=20 > Definition-by-example is easy to understand, but it is not good at > unambiguously specifying the boundary of permitted behavior. Was the > spec meant to allow using HTTP operations other than GET to access > protected resources? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From tim.freeman@hp.com Mon Apr 18 16:53:21 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6309CE0710 for ; Mon, 18 Apr 2011 16:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id darlLL-UUagP for ; Mon, 18 Apr 2011 16:53:20 -0700 (PDT) Received: from g4t0016.houston.hp.com (g4t0016.houston.hp.com [15.201.24.19]) by ietfc.amsl.com (Postfix) with ESMTP id AE462E070C for ; Mon, 18 Apr 2011 16:53:20 -0700 (PDT) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTPS id DD3E0148FE; Mon, 18 Apr 2011 23:53:19 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 18 Apr 2011 23:51:10 +0000 Received: from GVW0432EXB.americas.hpqcorp.net ([16.234.32.145]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Mon, 18 Apr 2011 23:51:10 +0000 From: "Freeman, Tim" To: Eran Hammer-Lahav , "oauth@ietf.org" Date: Mon, 18 Apr 2011 23:51:09 +0000 Thread-Topic: Can you use POST to access protected resources? Thread-Index: Acv+H/cTCo39lC3CRdm2we908pF/kwAAGlLQAABM2ZA= Message-ID: <59DD1BA8FD3C0F4C90771C18F2B5B53A654494B741@GVW0432EXB.americas.hpqcorp.net> References: <59DD1BA8FD3C0F4C90771C18F2B5B53A654494B720@GVW0432EXB.americas.hpqcorp.net> <90C41DD21FB7C64BB94121FBBC2E723447535BB680@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB680@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Can you use POST to access protected resources? 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, 18 Apr 2011 23:53:21 -0000 >Accessing protected resources is outside the scope of v2 but both Bearer a= nd MAC clearly allow any HTTP method. Thanks for pointing out that Bearer describes the entire request. From the= titles I had assumed that they just specified the format of the token. On quickly reading http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04= , and then looking at all occurrences of the word "method" in the document,= it doesn't seem to say what HTTP methods are permitted, beyond saying that= GET can't be used when posting the token via form-encoded HTTP body. Perh= aps it's in there somewhere and I was reading too fast. =20 Furthermore, section 7 of http://tools.ietf.org/html/draft-ietf-oauth-v2-15= does not say "beyond the scope" or "outside the scope" anywhere. I took t= hat section as a brief but meant-to-be-complete description of how to acces= s protected resources, deferring to Bearer only for the purpose of describi= ng the format of the access token itself. Of course, I now know that that = isn't what you meant. In any case, I'm sure you're right about the intent of the two specificatio= ns, so I'm more comfortable with our present code than I was before. Thank= s for the clarification. -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Monday, April 18, 2011 4:30 PM To: Freeman, Tim; oauth@ietf.org Subject: RE: Can you use POST to access protected resources? I'm a bit surprised by this question... Accessing protected resources is outside the scope of v2 but both Bearer an= d MAC clearly allow any HTTP method. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Freeman, Tim > Sent: Monday, April 18, 2011 4:26 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Can you use POST to access protected resources? >=20 > Section 7 of http://tools.ietf.org/html/draft-ietf-oauth-v2-15 gives exam= ples > of how to access protected resources. All of the examples use GET. >=20 > Our protected resources are identified by a query, which might be a few > kilobytes. I'm concerned that this may not fit inside the length limitat= ion on > GET's for some web servers. Our present implementation does a POST > instead. >=20 > Definition-by-example is easy to understand, but it is not good at > unambiguously specifying the boundary of permitted behavior. Was the > spec meant to allow using HTTP operations other than GET to access > protected resources? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Apr 18 16:54:44 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E6C77E0710 for ; Mon, 18 Apr 2011 16:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0SDVFahJEKa for ; Mon, 18 Apr 2011 16:54:44 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id 19FBBE070C for ; Mon, 18 Apr 2011 16:54:43 -0700 (PDT) Received: (qmail 13750 invoked from network); 18 Apr 2011 23:54:43 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Apr 2011 23:54:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 18 Apr 2011 16:54:32 -0700 From: Eran Hammer-Lahav To: "Freeman, Tim" , "oauth@ietf.org" Date: Mon, 18 Apr 2011 16:54:28 -0700 Thread-Topic: Can you use POST to access protected resources? Thread-Index: Acv+H/cTCo39lC3CRdm2we908pF/kwAAGlLQAABM2ZAAAJXgoA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BB68E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <59DD1BA8FD3C0F4C90771C18F2B5B53A654494B720@GVW0432EXB.americas.hpqcorp.net> <90C41DD21FB7C64BB94121FBBC2E723447535BB680@P3PW5EX1MB01.EX1.SECURESERVER.NET> <59DD1BA8FD3C0F4C90771C18F2B5B53A654494B741@GVW0432EXB.americas.hpqcorp.net> In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A654494B741@GVW0432EXB.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Can you use POST to access protected resources? 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, 18 Apr 2011 23:54:45 -0000 I'll make this more explicit in -16. Thanks. EHL > -----Original Message----- > From: Freeman, Tim [mailto:tim.freeman@hp.com] > Sent: Monday, April 18, 2011 4:51 PM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: RE: Can you use POST to access protected resources? >=20 > >Accessing protected resources is outside the scope of v2 but both Bearer > and MAC clearly allow any HTTP method. >=20 > Thanks for pointing out that Bearer describes the entire request. From t= he > titles I had assumed that they just specified the format of the token. >=20 > On quickly reading http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-= 04, > and then looking at all occurrences of the word "method" in the document,= it > doesn't seem to say what HTTP methods are permitted, beyond saying that > GET can't be used when posting the token via form-encoded HTTP body. > Perhaps it's in there somewhere and I was reading too fast. >=20 > Furthermore, section 7 of http://tools.ietf.org/html/draft-ietf-oauth-v2-= 15 > does not say "beyond the scope" or "outside the scope" anywhere. I took > that section as a brief but meant-to-be-complete description of how to > access protected resources, deferring to Bearer only for the purpose of > describing the format of the access token itself. Of course, I now know = that > that isn't what you meant. >=20 > In any case, I'm sure you're right about the intent of the two specificat= ions, > so I'm more comfortable with our present code than I was before. Thanks > for the clarification. >=20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Monday, April 18, 2011 4:30 PM > To: Freeman, Tim; oauth@ietf.org > Subject: RE: Can you use POST to access protected resources? >=20 > I'm a bit surprised by this question... >=20 > Accessing protected resources is outside the scope of v2 but both Bearer = and > MAC clearly allow any HTTP method. >=20 > EHL >=20 >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Freeman, Tim > > Sent: Monday, April 18, 2011 4:26 PM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] Can you use POST to access protected resources? > > > > Section 7 of http://tools.ietf.org/html/draft-ietf-oauth-v2-15 gives > > examples of how to access protected resources. All of the examples use > GET. > > > > Our protected resources are identified by a query, which might be a > > few kilobytes. I'm concerned that this may not fit inside the length > > limitation on GET's for some web servers. Our present implementation > > does a POST instead. > > > > Definition-by-example is easy to understand, but it is not good at > > unambiguously specifying the boundary of permitted behavior. Was the > > spec meant to allow using HTTP operations other than GET to access > > protected resources? > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From dnelson@elbrys.com Tue Apr 19 05:25:22 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C237E06C4 for ; Tue, 19 Apr 2011 05:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2r0VghPumBr for ; Tue, 19 Apr 2011 05:25:21 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfc.amsl.com (Postfix) with SMTP id 0987EE06A5 for ; Tue, 19 Apr 2011 05:25:20 -0700 (PDT) Received: from mail-wy0-f180.google.com ([74.125.82.180]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKTa1/MENVC8L/yCTSWxTqmsuTt0RmY/E4@postini.com; Tue, 19 Apr 2011 05:25:21 PDT Received: by mail-wy0-f180.google.com with SMTP id 26so7306325wyj.11 for ; Tue, 19 Apr 2011 05:25:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.150.207 with SMTP id z15mr6328570wbv.149.1303215919808; Tue, 19 Apr 2011 05:25:19 -0700 (PDT) Received: by 10.227.144.2 with HTTP; Tue, 19 Apr 2011 05:25:19 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 19 Apr 2011 08:25:19 -0400 Message-ID: From: Dave Nelson To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 19 Apr 2011 12:25:22 -0000 On Mon, Apr 18, 2011 at 6:46 PM, Eran Hammer-Lahav wrote: > Procedural issue: > The companies interested in this work have already showed interest > in other companion specification so the argument of having to point > developers to multiple documents is completely without merit. I'm sorry that my first post to this list will be about IETF etiquette, but this claim begs rebuttal. First, in the IETF representation is not by company, as it is in many other SDOs, but by individual. Second, publishing Standards Track RFCs is by IETF Consensus, the entire IETF not just the Working Group, so such issues are clearly not without merit. There are times when separating issues into multiple documents is simply a matter of organizing the workflow of the Working Group. Other times it's a matter of attempting to push on with a majority view, without establishing rough consensus. It's the latter that is to be avoided. It's also important to realize that the documents produced are not simply for the consumption of those active in their creation. They need to be well crafted and well organized for those who simply wish to adopt and implement the protocol(s) they describe. Leaving out important aspects, that will potentially impact multi-vendor interoperability is almost always a bad choice. > I would also point out that given the extensibility model we have adopted. > the authors of the proposed text could easily register the two parameters > without the need to build the same level of WG consensus. Publishing a > separate document is the only guaranteed method of getting the two > parameters to be officially registered (no RFC is required, just a specification > published somewhere which can be anywhere). Sorry, but IMHO this sounds a bit dismissive. > The claim that "removing is a breaking issue" is patently wrong. >From what I've read in this thread, I can't support that notion. If interoperable implementations can't be crafted without *some* resolution to this issue, it indeed seems like a "breaking issue" to me. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 From eran@hueniverse.com Tue Apr 19 07:11:30 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 23805E06F8 for ; Tue, 19 Apr 2011 07:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlWSU53F-x0s for ; Tue, 19 Apr 2011 07:11:29 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 81251E06E9 for ; Tue, 19 Apr 2011 07:11:29 -0700 (PDT) Received: (qmail 20094 invoked from network); 19 Apr 2011 14:11:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Apr 2011 14:11:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 19 Apr 2011 07:11:15 -0700 From: Eran Hammer-Lahav To: Dave Nelson Date: Tue, 19 Apr 2011 07:11:09 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv+jNqN6qkGsniLRi6zxFKGOQPyYwADZ/Tg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BB71B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 19 Apr 2011 14:11:30 -0000 > -----Original Message----- > From: Dave Nelson [mailto:dnelson@elbrys.com] > Sent: Tuesday, April 19, 2011 5:25 AM > > The claim that "removing is a breaking issue" is patently wrong. >=20 > From what I've read in this thread, I can't support that notion. If > interoperable implementations can't be crafted without *some* resolution > to this issue, it indeed seems like a "breaking issue" to me. This might be correct in general, but you are taking this out of the specif= ic context of the requested change. The proposed change does not accomplish by itself any level of interoperabi= lity since it is merely an extension point. It cannot be used without furth= er profiling (and I have demonstrated in a previous reply why even further = profiling might not produce a secure solution given the vague normative req= uirements provided). IOW, in order for this proposed change to accomplish interoperability, addi= tional specifications must be published (which also addresses some of your = other concerns). EHKL From hardjono@mit.edu Tue Apr 19 08:44:04 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 88062E0691 for ; Tue, 19 Apr 2011 08:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JkOXw3jrHev for ; Tue, 19 Apr 2011 08:44:03 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfc.amsl.com (Postfix) with ESMTP id 988FAE0664 for ; Tue, 19 Apr 2011 08:44:03 -0700 (PDT) X-AuditID: 1209190d-b7c48ae000004826-82-4dadad958a1f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id C4.3B.18470.59DADAD4; Tue, 19 Apr 2011 11:43:17 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p3JFi217017560; Tue, 19 Apr 2011 11:44:02 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id p3JFhxR4030791; Tue, 19 Apr 2011 11:44:01 -0400 Received: from oc11exhub5.exchange.mit.edu (18.9.3.15) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Apr 2011 11:42:50 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub5.exchange.mit.edu ([18.9.3.15]) with mapi; Tue, 19 Apr 2011 11:44:00 -0400 From: Thomas Hardjono To: Eran Hammer-Lahav Date: Tue, 19 Apr 2011 11:43:58 -0400 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv+jNqN6qkGsniLRi6zxFKGOQPyYwADZ/TgAAMUqBA= Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB71B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB71B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CBFE87.0FE07740" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02SX0hTYRjG+/b3bHniOGf73MpwYKljK6VATKKLgnkxHHVhZKJHd3Kjbco5 U9QQZlmWmkxYpSvSclmIZoWWaFoubU0hlBGRSqJ4IZrWLspyoZ2z47+73/s9z/e838v3IlxJ rUCOmKw2grTiZqVAzJOIIlXq2x0duiP9NzXJow9bQLJvaUFwkqO9O5yudbv/cvSc8+JUA2E2 FRPk4RM5YuPPqXph4TNdyeOKgMAOrmirgQiB2FHoX+sVsLwXjn3rpFmMSLABABt/zwrZ4h2A Nx5MArbwAthX93ZD6QawxuHfKBwA+u9MhMIEWBz8FOwXMizFVNDx5R6PYS4mh7OVIyHmYbHw 6noTh+EILB5WB69xWX8C9I/Nb3AKrFvoDjGK6eG408tlmzXx4NATf6iZCMuEFZ4ePsOAnmJl pJ3DNpPBiTm2AcSkcGZ8dGvStd4ZAeuPhFNVnaHZuNgtAH/9WeKz3cKhr3GORw/l2pHl2ulz 7fC5AEILGnj9BWD9B+Drpftclo/DhtVBAcsx0FkzI2T5GFwcDoBmgLSB/QZLmdqCm8wUkaem 8nCrlSDVSRqLyaYhDEUvQejTo9AesDyo9AAMAcowtLytQyfh48VUqcUDohCOMhItaaeP9uQW GEqNOGXMJovMBOUBEOEqpai0ldZQA15aRpAFm5IC4SllaGPUIZ0Ey8dtxCWCKCTITXUfgigh us6EhpNEPlFy0WS2bcscRMSEh9HhGcxbUKoQt1CmfFYfATFyGaqgt1SCMYKxyLp1d3OJF4CM HiUCVTGuMHrFt24v0MEcOjgrtZ0JtuHbktwO9GOTpw6qpsXj9rjowL8Yp1unSX5zGU3aXWc+ N+GtPFsenrbiTUjv6hqafm80uZdXsfrJzB+KR5l64crH4NdXrqDzqSWhEOk/ncv37bLnORXa FGnWh/5mXw5xZuazo2UoTfZwoMEWu1jmq824kD0Q6HPFxXe5WuPnqxKjvz9X8igjnpjAJSn8 P5ecuBefAwAA Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 19 Apr 2011 15:44:04 -0000 ------=_NextPart_000_0000_01CBFE87.0FE07740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Tuesday, April 19, 2011 10:11 AM > To: Dave Nelson > Cc: oauth > Subject: Re: [OAUTH-WG] Revised Section 3 > > > > > -----Original Message----- > > From: Dave Nelson [mailto:dnelson@elbrys.com] > > Sent: Tuesday, April 19, 2011 5:25 AM > > > > The claim that "removing is a breaking issue" is patently wrong. > > > > From what I've read in this thread, I can't support that notion. If > > interoperable implementations can't be crafted without *some* > > resolution to this issue, it indeed seems like a "breaking issue" to > me. > > This might be correct in general, but you are taking this out of the > specific context of the requested change. > > The proposed change does not accomplish by itself any level of > interoperability since it is merely an extension point. It cannot be > used without further profiling (and I have demonstrated in a previous > reply why even further profiling might not produce a secure solution > given the vague normative requirements provided). > > IOW, in order for this proposed change to accomplish interoperability, > additional specifications must be published (which also addresses some > of your other concerns). Hi Eran, If its ok with you, may I offer some friendly suggestion. Section 3 does not take away anything from your work and enormous contribution to the Oauth 2.0 main spec. If anything, Section 3 shows that lots of people are interested in seeing OAuth 2.0 deployed in other environments and being integrated into other authentication infrastructures (eg. enterprise infra). I view this as a positive success point and achievement for Oauth 2.0. And yes, further profiling & specs will be needed for each and every type of credential mentioned in Section 3 in order to get interoperability. That's always been my understanding (and I believe that is also the understanding of other folks who want Section 3 to stay). Perhaps it would best to just leave Section 3 where it is, and to move on to other aspects of the draft. Thanks. /thomas/ ------=_NextPart_000_0000_01CBFE87.0FE07740 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+4wggTMMIIDtKADAgECAhA04y/94Vi/dkaC9/1NZ7F6MA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTEwMzAzMDAwMDAwWhcNMTIwMzAyMjM1OTU5WjCCARMxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9u bzEfMB0GCSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAqXFlCDKk41h+Qdsa43S4gLmnm78zrrujeF/9ehTTbO2xWpQN5RXC1iaqTH3yfqdzZVax ssJ5yg5adnNBJUjFgy5FbgEzthKGURl+CcLvWhAVAVsAJhu227qhK/2SPnIXGP43u1TlZD+8LU9E WngkY3M3AiKhcclB0G9hX31qXsUCAwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAL BgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBD oEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRh bElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA3xiHqu8i5pWT418M2F07ZFN5tpHyOF2mJH8M M/mtUqkI6OpdT7X1YI68pv2UALawaTQIwLpFDDv2vTPyi9+yVANyngAUqe9QogpUhnVv0U6utNrE aFzIjwkoaPDpacOZRvz47yl4eN36rM2vGJ1i3eZfsEA8X0+aepIsUsX9zwZ69ocXyhs4+xNiEByQ YwBIUA2JUCf/bv5lIY4sX3XLHddtBgZ8vGPCjiJDu+1tXwdjqf2NyeHJRHk3TcNH7Nd3HSpR7Ojn fuMzpOtmRTuJ4N74J1+Ck4LWA3s6ZofXbGL/8qglffU1Wf+XW89L3hIKMfY4z3hf++YustE+Fmwj 1jCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV 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 dWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQNOMv/eFYv3ZGgvf9TWexejAJBgUrDgMCGgUAoIIDGzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0MTkxNTQzNTVaMCMG CSqGSIb3DQEJBDEWBBRvwdFnDKM3DLMkzQ3hStamro81kTCBqwYJKoZIhvcNAQkPMYGdMIGaMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCCAQMGCSsGAQQBgjcQBDGB9TCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhA0 4y/94Vi/dkaC9/1NZ7F6MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQNOMv/eFYv3ZGgvf9TWexejANBgkq hkiG9w0BAQEFAASBgJ+1y9+nKixociH5n36ti7y4TtukWVlujB2V2E/+rMPFFSLNbB2MY744xfgT 4UkmqKotP6TjXiGmY3eM8JLNl6kRHi0siRLIHNWmw6cuhm8ai8JusBKVwvXe5Zi6T4U4ANBRPpFY RYTcOVfKuVuClGDk/veXyw49L5QzsHjjFmN8AAAAAAAA ------=_NextPart_000_0000_01CBFE87.0FE07740-- From eran@hueniverse.com Tue Apr 19 09:26:36 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 469D1E07DA for ; Tue, 19 Apr 2011 09:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tc-MzCn7yin2 for ; Tue, 19 Apr 2011 09:26:34 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id 97C53E07C0 for ; Tue, 19 Apr 2011 09:26:34 -0700 (PDT) Received: (qmail 2666 invoked from network); 19 Apr 2011 16:26:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Apr 2011 16:26:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 19 Apr 2011 09:26:32 -0700 From: Eran Hammer-Lahav To: Thomas Hardjono Date: Tue, 19 Apr 2011 09:26:27 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv+jNqN6qkGsniLRi6zxFKGOQPyYwADZ/TgAAMUqBAAAL0nYA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BB7A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB71B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 19 Apr 2011 16:26:36 -0000 Hey Thomas, > -----Original Message----- > From: Thomas Hardjono [mailto:hardjono@MIT.EDU] > Sent: Tuesday, April 19, 2011 8:44 AM > If its ok with you, may I offer some friendly suggestion. > Section 3 does not take away anything from your work and > enormous contribution to the Oauth 2.0 main spec. This is not a personal issue... :-) Unlike the bearer token functionality which I consider harmful to the web a= nd refuse to have my name associated with it, this is just a case of poorly= defined functionality and the wrong way to define an HTTP authentication s= cheme. IOW, this one is purely about the technical qualities of the proposa= l. If my concerns are addressed, I don't have other external objections to = the functionality. The right example to compare this to is the discussion over the inclusion a= nd definition of the 'scope' parameter. While much less complex, the discus= sion over how much to specify the 'scope' parameter is touching the same in= teroperability concerns. > If anything, Section 3 shows that lots of people are > interested in seeing OAuth 2.0 deployed in other environments > and being integrated into other authentication > infrastructures (eg. enterprise infra). > I view this as a positive success point and achievement for Oauth 2.0. Yes and no. At some point, if you extend the reach of a protocol beyond its original pu= rpose you end up with a useless framework. I don't want to create another S= OAP or WS-*. Now, this is my personal view and I understand that in the context of an IE= TF standard creation every community (consumer web, enterprise, telecom, go= vernmental, etc.) has a right to its voice. This is why I have not objected= to this addition on the basis of WG scope, use cases, or requirements (whi= ch I could have easily done). My objection is purely on the technical quali= ty of the solution. The issue at hand is where to draw the line when it comes to defining exten= sibility. This is the main theme behind other open issues as well. I believ= e the document as currently defined provides sufficient extensibility while= still providing a complete authorization protocol. This proposal merely ta= kes that extensibility and moves it 1% forward with a tiny bit more special= ization for one use case. =20 > And yes, further profiling & specs will be needed for each and every > type of credential mentioned in Section 3 in order to get > interoperability. That's always been my understanding (and > I believe that is also the understanding > of other folks who want Section 3 to stay). The only way we can test if the proposal works is by doing exactly that. Th= e same way we require multiple interoperable implementations before finish = a standard, we should require at least one published draft making use of th= is extension point and complying with its requirements. How else would we k= now that we got it right? For example, the SAML draft tested out the grant type and parameter extensi= on point. The bearer and MAC drafts tested out the token type extension poi= nt. The UX draft tested out the error extension point (though not explicitl= y). So regardless of the text being incorporated at the end, someone will need = to publish a draft making use of it so that we can verify we have the right= solution specified. > Perhaps it would best to just leave Section 3 where it is, > and to move on to other aspects of the draft. If you mean leave -15 section 3 as-is, I completely agree. :-) I think your draft has some new, useful prose that I plan to incorporate ei= ther way (namely the new section about other authentication protocols). I a= lso think that we should go back to the previous text focusing on the HTTP = Basic scheme and defining the parameters alternative as just that (so as to= not create a new authentication scheme, but merely document how people are= "hacking" on Basic). I believe we have consensus to making those changed i= n -16. Personally, I would go as far as to declare the two basic parameters as MAY= support for servers and NOT RECOMMENDED for clients. But we don't have con= sensus for this yet (it wasn't framed this way before). So there is value in an overall review of section 3 which your contribution= has facilitated. Since no new voices have been added to this discussion since it was origina= lly introduced (on either side), the only next step with the new functional= ity (client assertion credentials) is to wait for the chairs to take over t= his discussion and outline how they want to gage consensus. Further discuss= ion between the same people is pointless - no one is saying anything new, m= yself included. EHL From recordond@gmail.com Tue Apr 19 10:51:13 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8B887E0768 for ; Tue, 19 Apr 2011 10:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7vZqMoPlAya for ; Tue, 19 Apr 2011 10:51:12 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id D75FCE0685 for ; Tue, 19 Apr 2011 10:51:07 -0700 (PDT) Received: by vxg33 with SMTP id 33so5596131vxg.31 for ; Tue, 19 Apr 2011 10:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=b7vwebRmLxej+xJztEW7/Hdx/EGdejB+NansBbtWjW0=; b=cwie1rRl1pIk/p4qavqSQ0nYI1YUPGl36zXF9nOnjwMwb0oKeTmxKhHS0fA3Ckddfu aC3mjJbbzIX0ZZ/UIYS/tKfs/dfF7o85IqmKWpzEwzm0OsUqACgR1qvoI3E92IL7483b x22QE7Jdz2ijcyoggYM5jirISE8DeTj0/DweE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=WVK1pfAKEkGgC/dd5mYW+1mNVP4NaBx2vMIcUDbEY2qWCgDcsOgFXBA5Dnyt2w36HJ 7miZYH2SxZ/wNiGmbdDxPefbfrx/83kHEDrKy7pexsiRzFitUjOOL/pEc2QYykEDzZDc SBOftNp9llfL7gz5F4yoNA2xIANZ9/4DECNoI= MIME-Version: 1.0 Received: by 10.52.66.104 with SMTP id e8mr2759983vdt.132.1303235467408; Tue, 19 Apr 2011 10:51:07 -0700 (PDT) Received: by 10.52.155.42 with HTTP; Tue, 19 Apr 2011 10:51:07 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB7A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB71B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB7A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 19 Apr 2011 10:51:07 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav , oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Revised Section 3 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, 19 Apr 2011 17:51:13 -0000 I think requests like this and the following discussions have scared away many of the original voices behind OAuth 2.0. As Eran said, the goal was never to create a new framework but standardize interoperable best practices that the industry was adopting. Under-defined extension points don't make this specification easier to adopt in a pragmatic fashion. (Obviously my individual $0.02.) --David On Tue, Apr 19, 2011 at 9:26 AM, Eran Hammer-Lahav wr= ote: > Hey Thomas, > >> -----Original Message----- >> From: Thomas Hardjono [mailto:hardjono@MIT.EDU] >> Sent: Tuesday, April 19, 2011 8:44 AM > >> If its ok with you, may I offer some friendly suggestion. >> Section 3 does not take away anything from your work and >> enormous contribution to the Oauth 2.0 main spec. > > This is not a personal issue... :-) > > Unlike the bearer token functionality which I consider harmful to the web= and refuse to have my name associated with it, this is just a case of poor= ly defined functionality and the wrong way to define an HTTP authentication= scheme. IOW, this one is purely about the technical qualities of the propo= sal. If my concerns are addressed, I don't have other external objections t= o the functionality. > > The right example to compare this to is the discussion over the inclusion= and definition of the 'scope' parameter. While much less complex, the disc= ussion over how much to specify the 'scope' parameter is touching the same = interoperability concerns. > >> If anything, Section 3 shows that lots of people are >> interested in seeing OAuth 2.0 deployed in other environments >> and being integrated into other authentication >> infrastructures (eg. enterprise infra). >> I view this as a positive success point and achievement for Oauth 2.0. > > Yes and no. > > At some point, if you extend the reach of a protocol beyond its original = purpose you end up with a useless framework. I don't want to create another= SOAP or WS-*. > > Now, this is my personal view and I understand that in the context of an = IETF standard creation every community (consumer web, enterprise, telecom, = governmental, etc.) has a right to its voice. This is why I have not object= ed to this addition on the basis of WG scope, use cases, or requirements (w= hich I could have easily done). My objection is purely on the technical qua= lity of the solution. > > The issue at hand is where to draw the line when it comes to defining ext= ensibility. This is the main theme behind other open issues as well. I beli= eve the document as currently defined provides sufficient extensibility whi= le still providing a complete authorization protocol. This proposal merely = takes that extensibility and moves it 1% forward with a tiny bit more speci= alization for one use case. > >> And yes, further profiling & specs will be needed for each and every >> type of credential mentioned in Section 3 in order to get >> interoperability. That's always been my understanding (and >> I believe that is also the understanding >> of other folks who want Section 3 to stay). > > The only way we can test if the proposal works is by doing exactly that. = The same way we require multiple interoperable implementations before finis= h a standard, we should require at least one published draft making use of = this extension point and complying with its requirements. How else would we= know that we got it right? > > For example, the SAML draft tested out the grant type and parameter exten= sion point. The bearer and MAC drafts tested out the token type extension p= oint. The UX draft tested out the error extension point (though not explici= tly). > > So regardless of the text being incorporated at the end, someone will nee= d to publish a draft making use of it so that we can verify we have the rig= ht solution specified. > >> Perhaps it would best to just leave Section 3 where it is, >> and to move on to other aspects of the draft. > > If you mean leave -15 section 3 as-is, I completely agree. :-) > > I think your draft has some new, useful prose that I plan to incorporate = either way (namely the new section about other authentication protocols). I= also think that we should go back to the previous text focusing on the HTT= P Basic scheme and defining the parameters alternative as just that (so as = to not create a new authentication scheme, but merely document how people a= re "hacking" on Basic). I believe we have consensus to making those changed= in -16. > > Personally, I would go as far as to declare the two basic parameters as M= AY support for servers and NOT RECOMMENDED for clients. But we don't have c= onsensus for this yet (it wasn't framed this way before). > > So there is value in an overall review of section 3 which your contributi= on has facilitated. > > Since no new voices have been added to this discussion since it was origi= nally introduced (on either side), the only next step with the new function= ality (client assertion credentials) is to wait for the chairs to take over= this discussion and outline how they want to gage consensus. Further discu= ssion between the same people is pointless - no one is saying anything new,= myself included. > > EHL > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From dick.hardt@gmail.com Tue Apr 19 11:37:25 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1B75EE0664 for ; Tue, 19 Apr 2011 11:37:25 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1JDLWrn5RJq for ; Tue, 19 Apr 2011 11:37:24 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 08C92E0669 for ; Tue, 19 Apr 2011 11:37:22 -0700 (PDT) Received: by pwi5 with SMTP id 5so4833pwi.31 for ; Tue, 19 Apr 2011 11:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=zIdh4hLV2sAYGwHzGIJ2kGwg21njsPeIlqs9Yf/KqTI=; b=A4cDaIzd8gOOpnbpEYzJHoggX0ot6f9xbMY+KFGYkuoA80SMhrBfY/Kix0yZ+FZMji 8AbFlpjBWwbeURrRL0ecMlJvymWjFlmjiqxRInZRdEdVbGfB2N1Vrzue2UOAPFiduWOb 9zodhzrHBwcHOrzb6LmxkInL2hYMufECHWQ5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=OKzoO+H2cOD9fyUjXfFB09jA/Vu/7klFMLPh1o07U3Dh+7WEHdqBhAy0988vhLCIIt CTQo6OEjiRTMQvkf3j0EmW6K65zIZUBxWJaFKDKlyWMBDot+GS5hAZAEyqgVMS/3T2yM x0+pT0gS2zcG/53bp4uinNMvrM3BAComovvuQ= Received: by 10.68.0.71 with SMTP id 7mr9104945pbc.226.1303238242506; Tue, 19 Apr 2011 11:37:22 -0700 (PDT) Received: from [192.168.1.45] (c-24-5-83-209.hsd1.ca.comcast.net [24.5.83.209]) by mx.google.com with ESMTPS id i3sm97728pbb.26.2011.04.19.11.37.19 (version=SSLv3 cipher=OTHER); Tue, 19 Apr 2011 11:37:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Tue, 19 Apr 2011 11:37:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7730636D-2EEA-474A-B245-EA7EABFF0995@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB71B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB7A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: David Recordon X-Mailer: Apple Mail (2.1084) Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 19 Apr 2011 18:37:25 -0000 On 2011-04-19, at 10:51 AM, David Recordon wrote: > I think requests like this and the following discussions have scared > away many of the original voices behind OAuth 2.0. As Eran said, the > goal was never to create a new framework but standardize interoperable > best practices that the industry was adopting. Under-defined extension > points don't make this specification easier to adopt in a pragmatic > fashion. I disagree David. While the original IETF WG charter was to standardize OAuth 1.0, we are = now working on OAuth 2.0. The feature described was in OAuth-WRAP which was a basis for OAuth 2.0.=20= -- Dick From eran@hueniverse.com Tue Apr 19 11:41:24 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 00D79E076F for ; Tue, 19 Apr 2011 11:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wXKRPtGznI2 for ; Tue, 19 Apr 2011 11:41:20 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id 5EBB9E06DE for ; Tue, 19 Apr 2011 11:41:20 -0700 (PDT) Received: (qmail 4655 invoked from network); 19 Apr 2011 18:41:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Apr 2011 18:41:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 19 Apr 2011 11:41:06 -0700 From: Eran Hammer-Lahav To: Dick Hardt , David Recordon Date: Tue, 19 Apr 2011 11:41:00 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv+wNQuDcUsC7T5SI6uuYGUTfMhIwAAGilw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BB829@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB71B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB7A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7730636D-2EEA-474A-B245-EA7EABFF0995@gmail.com> In-Reply-To: <7730636D-2EEA-474A-B245-EA7EABFF0995@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 19 Apr 2011 18:41:24 -0000 > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Tuesday, April 19, 2011 11:37 AM =20 > The feature described was in OAuth-WRAP which was a basis for OAuth 2.0. Can you please point me to where this feature was in WRAP? I can't find it. EHL From dick.hardt@gmail.com Tue Apr 19 11:58:43 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 01981E0675 for ; Tue, 19 Apr 2011 11:58:43 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNzKxrZgik6P for ; Tue, 19 Apr 2011 11:58:41 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id 2E1D9E0669 for ; Tue, 19 Apr 2011 11:58:41 -0700 (PDT) Received: by pxi20 with SMTP id 20so733pxi.27 for ; Tue, 19 Apr 2011 11:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=7xVgh2Pw8Ao7gLv4mDMuY+5SnDBKAljUrDZ2xomZlbo=; b=UI36xbrcVHcjrYNC6H2egbG/rC/0sTeb0HL66t+wYtE4/U1kyGvDlh9FVAABp/Qv/5 N5Qj3Q+M7iMGyPcufXOebsBt8/OJ0WSNsAIqHwcYF/Ar1f0WkL8DvTHRKy79OCpjrmNM xfIsrLmgou0zSr/caZ/sN1btvW9Y0W/cRYdrc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=fs91RciMS+J06OPpq3iR7gkaPFunLPD5n2qxKKABtDRGdMPOGvMA58hadiTjj5G/9V CXE79GrboBZ0KiHJtGTeDzchskdDyteNlTqOJhSwLpl9+edEtDDPvYSQMeI2KQFNafxZ w62cPWuAYK/pC7Df3DvwiNTdHSG95nEWRtwWw= Received: by 10.68.5.36 with SMTP id p4mr9187715pbp.253.1303239520533; Tue, 19 Apr 2011 11:58:40 -0700 (PDT) Received: from [192.168.1.45] (c-24-5-83-209.hsd1.ca.comcast.net [24.5.83.209]) by mx.google.com with ESMTPS id d2sm101413pba.100.2011.04.19.11.58.38 (version=SSLv3 cipher=OTHER); Tue, 19 Apr 2011 11:58:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB829@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 19 Apr 2011 11:58:36 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7B9D9A4E-73C8-43D1-9819-6D571F630E9C@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB71B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB7A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7730636D-2EEA-474A-B245-EA7EABFF0995@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB829@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 19 Apr 2011 18:58:43 -0000 On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote: > > >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Tuesday, April 19, 2011 11:37 AM > >> The feature described was in OAuth-WRAP which was a basis for OAuth 2.0. > > Can you please point me to where this feature was in WRAP? I can't find it. http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 ... or am I confused about what we are talking about changing in Section 3? From eran@hueniverse.com Tue Apr 19 12:27:59 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 687B4E0776 for ; Tue, 19 Apr 2011 12:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wz0hBGnVzIxE for ; Tue, 19 Apr 2011 12:27:58 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id 96F44E0761 for ; Tue, 19 Apr 2011 12:27:58 -0700 (PDT) Received: (qmail 27939 invoked from network); 19 Apr 2011 19:27:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Apr 2011 19:27:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 19 Apr 2011 12:27:53 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Tue, 19 Apr 2011 12:27:48 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv+w9BrWKi9UM0WTuSQM++18WL+8QAAdCig Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BB856@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB71B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB7A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7730636D-2EEA-474A-B245-EA7EABFF0995@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB829@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7B9D9A4E-73C8-43D1-9819-6D571F630E9C@gmail.com> In-Reply-To: <7B9D9A4E-73C8-43D1-9819-6D571F630E9C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 19 Apr 2011 19:27:59 -0000 Yes, you are confused... WRAP section 5.2 defines an assertion authorization grant type which is pro= vided in OAuth 2.0 via two parts: 1. v2 extensible grant types [1], which provides the wrap_assertion_format = parameter functionality. You simply provide a URI to identify the assertion= format and include it using the grant_type parameter. No additional parame= ters needed. 2. SAML bearer assertion grant type document [2] which provides the wrap_as= sertion parameter functionality via the assertion parameter. The assertion = parameter is defined in the context of the SAML extension, but is registere= d as a general purpose parameter and available for any future assertion gra= nt types if they so desire. This thread (and open issue) is about a new (to WRAP and OAuth 2.0 pre -11)= client authentication method using assertions. It can be combined with the= WRAP functionality described above to produce requests with two separate a= ssertions (in the same request). The two functionalities has nothing to do = with one another except that both use assertions as each assertions serves = a completely different purpose (one for client authentication, and the othe= r for access authorization). Therefore, this is new functionality that was never discussed or suggested = before Yaron Goland proposal was submitted and added to -11 and later remov= ed in -12. And to prevent a broken record reply I'll add: both actions, tak= en by me, were done without working group consensus. So while adding and re= moving the section between -11 and -12 was not proper IETF editorial proces= s, the end result is nevertheless the same - the section is out of the docu= ment pending working group consensus for inclusion. EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.5 [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03 > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Tuesday, April 19, 2011 11:59 AM > To: Eran Hammer-Lahav > Cc: David Recordon; oauth > Subject: Re: [OAUTH-WG] Revised Section 3 >=20 >=20 > On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote: >=20 > > > > > >> -----Original Message----- > >> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >> Sent: Tuesday, April 19, 2011 11:37 AM > > > >> The feature described was in OAuth-WRAP which was a basis for OAuth > 2.0. > > > > Can you please point me to where this feature was in WRAP? I can't find= it. >=20 > http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 >=20 > ... or am I confused about what we are talking about changing in Section = 3? From dick.hardt@gmail.com Tue Apr 19 13:25:21 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7D4E9E0678 for ; Tue, 19 Apr 2011 13:25:21 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcPkyneU4CrN for ; Tue, 19 Apr 2011 13:25:20 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfc.amsl.com (Postfix) with ESMTP id 38E07E0670 for ; Tue, 19 Apr 2011 13:25:20 -0700 (PDT) Received: by pvh1 with SMTP id 1so37937pvh.31 for ; Tue, 19 Apr 2011 13:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=G19Q6fvOchjyIH58P1d8/OG/6xWdoOWVeXzUKM+wIGE=; b=Z98/Qtp+GrTlXuwABCxpaNOkwc0k4xe903lH2a0Yv870hIpfuyARejvFVKF7rk9drG ZONfcqKvgiNTSF+ruyrt/34qZOcUB4/IVs1hVCoUhXajrLi1kKfP0V48iGZXW8HIeWa/ QKddjqkqeWPFu2Bh37QN0Uiup627IhzQvsWJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=l2ZZpnyIlh9sEfgIAMcOBv7dIvAzQEm7vtl7ZBs4v6r/qQJ9LsapiHbO+QsHiK9Zy7 x651bpV46X1R+Vf96SObeOwKwikmNqZK457xjXhgnxoVLODbGS9RCYh9dFxpJVYPWq9I TDqBlpTX8d8/tb9oYguWjt3DVakBQUnyOORCU= Received: by 10.143.158.4 with SMTP id k4mr797690wfo.205.1303244719624; Tue, 19 Apr 2011 13:25:19 -0700 (PDT) Received: from [192.168.1.45] (c-24-5-83-209.hsd1.ca.comcast.net [24.5.83.209]) by mx.google.com with ESMTPS id d10sm142552pbe.75.2011.04.19.13.25.17 (version=SSLv3 cipher=OTHER); Tue, 19 Apr 2011 13:25:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB856@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 19 Apr 2011 13:25:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E7234465674411C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281FB7C3C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB672@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB71B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BB7A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7730636D-2EEA-474A-B245-EA7EABFF0995@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB829@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7B9D9A4E-73C8-43D1-9819-6D571F630E9C@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723447535BB856@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 19 Apr 2011 20:25:21 -0000 Thanks for clarifying. Given how you have broken out Section 3 from the = rest of the flow, I missed 4.5. It is not clear in 4.5 that an access token is returned since in the = previous sections, there is a separate request and response section. = What is the response supposed to look like when using an access token? = Some of the confusion here may be that 4.5 is not as complete as the = other sections. -- Dick On 2011-04-19, at 12:27 PM, Eran Hammer-Lahav wrote: > Yes, you are confused... >=20 > WRAP section 5.2 defines an assertion authorization grant type which = is provided in OAuth 2.0 via two parts: >=20 > 1. v2 extensible grant types [1], which provides the = wrap_assertion_format parameter functionality. You simply provide a URI = to identify the assertion format and include it using the grant_type = parameter. No additional parameters needed. >=20 > 2. SAML bearer assertion grant type document [2] which provides the = wrap_assertion parameter functionality via the assertion parameter. The = assertion parameter is defined in the context of the SAML extension, but = is registered as a general purpose parameter and available for any = future assertion grant types if they so desire. >=20 > This thread (and open issue) is about a new (to WRAP and OAuth 2.0 pre = -11) client authentication method using assertions. It can be combined = with the WRAP functionality described above to produce requests with two = separate assertions (in the same request). The two functionalities has = nothing to do with one another except that both use assertions as each = assertions serves a completely different purpose (one for client = authentication, and the other for access authorization). >=20 > Therefore, this is new functionality that was never discussed or = suggested before Yaron Goland proposal was submitted and added to -11 = and later removed in -12. And to prevent a broken record reply I'll add: = both actions, taken by me, were done without working group consensus. So = while adding and removing the section between -11 and -12 was not proper = IETF editorial process, the end result is nevertheless the same - the = section is out of the document pending working group consensus for = inclusion. >=20 > EHL >=20 > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.5 > [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03 >=20 >=20 >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Tuesday, April 19, 2011 11:59 AM >> To: Eran Hammer-Lahav >> Cc: David Recordon; oauth >> Subject: Re: [OAUTH-WG] Revised Section 3 >>=20 >>=20 >> On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote: >>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>>> Sent: Tuesday, April 19, 2011 11:37 AM >>>=20 >>>> The feature described was in OAuth-WRAP which was a basis for OAuth >> 2.0. >>>=20 >>> Can you please point me to where this feature was in WRAP? I can't = find it. >>=20 >> http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 >>=20 >> ... or am I confused about what we are talking about changing in = Section 3? From eran@hueniverse.com Tue Apr 19 14:01:16 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D9C69E0814 for ; Tue, 19 Apr 2011 14:01:16 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWVYnPqOkKgH for ; Tue, 19 Apr 2011 14:01:15 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id 83744E0808 for ; Tue, 19 Apr 2011 14:01:15 -0700 (PDT) Received: (qmail 28575 invoked from network); 19 Apr 2011 21:01:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Apr 2011 21:01:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 19 Apr 2011 14:00:44 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Tue, 19 Apr 2011 14:00:40 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv+1Nj+J4sOKgNeRlmghXAqtYqwTQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9D345C2110B7eranhueniversecom_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] Revised Section 3 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, 19 Apr 2011 21:01:17 -0000 --_000_C9D345C2110B7eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So your suggestions is to add something like 4.4.3 to 4.5? That sounds like= a good idea. Would that resolve the potential confusion here? EHL From: Dick Hardt > Date: Tue, 19 Apr 2011 13:25:15 -0700 To: Eran Hammer-lahav > Cc: "recordond@gmail.com" >, oauth > Subject: Re: [OAUTH-WG] Revised Section 3 Thanks for clarifying. Given how you have broken out Section 3 from the res= t of the flow, I missed 4.5. It is not clear in 4.5 that an access token is returned since in the previo= us sections, there is a separate request and response section. What is the = response supposed to look like when using an access token? Some of the con= fusion here may be that 4.5 is not as complete as the other sections. -- Dick On 2011-04-19, at 12:27 PM, Eran Hammer-Lahav wrote: Yes, you are confused... WRAP section 5.2 defines an assertion authorization grant type which is pro= vided in OAuth 2.0 via two parts: 1. v2 extensible grant types [1], which provides the wrap_assertion_format = parameter functionality. You simply provide a URI to identify the assertion= format and include it using the grant_type parameter. No additional parame= ters needed. 2. SAML bearer assertion grant type document [2] which provides the wrap_as= sertion parameter functionality via the assertion parameter. The assertion = parameter is defined in the context of the SAML extension, but is registere= d as a general purpose parameter and available for any future assertion gra= nt types if they so desire. This thread (and open issue) is about a new (to WRAP and OAuth 2.0 pre -11)= client authentication method using assertions. It can be combined with the= WRAP functionality described above to produce requests with two separate a= ssertions (in the same request). The two functionalities has nothing to do = with one another except that both use assertions as each assertions serves = a completely different purpose (one for client authentication, and the othe= r for access authorization). Therefore, this is new functionality that was never discussed or suggested = before Yaron Goland proposal was submitted and added to -11 and later remov= ed in -12. And to prevent a broken record reply I'll add: both actions, tak= en by me, were done without working group consensus. So while adding and re= moving the section between -11 and -12 was not proper IETF editorial proces= s, the end result is nevertheless the same - the section is out of the docu= ment pending working group consensus for inclusion. EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.5 [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03 -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 19, 2011 11:59 AM To: Eran Hammer-Lahav Cc: David Recordon; oauth Subject: Re: [OAUTH-WG] Revised Section 3 On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote: -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 19, 2011 11:37 AM The feature described was in OAuth-WRAP which was a basis for OAuth 2.0. Can you please point me to where this feature was in WRAP? I can't find it. http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 ... or am I confused about what we are talking about changing in Section 3? --_000_C9D345C2110B7eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So your suggestions is t= o add something like 4.4.3 to 4.5? That sounds like a good idea.
=
Would that resolve the potential confusion here?
<= br>
EHL

From: Dick Hardt <dick.= hardt@gmail.com>
Date: T= ue, 19 Apr 2011 13:25:15 -0700
To: Eran Hammer-lahav <eran@hueni= verse.com>
Cc: "recordond@gmail.com" <recordond@gmail.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Revised Section 3

=
Th= anks for clarifying. Given how you have broken out Section 3 from the rest = of the flow, I missed 4.5.

It is not clear in 4.5 = that an access token is returned since in the previous sections, there is a= separate request and response section. What is the response supposed to lo= ok like when using an access token?  Some of the confusion here m= ay be that 4.5 is not as complete as the other sections.

-- Dick



On 20= 11-04-19, at 12:27 PM, Eran Hammer-Lahav wrote:

Yes, you are confused...=
WRAP section 5.2 defines an assertion authorization= grant type which is provided in OAuth 2.0 via two parts:
=
1. v2 extensible grant types [1], which provides the wrap_assertion_f= ormat parameter functionality. You simply provide a URI to identify the ass= ertion format and include it using the grant_type parameter. No additional = parameters needed.
2. SAML bearer assertion grant ty= pe document [2] which provides the wrap_assertion parameter functionality v= ia the assertion parameter. The assertion parameter is defined in the conte= xt of the SAML extension, but is registered as a general purpose parameter = and available for any future assertion grant types if they so desire.
=
This thread (and open issue) is about a new (to WRAP and = OAuth 2.0 pre -11) client authentication method using assertions. It can be= combined with the WRAP functionality described above to produce requests w= ith two separate assertions (in the same request). The two functionalities = has nothing to do with one another except that both use assertions as each = assertions serves a completely different purpose (one for client authentica= tion, and the other for access authorization).
There= fore, this is new functionality that was never discussed or suggested befor= e Yaron Goland proposal was submitted and added to -11 and later removed in= -12. And to prevent a broken record reply I'll add: both actions, taken by= me, were done without working group consensus. So while adding and removin= g the section between -11 and -12 was not proper IETF editorial process, th= e end result is nevertheless the same - the section is out of the document = pending working group consensus for inclusion.
EHL
-----Original Message-----
From: Di= ck Hardt [mailto:dick.hardt@gmail.c= om]
Sent: Tuesday, April 19, 2011 11:59 AM
To: Er= an Hammer-Lahav
Cc: David Recordon; oauth
Subject: Re= : [OAUTH-WG] Revised Section 3
On 2011-0= 4-19, at 11:41 AM, Eran Hammer-Lahav wrote:
-----Original Message-----
From: Dick Hardt [mailto:di= ck.hardt@gmail.com]
Sent: Tuesday, April 19, 2011 11:37 AM
The feature described was in OAuth-WRAP which was a basis for O= Auth
2.0.
Can you please point me to w= here this feature was in WRAP? I can't find it.
=
... or am I confused about what we are talking about chan= ging in Section 3?


<= /div>
 --_000_C9D345C2110B7eranhueniversecom_-- From dick.hardt@gmail.com Tue Apr 19 14:06:22 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 89896E0838 for ; Tue, 19 Apr 2011 14:06:22 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHMALA8AHN3E for ; Tue, 19 Apr 2011 14:06:21 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 206DAE0823 for ; Tue, 19 Apr 2011 14:06:21 -0700 (PDT) Received: by pzk30 with SMTP id 30so65943pzk.31 for ; Tue, 19 Apr 2011 14:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=Dwd5qrEJcbHhZhwdFsFmRA0gpUGr5hEBJ75xiyfUCDo=; b=qDO7WlEYuqmTY2G4bLPtiEtCzalL8uSG260/T4ePoJc7uXI+Qcwz8EQx1/ghyREdtP HmZbf+FgzvVQ28qlx2XK1kZXbkzAyFl8dZ8Q5ykU5CjbmIBfjUTBeKSgvVZ1UdSARTfB A6QFcDkkRHrHSk6vx+MVbnOUGotFsmBTBO4io= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=TsaOIgOmtLIOl6Wvojne4PLcZkYswcKnHr3Bp0XAl3QcDhi7IYF0MZUSufo9qJ2LU5 BeFBC25vSxBWzdvabmP2wdnIKUpVAnIciqat1LCHAuUSOzfTCQqRkhqNrt4cj9plu4DP UjY7tPo56G2qM21Ia3Vv90HjZI4FwlkBZQrO0= Received: by 10.68.25.101 with SMTP id b5mr9238292pbg.134.1303247179584; Tue, 19 Apr 2011 14:06:19 -0700 (PDT) Received: from [192.168.1.16] (c-24-5-83-209.hsd1.ca.comcast.net [24.5.83.209]) by mx.google.com with ESMTPS id n7sm166703pbi.2.2011.04.19.14.06.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 14:06:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-65-669944538 From: Dick Hardt In-Reply-To: Date: Tue, 19 Apr 2011 14:06:15 -0700 Message-Id: <0DA423F6-B895-458B-97AE-99299FBA1B0A@gmail.com> References: To: Eran Hammer-Lahav , Anthony Nadalin X-Mailer: Apple Mail (2.1084) Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 19 Apr 2011 21:06:22 -0000 --Apple-Mail-65-669944538 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Resolves *my* confusion. :) Tony: apologies if you covered this in earlier posts, but if 4.5 does = not solve your use case, would you clarify what else is needed? Are you = unhappy that it is labeled an extension? -- Dick On 2011-04-19, at 2:00 PM, Eran Hammer-Lahav wrote: > So your suggestions is to add something like 4.4.3 to 4.5? That sounds = like a good idea. >=20 > Would that resolve the potential confusion here? >=20 > EHL >=20 > From: Dick Hardt > Date: Tue, 19 Apr 2011 13:25:15 -0700 > To: Eran Hammer-lahav > Cc: "recordond@gmail.com" , oauth = > Subject: Re: [OAUTH-WG] Revised Section 3 >=20 >> Thanks for clarifying. Given how you have broken out Section 3 from = the rest of the flow, I missed 4.5. >>=20 >> It is not clear in 4.5 that an access token is returned since in the = previous sections, there is a separate request and response section. = What is the response supposed to look like when using an access token? = Some of the confusion here may be that 4.5 is not as complete as the = other sections. >>=20 >> -- Dick >>=20 >>=20 >>=20 >> On 2011-04-19, at 12:27 PM, Eran Hammer-Lahav wrote: >>=20 >>> Yes, you are confused... >>> WRAP section 5.2 defines an assertion authorization grant type which = is provided in OAuth 2.0 via two parts: >>> 1. v2 extensible grant types [1], which provides the = wrap_assertion_format parameter functionality. You simply provide a URI = to identify the assertion format and include it using the grant_type = parameter. No additional parameters needed. >>> 2. SAML bearer assertion grant type document [2] which provides the = wrap_assertion parameter functionality via the assertion parameter. The = assertion parameter is defined in the context of the SAML extension, but = is registered as a general purpose parameter and available for any = future assertion grant types if they so desire. >>> This thread (and open issue) is about a new (to WRAP and OAuth 2.0 = pre -11) client authentication method using assertions. It can be = combined with the WRAP functionality described above to produce requests = with two separate assertions (in the same request). The two = functionalities has nothing to do with one another except that both use = assertions as each assertions serves a completely different purpose (one = for client authentication, and the other for access authorization). >>> Therefore, this is new functionality that was never discussed or = suggested before Yaron Goland proposal was submitted and added to -11 = and later removed in -12. And to prevent a broken record reply I'll add: = both actions, taken by me, were done without working group consensus. So = while adding and removing the section between -11 and -12 was not proper = IETF editorial process, the end result is nevertheless the same - the = section is out of the document pending working group consensus for = inclusion. >>> EHL >>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.5 >>> [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03 >>>> -----Original Message----- >>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>>> Sent: Tuesday, April 19, 2011 11:59 AM >>>> To: Eran Hammer-Lahav >>>> Cc: David Recordon; oauth >>>> Subject: Re: [OAUTH-WG] Revised Section 3 >>>> On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote: >>>>>> -----Original Message----- >>>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>>>>> Sent: Tuesday, April 19, 2011 11:37 AM >>>>>> The feature described was in OAuth-WRAP which was a basis for = OAuth >>>> 2.0. >>>>> Can you please point me to where this feature was in WRAP? I can't = find it. >>>> http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 >>>> ... or am I confused about what we are talking about changing in = Section 3? >>=20 >>=20 --Apple-Mail-65-669944538 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
So your suggestions is to = add something like 4.4.3 to 4.5? That sounds like a good = idea.

Would that resolve the potential = confusion here?

EHL

From: = Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 19 Apr 2011 13:25:15 = -0700
To: Eran Hammer-lahav = <eran@hueniverse.com>
Cc: "recordond@gmail.com" <recordond@gmail.com>, oauth = <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Revised = Section 3

Thanks for clarifying. Given how you have = broken out Section 3 from the rest of the flow, I missed = 4.5.

It is not clear in 4.5 that an access = token is returned since in the previous sections, there is a separate = request and response section. What is the response supposed to look like = when using an access token?  Some of the confusion here may be = that 4.5 is not as complete as the other = sections.

-- = Dick



On = 2011-04-19, at 12:27 PM, Eran Hammer-Lahav = wrote:

Yes, you = are confused...
WRAP section 5.2 defines an = assertion authorization grant type which is provided in OAuth 2.0 via = two parts:
1. v2 extensible grant types [1], = which provides the wrap_assertion_format parameter functionality. You = simply provide a URI to identify the assertion format and include it = using the grant_type parameter. No additional parameters = needed.
2. SAML bearer assertion grant type = document [2] which provides the wrap_assertion parameter functionality = via the assertion parameter. The assertion parameter is defined in the = context of the SAML extension, but is registered as a general purpose = parameter and available for any future assertion grant types if they so = desire.
This thread (and open issue) is about a = new (to WRAP and OAuth 2.0 pre -11) client authentication method using = assertions. It can be combined with the WRAP functionality described = above to produce requests with two separate assertions (in the same = request). The two functionalities has nothing to do with one another = except that both use assertions as each assertions serves a completely = different purpose (one for client authentication, and the other for = access authorization).
Therefore, this is new = functionality that was never discussed or suggested before Yaron Goland = proposal was submitted and added to -11 and later removed in -12. And to = prevent a broken record reply I'll add: both actions, taken by me, were = done without working group consensus. So while adding and removing the = section between -11 and -12 was not proper IETF editorial process, the = end result is nevertheless the same - the section is out of the document = pending working group consensus for inclusion.
= EHL
=
-----Original Message-----
From: Dick = Hardt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, April 19, 2011 11:59 AM
To: Eran = Hammer-Lahav
Cc: David Recordon; oauth
Subject: = Re: [OAUTH-WG] Revised Section 3
On = 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote:
=
= -----Original Message-----
From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, April 19, 2011 11:37 AM
=
The feature described was in OAuth-WRAP which was a = basis for OAuth
= 2.0.
Can you please point me to where this = feature was in WRAP? I can't find it.
=
=
... or am I confused about what we are talking about = changing in Section = 3?



= --Apple-Mail-65-669944538-- From melinda.shore@gmail.com Tue Apr 19 16:29:30 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0FDC4E07E1 for ; Tue, 19 Apr 2011 16:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24B9u1BHw99k for ; Tue, 19 Apr 2011 16:29:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 2C808E075C for ; Tue, 19 Apr 2011 16:29:29 -0700 (PDT) Received: by vws12 with SMTP id 12so186163vws.31 for ; Tue, 19 Apr 2011 16:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=0Arsnt8i2Bns8gS+ofJcZ69UZaeQPaQAxUveDNriVa4=; b=hHNL9ndCuooO+AHyyFf85DBIE7uxDrJmoudRvSWAsOcyuJ+Pd+jDg6+MwKMcjakPIq gLLgJaRDLLBXZjiSfKCJEZ9+Gi0YSVHX2QfspZ0vJOgh4GAxHLRduS7DOeD0XUtYBWaB 5apJOj1Xc3DQwDfu2yxTKircgcP3KA2zS8tiU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NZEC87FKyqMo2Fg0VZn4xprj/Zu5wCFemwaDZqJH911QG/N4DDP5u8rcPKqcBoWI2T tLQmKzoWqIMWU+kJNlP2iPttv/PkgT2pZ3xXQZlWFKGh9mW4p3X1cX4BUINpJXgdwErF jyPFiE3HQSE4J6jdU9tlfbI6R00sEWcZPTc9g= MIME-Version: 1.0 Received: by 10.52.109.73 with SMTP id hq9mr3212180vdb.215.1303255767567; Tue, 19 Apr 2011 16:29:27 -0700 (PDT) Received: by 10.220.19.21 with HTTP; Tue, 19 Apr 2011 16:29:27 -0700 (PDT) Date: Tue, 19 Apr 2011 15:29:27 -0800 Message-ID: From: Melinda Shore To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Use cases document review 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, 19 Apr 2011 23:29:30 -0000 At the oauth session at IETF 80, I volunteered to review the use cases document (draft-zeltsan-oauth-use-cases). Overall I liked the document a lot and thought the structure (pre- conditions, post-conditions, requirements) was excellent. I do wonder if the post-conditions aren't somewhat overly focused on process rather than state in many cases ("Alice's browser downloads a script [ ... ]"), but that may be a terminological question around "post-conditions" rather than much to do with actual content. I also think that it may help to identify which requirements are in-scope for the working group and which are not. For example, in 3.11 "The server at www.social.example.com must be able to redirect Alice's browser to www.sipservice.example.com" is clearly out-of-scope for oauth, but "The application running at www.sipservice.example.com must be capable of authenticating Alice and obtaining her authorization of a request from www.social.example.com" is not, or at least both the authn and authz steps may not be, and that would benefit from clarification. And come to think of it, that's a pretty good example of a case where the distinction between "pre-condition" and requirement isn't all that clear. Individual sections: 3.1 I thought the discussion of token lifetime was a bit muddled. I think it's probably sufficient to say that expired tokens may be reissued and that it is possible, when appropriate, to issue relatively long-lived tokens. 3.2 I didn't understand the second bullet item under "pre-conditions." I tried substituting both "not" and "now" for "no" and neither of them worked all that well. 3.11 I think "The application at www.social.example.com must be able to translate the messages of the Alice's VoIP applet into SIP and RTP messages" is almost certainly irrelevant. 3.12 I'm insufficiently familiar with XRD to know if it protects private patient data sufficiently to satisfy HIPPA and other legal requirements. The discovery component of this seems dicey and can probably be addressed in a less touchy scenario. If this document is to provide guidance during the development of protocol documents, I'm not sure it's worth the effort to sort out pre- conditions and requirements, although I do think I'd try to put some effort into identifying what's going to be done by the working group and what's not. Overall I think it's an extremely useful document. Melinda From tonynad@microsoft.com Wed Apr 20 16:05:13 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 230A7E07C1 for ; Wed, 20 Apr 2011 16:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WpjOlsCjcoV for ; Wed, 20 Apr 2011 16:05:08 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id 0E7B2E07B6 for ; Wed, 20 Apr 2011 16:05:08 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 20 Apr 2011 16:05:07 -0700 Received: from TX2EHSOBE001.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 20 Apr 2011 16:05:07 -0700 Received: from mail43-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.8; Wed, 20 Apr 2011 23:05:06 +0000 Received: from mail43-tx2 (localhost.localdomain [127.0.0.1]) by mail43-tx2-R.bigfish.com (Postfix) with ESMTP id 2737414380F5 for ; Wed, 20 Apr 2011 23:05:06 +0000 (UTC) X-SpamScore: -48 X-BigFish: PS-48(zzbb2cK936eK9371O148cM542M98dKzzdafM1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT007.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail43-tx2 (localhost.localdomain [127.0.0.1]) by mail43-tx2 (MessageSwitch) id 1303340705152046_5147; Wed, 20 Apr 2011 23:05:05 +0000 (UTC) Received: from TX2EHSMHS046.bigfish.com (unknown [10.9.14.244]) by mail43-tx2.bigfish.com (Postfix) with ESMTP id 204A215E004E; Wed, 20 Apr 2011 23:05:05 +0000 (UTC) Received: from CH1PRD0302HT007.namprd03.prod.outlook.com (207.46.198.24) by TX2EHSMHS046.bigfish.com (10.9.99.146) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 20 Apr 2011 23:05:04 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.79]) by CH1PRD0302HT007.namprd03.prod.outlook.com ([10.28.29.126]) with mapi id 14.01.0225.042; Wed, 20 Apr 2011 23:05:04 +0000 From: Anthony Nadalin To: Dick Hardt , Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAB2/gYAAA7I5gAADPdkAAAF71YAAAvT6gAABnOkAAAAhFQAAAJ1bAAABBRIAAAIBpIAAATynAAAAMeuAACk2iiA= Date: Wed, 20 Apr 2011 23:05:02 +0000 Message-ID: References: <0DA423F6-B895-458B-97AE-99299FBA1B0A@gmail.com> In-Reply-To: <0DA423F6-B895-458B-97AE-99299FBA1B0A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.165] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E71A47AEE5CH1PRD0302MB115_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT007.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 20 Apr 2011 23:05:13 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A47AEE5CH1PRD0302MB115_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So here is what I currently understand, I'm sure that I have some of this w= rong; 1. At the Prague meeting the general issue of Client Credentials remo= val from document was brought up, Thomas took the action item from the meet= ing to redraft the section that was removed. Thomas provided that. What Tho= mas provided is a replacement for the current section 3 in the latest draft= . 2. As Eran points out there are several parts to this issue, 1st issu= e is the thread going back to Yaron's text proposal ( http://www.ietf.org/m= ail-archive/web/oauth/current/msg03363.html ) which was added and then remo= ved (which were both done w/o consensus) which is authenticating with a acc= ess token request with two assertions, one from the client and one from the= resource owner, the 2nd part is about authentication with id and secret an= d the 3rd part is about authentication with assertion. 3. The replacement Section 3 introduces the notion client identity an= d authentication and provides a means to specify a client identity and secr= et used for authentication and also provided is a means for client authenti= cation using assertions (such as SAML). I believe the way the replacement s= ection 3 is worded it would solve the issue that Yaron was trying to solve = and a extension could be posible. 4. So with the current text in section 3 and section 4.5 we can't do = 2 assertions since it uses grant_type=3Dassertion. So I'm not sure that an = extension based upon the current draft would help solve the problem. So a possible issue would be if you added something like 4.4.3 to 4.5 the e= xtension would have to conform to this, do we expect all extensions to defi= ne this in the way they want? From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 19, 2011 2:06 PM To: Eran Hammer-Lahav; Anthony Nadalin Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 Resolves *my* confusion. :) Tony: apologies if you covered this in earlier posts, but if 4.5 does not s= olve your use case, would you clarify what else is needed? Are you unhappy = that it is labeled an extension? -- Dick On 2011-04-19, at 2:00 PM, Eran Hammer-Lahav wrote: So your suggestions is to add something like 4.4.3 to 4.5? That sounds like= a good idea. Would that resolve the potential confusion here? EHL From: Dick Hardt > Date: Tue, 19 Apr 2011 13:25:15 -0700 To: Eran Hammer-lahav > Cc: "recordond@gmail.com" >, oauth > Subject: Re: [OAUTH-WG] Revised Section 3 Thanks for clarifying. Given how you have broken out Section 3 from the res= t of the flow, I missed 4.5. It is not clear in 4.5 that an access token is returned since in the previo= us sections, there is a separate request and response section. What is the = response supposed to look like when using an access token? Some of the con= fusion here may be that 4.5 is not as complete as the other sections. -- Dick On 2011-04-19, at 12:27 PM, Eran Hammer-Lahav wrote: Yes, you are confused... WRAP section 5.2 defines an assertion authorization grant type which is pro= vided in OAuth 2.0 via two parts: 1. v2 extensible grant types [1], which provides the wrap_assertion_format = parameter functionality. You simply provide a URI to identify the assertion= format and include it using the grant_type parameter. No additional parame= ters needed. 2. SAML bearer assertion grant type document [2] which provides the wrap_as= sertion parameter functionality via the assertion parameter. The assertion = parameter is defined in the context of the SAML extension, but is registere= d as a general purpose parameter and available for any future assertion gra= nt types if they so desire. This thread (and open issue) is about a new (to WRAP and OAuth 2.0 pre -11)= client authentication method using assertions. It can be combined with the= WRAP functionality described above to produce requests with two separate a= ssertions (in the same request). The two functionalities has nothing to do = with one another except that both use assertions as each assertions serves = a completely different purpose (one for client authentication, and the othe= r for access authorization). Therefore, this is new functionality that was never discussed or suggested = before Yaron Goland proposal was submitted and added to -11 and later remov= ed in -12. And to prevent a broken record reply I'll add: both actions, tak= en by me, were done without working group consensus. So while adding and re= moving the section between -11 and -12 was not proper IETF editorial proces= s, the end result is nevertheless the same - the section is out of the docu= ment pending working group consensus for inclusion. EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.5 [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03 -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 19, 2011 11:59 AM To: Eran Hammer-Lahav Cc: David Recordon; oauth Subject: Re: [OAUTH-WG] Revised Section 3 On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote: -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 19, 2011 11:37 AM The feature described was in OAuth-WRAP which was a basis for OAuth 2.0. Can you please point me to where this feature was in WRAP? I can't find it. http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 ... or am I confused about what we are talking about changing in Section 3? --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A47AEE5CH1PRD0302MB115_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So here is what I current= ly understand, I’m sure that I have some of this wrong;

 <= /p>

1. = ;      At the Prague mee= ting the general issue of Client Credentials removal from document was brou= ght up, Thomas took the action item from the meeting to redraft the section that was removed. Thomas provided that. What Thomas pr= ovided is a replacement for the current section 3 in the latest draft.=

2. = ;      As Eran points ou= t there are several parts to this issue, 1st issue is the thread= going back to Yaron’s text proposal ( http://www.ietf.org/mail-archive/web/oauth/current/msg03363.html ) wh= ich was added and then removed (which were both done w/o consensus) which i= s authenticating with a access token request with two assertions, one from the client and one from the resource= owner, the 2nd part is about authentication with id and secret and the 3rd= part is about authentication with assertion.

3. = ;      The replacement S= ection 3 introduces the notion client identity and authentication and provi= des a means to specify a client identity and secret used for authentication and also provided is a means for client authentication = using assertions (such as SAML). I believe the way the replacement section = 3 is worded it would solve the issue that Yaron was trying to solve and a e= xtension could be posible.

4. = ;      So with the curre= nt text in section 3 and section 4.5 we can’t do 2 assertions since i= t uses grant_type=3Dassertion. So I’m not sure that an extension based upon the current draft would help solve the problem.

 <= /p>

So a possible issue would= be if you added something like 4.4.3 to 4.5 the extension would have to co= nform to this, do we expect all extensions to define this in the way they want?

 <= /p>

From: Dick Har= dt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, April 19, 2011 2:06 PM
To: Eran Hammer-Lahav; Anthony Nadalin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

 

Resolves *my* confusion. :)

 

Tony: apologies if you covered this in earlier posts= , but if 4.5 does not solve your use case, would you clarify what else is n= eeded? Are you unhappy that it is labeled an extension?

 

-- Dick

 

On 2011-04-19, at 2:00 PM, Eran Hammer-Lahav wrote:<= o:p>



So your suggestions is to a= dd something like 4.4.3 to 4.5? That sounds like a good idea.

 

Would that resolve the pote= ntial confusion here?

 

EHL

 

From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 19 Apr 2011 13:25:15 -0700
To: Eran Hammer-lahav <era= n@hueniverse.com>
Cc: "recordond@gmail.com= " <recordond@gmail.com>, oauth <oauth@ietf.org><= br> Subject: Re: [OAUTH-WG] Revised Section 3

 

Thanks for clarifying. Give= n how you have broken out Section 3 from the rest of the flow, I missed 4.5= .

 

It is not clear in 4.5 that= an access token is returned since in the previous sections, there is a sep= arate request and response section. What is the response supposed to look like when using an access token?  Some of the c= onfusion here may be that 4.5 is not as complete as the other sections.

 

-- Dick

 

 

 

On 2011-04-19, at 12:27 PM,= Eran Hammer-Lahav wrote:

 

Yes, you are confused...

WRAP section 5.2 defines an= assertion authorization grant type which is provided in OAuth 2.0 via two = parts:

1. v2 extensible grant type= s [1], which provides the wrap_assertion_format parameter functionality. Yo= u simply provide a URI to identify the assertion format and include it using the grant_type parameter. No additional parameters ne= eded.

2. SAML bearer assertion gr= ant type document [2] which provides the wrap_assertion parameter functiona= lity via the assertion parameter. The assertion parameter is defined in the context of the SAML extension, but is registered as a ge= neral purpose parameter and available for any future assertion grant types = if they so desire.

This thread (and open issue= ) is about a new (to WRAP and OAuth 2.0 pre -11) client authentication meth= od using assertions. It can be combined with the WRAP functionality described above to produce requests with two separate assertions (in the s= ame request). The two functionalities has nothing to do with one another ex= cept that both use assertions as each assertions serves a completely differ= ent purpose (one for client authentication, and the other for access authorization).

Therefore, this is new func= tionality that was never discussed or suggested before Yaron Goland proposa= l was submitted and added to -11 and later removed in -12. And to prevent a broken record reply I'll add: both actions, taken by me, = were done without working group consensus. So while adding and removing the= section between -11 and -12 was not proper IETF editorial process, the end= result is nevertheless the same - the section is out of the document pending working group consensus for i= nclusion.

EHL

-----Original Message-----<= o:p>

From: Dick Hardt [mailto:dick.hardt@gmail.com]

Sent: Tuesday, April 19, 20= 11 11:59 AM

To: Eran Hammer-Lahav<= /o:p>

Cc: David Recordon; oauth

Subject: Re: [OAUTH-WG] Rev= ised Section 3

On 2011-04-19, at 11:41 AM,= Eran Hammer-Lahav wrote:

-----Original Message-----<= o:p>

From: Dick Hardt [mailto:dick.hardt@gmail.com]

Sent: Tuesday, April 19, 20= 11 11:37 AM

The feature described was i= n OAuth-WRAP which was a basis for OAuth

2.0.

Can you please point me to = where this feature was in WRAP? I can't find it.

... or am I confused about = what we are talking about changing in Section 3?

 

 

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E71A47AEE5CH1PRD0302MB115_-- From eran@hueniverse.com Wed Apr 20 16:52:55 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E3922E06E2 for ; Wed, 20 Apr 2011 16:52:55 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTiHNMUIcheB for ; Wed, 20 Apr 2011 16:52:53 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 84B08E0673 for ; Wed, 20 Apr 2011 16:52:53 -0700 (PDT) Received: (qmail 24520 invoked from network); 20 Apr 2011 23:52:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Apr 2011 23:52:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 20 Apr 2011 16:52:31 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , Dick Hardt Date: Wed, 20 Apr 2011 16:52:24 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv/tgLvT9ardZESRV+Dl99pE/Dspg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9D4B8CF112FFeranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 20 Apr 2011 23:52:56 -0000 --_000_C9D4B8CF112FFeranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I had a hard time following some of this but I=92ll try to clarify. From: Anthony Nadalin > Date: Wed, 20 Apr 2011 16:05:02 -0700 To: Dick Hardt >, Eran Ha= mmer-lahav > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Revised Section 3 So here is what I currently understand, I=92m sure that I have some of this= wrong; 1. At the Prague meeting the general issue of Client Credentials remo= val from document was brought up, Thomas took the action item from the meet= ing to redraft the section that was removed. Thomas provided that. What Tho= mas provided is a replacement for the current section 3 in the latest draft= . 2. As Eran points out there are several parts to this issue, 1st issu= e is the thread going back to Yaron=92s text proposal ( http://www.ietf.org= /mail-archive/web/oauth/current/msg03363.html ) which was added and then re= moved (which were both done w/o consensus) which is authenticating with a a= ccess token request with two assertions, one from the client and one from t= he resource owner This is the only requirement driving this open issue. The new proposed text= does not change any other normative part of v2. One additional note is that this doesn't mean the client has to use two ass= ertions, but that there are two assertions and each serves a different purp= ose (authenticate the client, denote the resource owner authorization). the 2nd part is about authentication with id and secret I assume you are referring to the client password credentials section? and the 3rd part is about authentication with assertion. Not sure what you mean here, but if you mean authenticating a client using = an assertion, that's already covered by the first part. If you mean using a= n assertion as the resource owner authorization, that's covered by 4.5 and = the 'assertion' extension parameter. 3. The replacement Section 3 introduces the notion client identity an= d authentication and provides a means to specify a client identity and secr= et used for authentication and also provided is a means for client authenti= cation using assertions (such as SAML). The replacement only adds the assertion part. The rest is already in v2. Th= e new text includes some other useful prose, but that's purely editorial. I believe the way the replacement section 3 is worded it would solve the is= sue that Yaron was trying to solve and a extension could be posible. True, in that it bring's Yaron's proposal back practically unchanged (norma= tive language wise). 4. So with the current text in section 3 and section 4.5 we can=92t d= o 2 assertions True to the extent it doesn't specify it. since it uses grant_type=3Dassertion. Nothing uses that. The 'assertion' grant type has been replaced with a more= generic extension mechanism. Basically, we combined the 'grant_type' and '= assertion_type' parameters into a single extension point. So what was previ= ously sent like this: grant_type=3Dassertion&assertion_type=3Dhttp://some.assertion.type.uri Is now send as: grant_type=3Dhttp://some.assertion.type.uri This change was made in =9612 with WG consensus. At the time, the 'assertio= n' parameter was relocated to the SAML draft. So I=92m not sure that an extension based upon the current draft would help= solve the problem. An extension grant type (which is the mechanism used by the SAML draft) wil= l not be suitable here. This use care requires defining a new way to authen= tication HTTP requests (traditional client authentication) using assertions= , similar to how Basic is used to authenticate requests using a username an= d password. So a possible issue would be if you added something like 4.4.3 to 4.5 the e= xtension would have to conform to this, do we expect all extensions to defi= ne this in the way they want? Adding 4.4.3-like text to 4.5 does not have *any* normative implications. S= ection 4.5 provides an extension point to the token endpoint. Section 4.4.3= merely states the obvious in how responses to token requests are handled. = Adding it will be done purely for clarity. So I agree that the current specification doesn't address the use case of u= sing an assertion to authenticate the client. Beyond that we disagree on ev= erything else related to how to address it. EHL From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 19, 2011 2:06 PM To: Eran Hammer-Lahav; Anthony Nadalin Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 Resolves *my* confusion. :) Tony: apologies if you covered this in earlier posts, but if 4.5 does not s= olve your use case, would you clarify what else is needed? Are you unhappy = that it is labeled an extension? -- Dick On 2011-04-19, at 2:00 PM, Eran Hammer-Lahav wrote: So your suggestions is to add something like 4.4.3 to 4.5? That sounds like= a good idea. Would that resolve the potential confusion here? EHL From: Dick Hardt > Date: Tue, 19 Apr 2011 13:25:15 -0700 To: Eran Hammer-lahav > Cc: "recordond@gmail.com" >, oauth > Subject: Re: [OAUTH-WG] Revised Section 3 Thanks for clarifying. Given how you have broken out Section 3 from the res= t of the flow, I missed 4.5. It is not clear in 4.5 that an access token is returned since in the previo= us sections, there is a separate request and response section. What is the = response supposed to look like when using an access token? Some of the con= fusion here may be that 4.5 is not as complete as the other sections. -- Dick On 2011-04-19, at 12:27 PM, Eran Hammer-Lahav wrote: Yes, you are confused... WRAP section 5.2 defines an assertion authorization grant type which is pro= vided in OAuth 2.0 via two parts: 1. v2 extensible grant types [1], which provides the wrap_assertion_format = parameter functionality. You simply provide a URI to identify the assertion= format and include it using the grant_type parameter. No additional parame= ters needed. 2. SAML bearer assertion grant type document [2] which provides the wrap_as= sertion parameter functionality via the assertion parameter. The assertion = parameter is defined in the context of the SAML extension, but is registere= d as a general purpose parameter and available for any future assertion gra= nt types if they so desire. This thread (and open issue) is about a new (to WRAP and OAuth 2.0 pre -11)= client authentication method using assertions. It can be combined with the= WRAP functionality described above to produce requests with two separate a= ssertions (in the same request). The two functionalities has nothing to do = with one another except that both use assertions as each assertions serves = a completely different purpose (one for client authentication, and the othe= r for access authorization). Therefore, this is new functionality that was never discussed or suggested = before Yaron Goland proposal was submitted and added to -11 and later remov= ed in -12. And to prevent a broken record reply I'll add: both actions, tak= en by me, were done without working group consensus. So while adding and re= moving the section between -11 and -12 was not proper IETF editorial proces= s, the end result is nevertheless the same - the section is out of the docu= ment pending working group consensus for inclusion. EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.5 [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03 -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 19, 2011 11:59 AM To: Eran Hammer-Lahav Cc: David Recordon; oauth Subject: Re: [OAUTH-WG] Revised Section 3 On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote: -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 19, 2011 11:37 AM The feature described was in OAuth-WRAP which was a basis for OAuth 2.0. Can you please point me to where this feature was in WRAP? I can't find it. http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 ... or am I confused about what we are talking about changing in Section 3? --_000_C9D4B8CF112FFeranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I had a hard time following some of this but I=92ll try to clarify.<= /span>

  

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Wed, 20 Apr 2011 16:05:02 -0700
To: Dick Hardt <dick.hardt@gmail.com>, Eran Hammer-lahav <eran@hueniverse.com>
Cc: OAuth WG <oauth@ietf.org>
Subject: <= /span> RE: [OAUTH-WG] Revised Section 3

So here is what I currently understand, I=92m sure that I have some = of this wrong;

1.       At the Prague meeting the general is= sue of Client Credentials removal from document was brought up, Thomas took= the action item from the meeting to redraft the section that was removed. Thomas provided that. What Thomas pr= ovided is a replacement for the current section 3 in the latest draft.=

2. &nb= sp;     As Eran points out there are several= parts to this issue, 1st issue is the thread going back to Yaro= n=92s text proposal ( http://www.ietf.org/mail-archive/web/oauth/current/msg03363.html ) wh= ich was added and then removed (which were both done w/o consensus) which i= s authenticating with a access token request with two assertions, one from the client and one from the resource= owner


=

This is the= only requirement driving this open issue. The new proposed text does not c= hange any other normative part of v2.


One additional note is that this d= oesn't mean the client has to use two assertions, but that there are two as= sertions and each serves a different purpose (authenticate the client, deno= te the resource owner authorization).

 

<= div class=3D"WordSection1">

the 2nd part is about= authentication with id and secret


I assume you are referring to the client passwo= rd credentials section?

and the 3rd part is about authenticat= ion with assertion.

Not sure what you mean here, but if you mean authenticating a = client using an assertion, that's already covered by the first part. If you= mean using an assertion as the resource owner authorization, that's covere= d by 4.5 and the 'assertion' extension parameter.

<= /span>

3.  &nbs= p;    The replacement Section 3 introduces= the notion client identity and authentication and provides a means to spec= ify a client identity and secret used for authentication and also provided is a means for client authentication = using assertions (such as SAML).

<= /span>

The replacement only adds the assertion part. The= rest is already in v2. The new text includes some other useful prose, but = that's purely editorial.

I believe the way the replacement se= ction 3 is worded it would solve the issue that Yaron was trying to solve a= nd a extension could be posible.

<= /span>

True, in that it bring's Yaron's proposal back pr= actically unchanged (normative language wise).

4= .   &= nbsp;   So with the current text in section = 3 and section 4.5 we can=92t do 2 assertions


True to the extent it doesn't specify= it.

since it uses grant_type=3Dassertion.


Nothing uses that. The= 'assertion' grant type has been replaced with a more generic extension mec= hanism. Basically, we combined the 'grant_type' and 'assertion_type' parame= ters into a single extension point. So what was previously sent like this:<= /div>

grant_type=3Dassertion&assertion_type=3Dhttp:/= /some.assertion.type.uri

Is now send as:

grant_type=3Dhttp://some.assertion.type.uri 

This change was made in =9612 with WG consensus. At the tim= e, the 'assertion' parameter was relocated to the SAML draft.

= So I=92m not sure that an extension based upon the current draft would help solve the problem.


An extension grant typ= e (which is the mechanism used by the SAML draft) will not be suitable here= . This use care requires defining a new way to authentication HTTP requests= (traditional client authentication) using assertions, similar to how Basic= is used to authenticate requests using a username and password.
=

= So a possible issue would be if you added something like = 4.4.3 to 4.5 the extension would have to conform to this, do we expect all = extensions to define this in the way they want?&= nbsp;


A= dding 4.4.3-like text to 4.5 does not have *any* normative implications. Se= ction 4.5 provides an extension point to the token endpoint. Section 4.4.3 = merely states the obvious in how responses to token requests are handled. A= dding it will be done purely for clarity.

So I agr= ee that the current specification doesn't address the use case of using an = assertion to authenticate the client. Beyond that we disagree on everything= else related to how to address it.

EHL
=

From: Dick Hardt [mail= to:dick.hardt@gmail.com]
Sent: Tuesday, April 19, 2011 2:06 PM
To: Eran Hammer-= Lahav; Anthony Nadalin
Cc: OAuth WG
Subject: Re: [OAUTH= -WG] Revised Section 3

 

Resolves *my* confusion. :)=

 

=

Tony: apologies if you covered this in earlier = posts, but if 4.5 does not solve your use case, would you clarify what else= is needed? Are you unhappy that it is labeled an extension?

=

 

-- Dick

 

On 2011-04-19, at 2:00 P= M, Eran Hammer-Lahav wrote:


=

So your sugges= tions is to add something like 4.4.3 to 4.5? That sounds like a good idea.<= o:p>

 =

Would that reso= lve the potential confusion here?

 

EHL

 

From: Dick Hardt <di= ck.hardt@gmail.com>
Date: Tue, 19 Apr 2011 13:25:15 -0700<= br>To: Eran Hammer-lahav <= eran@hueniverse.com>
Cc: "recordond@gmail.com" <recordond@gmail.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Revised Se= ction 3

 

Thanks for clarifying. Given how you have broken ou= t Section 3 from the rest of the flow, I missed 4.5.

<= /div>

 

It is not clear in 4.5 that an access= token is returned since in the previous sections, there is a separate requ= est and response section. What is the response supposed to look like when using an access token?  Some of the c= onfusion here may be that 4.5 is not as complete as the other sections.

 

-- Dick=

 

 <= /p>

 

<= /div>

On 2011-04-19, at 12:27 PM, Eran = Hammer-Lahav wrote:

=  

Yes, you are confused...

WRAP section 5.2 defines an assertio= n authorization grant type which is provided in OAuth 2.0 via two parts:

1. v2 extensi= ble grant types [1], which provides the wrap_assertion_format parameter fun= ctionality. You simply provide a URI to identify the assertion format and include it using the grant_type parameter. No additional parameters ne= eded.

2. SA= ML bearer assertion grant type document [2] which provides the wrap_asserti= on parameter functionality via the assertion parameter. The assertion param= eter is defined in the context of the SAML extension, but is registered as a ge= neral purpose parameter and available for any future assertion grant types = if they so desire.

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri, sans-s= erif; ">This thread (and open issue) is about a new (to WRAP and OAuth 2.0 = pre -11) client authentication method using assertions. It can be combined = with the WRAP functionality described above to produce requests with two separate assertions (in the s= ame request). The two functionalities has nothing to do with one another ex= cept that both use assertions as each assertions serves a completely differ= ent purpose (one for client authentication, and the other for access authorization).

<= p class=3D"MsoNormal">Therefore, this is new functionality that wa= s never discussed or suggested before Yaron Goland proposal was submitted a= nd added to -11 and later removed in -12. And to prevent a broken record reply I'll add: both actions, taken by me, = were done without working group consensus. So while adding and removing the= section between -11 and -12 was not proper IETF editorial process, the end= result is nevertheless the same - the section is out of the document pending working group consensus for i= nclusion.

E= HL

-----= Original Message-----

Sent: Tuesday, April 19, 2011 11:59 AM

To: Eran Hammer-Lahav

Cc: David Recordon; = oauth

Subje= ct: Re: [OAUTH-WG] Revised Section 3

On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wro= te:

-----Original Message-----

From: Dick Hardt [mailto:dick.hardt@gmail.com]

Sent: Tuesday, April= 19, 2011 11:37 AM

The feature described was in OAuth= -WRAP which was a basis for OAuth

<= /blockquote>

2.0.

=

Can you plea= se point me to where this feature was in WRAP? I can't find it.<= /span>

... or am I confused about what = we are talking about changing in Section 3?

 

 

<= o:p> 

 --_000_C9D4B8CF112FFeranhueniversecom_-- From zachary.zeltsan@alcatel-lucent.com Thu Apr 21 01:35:56 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2AA25E0696 for ; Thu, 21 Apr 2011 01:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxOEuve4loHu for ; Thu, 21 Apr 2011 01:35:55 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id 1E210E0661 for ; Thu, 21 Apr 2011 01:35:55 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3L8ZrLW022556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Apr 2011 03:35:53 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3L8ZqaH006013 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Apr 2011 03:35:52 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 21 Apr 2011 03:35:52 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Melinda Shore'" , "oauth@ietf.org" Date: Thu, 21 Apr 2011 03:35:50 -0500 Thread-Topic: [OAUTH-WG] Use cases document review Thread-Index: Acv+6aNPi6fwnJzETYiioX/74mwdMgBFFl2g Message-ID: <5710F82C0E73B04FA559560098BF95B12507584EAE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [OAUTH-WG] Use cases document review 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, 21 Apr 2011 08:35:56 -0000 Melinda, Thank you for the review and feedback. We (the co-authors) have also received comments on the draft from Thomas (c= opied).=20 I plan to address all comments and respond by the end of the next week. Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= elinda Shore Sent: Tuesday, April 19, 2011 7:29 PM To: oauth@ietf.org Subject: [OAUTH-WG] Use cases document review At the oauth session at IETF 80, I volunteered to review the use cases document (draft-zeltsan-oauth-use-cases). Overall I liked the document a lot and thought the structure (pre- conditions, post-conditions, requirements) was excellent. I do wonder if the post-conditions aren't somewhat overly focused on process rather than state in many cases ("Alice's browser downloads a script [ ... ]"), but that may be a terminological question around "post-conditions" rather than much to do with actual content. I also think that it may help to identify which requirements are in-scope for the working group and which are not. For example, in 3.11 "The server at www.social.example.com must be able to redirect Alice's browser to www.sipservice.example.com" is clearly out-of-scope for oauth, but "The application running at www.sipservice.example.com must be capable of authenticating Alice and obtaining her authorization of a request from www.social.example.com" is not, or at least both the authn and authz steps may not be, and that would benefit from clarification. And come to think of it, that's a pretty good example of a case where the distinction between "pre-condition" and requirement isn't all that clear. Individual sections: 3.1 I thought the discussion of token lifetime was a bit muddled. I think it's probably sufficient to say that expired tokens may be reissued and that it is possible, when appropriate, to issue relatively long-lived tokens. 3.2 I didn't understand the second bullet item under "pre-conditions." I tried substituting both "not" and "now" for "no" and neither of them worked all that well. 3.11 I think "The application at www.social.example.com must be able to translate the messages of the Alice's VoIP applet into SIP and RTP messages" is almost certainly irrelevant. 3.12 I'm insufficiently familiar with XRD to know if it protects private patient data sufficiently to satisfy HIPPA and other legal requirements. The discovery component of this seems dicey and can probably be addressed in a less touchy scenario. If this document is to provide guidance during the development of protocol documents, I'm not sure it's worth the effort to sort out pre- conditions and requirements, although I do think I'd try to put some effort into identifying what's going to be done by the working group and what's not. Overall I think it's an extremely useful document. Melinda _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From d.tangren@gmail.com Thu Apr 21 09:26:36 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 341BEE068E for ; Thu, 21 Apr 2011 09:26:36 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPZIMDdghl4W for ; Thu, 21 Apr 2011 09:26:35 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfc.amsl.com (Postfix) with ESMTP id 7A52BE0663 for ; Thu, 21 Apr 2011 09:26:35 -0700 (PDT) Received: by gxk19 with SMTP id 19so625770gxk.31 for ; Thu, 21 Apr 2011 09:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=zuht1biKMRjOztIszJmCwm3YzP8fMP+HMkZ8WsrFAao=; b=I7DiEXQo2DLQVocmq5e155+SPP+36WqR7j5A33fsIgS5n85Ue587XFrKdh2kqAcM3X 2Llre/fOWHi+1WrPSjUIzwF9mhfPn0+cI+BpT8zOmkt/bfs/IyqR80qMU4mfg2hXogxJ ccrLMVGcREki9L8EU7qhIJE0U0IRRrATfvnTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=RorovmZ+6HjurUDeGsR5manZFtqZS7w3bbDld5yhPjJEQN+PH4UZb68UgCYjGOGTI/ 9r46q/wHasRZ/ITInJ77NpPRpsBe67dZZXekIX8iowp8AM5ozOW6iwpqsCjHwz00xqvn 9vlVqxdtpAOjPE0IyiggphEPbjb01KQqFvGm0= Received: by 10.91.199.6 with SMTP id b6mr621620agq.4.1303403194131; Thu, 21 Apr 2011 09:26:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.57.33 with HTTP; Thu, 21 Apr 2011 09:26:14 -0700 (PDT) From: Doug Tangren Date: Thu, 21 Apr 2011 12:26:14 -0400 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001636b42ece62a63104a170343a Subject: [OAUTH-WG] implicit clients and refresh tokens 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, 21 Apr 2011 16:26:36 -0000 --001636b42ece62a63104a170343a Content-Type: text/plain; charset=UTF-8 According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.2.2 it doesn't look like clients of the implicit oauth2 flow should receive a refreshing token although it looks like the access token can optionally have an expires_in time set. Does this mean there is no step for an implicit client to refresh their access token without involving the user again? According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-6 it looks like a client needs to send in the client credentials, including the client secret, to refresh an access token. This is a no-go for clients that can't securely secure a client secret like a web browser. Is providing no way for an implicit client to refresh an access token without involving the resource owner intended? -Doug Tangren http://lessis.me --001636b42ece62a63104a170343a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-= 4.2.2 it doesn't look like clients of the implicit oauth2 flow shou= ld receive a refreshing token although it looks like the access token can o= ptionally have an expires_in time set. Does this mean there is no step for = an implicit client to refresh their access token without involving the user= again?

According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-6 it looks like a client needs to send in the client credentials, includin= g the client secret, to refresh an access token. This is a no-go for client= s that can't securely secure a client secret like a web browser.

Is providing no way for an implicit client to refresh an access token w= ithout involving the resource owner intended?

-Doug Ta= ngren
http://lessis.me
--001636b42ece62a63104a170343a-- From eran@hueniverse.com Thu Apr 21 09:35:04 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9569AE0655 for ; Thu, 21 Apr 2011 09:35:04 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sehgf-yUnlqJ for ; Thu, 21 Apr 2011 09:35:03 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 99782E0663 for ; Thu, 21 Apr 2011 09:35:03 -0700 (PDT) Received: (qmail 23815 invoked from network); 21 Apr 2011 16:35:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Apr 2011 16:34:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 21 Apr 2011 09:34:40 -0700 From: Eran Hammer-Lahav To: Doug Tangren , "oauth@ietf.org" Date: Thu, 21 Apr 2011 09:34:32 -0700 Thread-Topic: [OAUTH-WG] implicit clients and refresh tokens Thread-Index: AcwAQO5CKpZ86sAdR1SK/Etg3Sop4QAAQU+A Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BBC48@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723447535BBC48P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] implicit clients and refresh tokens 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, 21 Apr 2011 16:35:04 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447535BBC48P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVwLg0KDQpFSEwNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEb3VnIFRhbmdyZW4NClNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAyMSwgMjAxMSA5OjI2IEFNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6 IFtPQVVUSC1XR10gaW1wbGljaXQgY2xpZW50cyBhbmQgcmVmcmVzaCB0b2tlbnMNCg0KQWNjb3Jk aW5nIHRvIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItMTUj c2VjdGlvbi00LjIuMiBpdCBkb2Vzbid0IGxvb2sgbGlrZSBjbGllbnRzIG9mIHRoZSBpbXBsaWNp dCBvYXV0aDIgZmxvdyBzaG91bGQgcmVjZWl2ZSBhIHJlZnJlc2hpbmcgdG9rZW4gYWx0aG91Z2gg aXQgbG9va3MgbGlrZSB0aGUgYWNjZXNzIHRva2VuIGNhbiBvcHRpb25hbGx5IGhhdmUgYW4gZXhw aXJlc19pbiB0aW1lIHNldC4gRG9lcyB0aGlzIG1lYW4gdGhlcmUgaXMgbm8gc3RlcCBmb3IgYW4g aW1wbGljaXQgY2xpZW50IHRvIHJlZnJlc2ggdGhlaXIgYWNjZXNzIHRva2VuIHdpdGhvdXQgaW52 b2x2aW5nIHRoZSB1c2VyIGFnYWluPw0KDQpBY2NvcmRpbmcgdG8gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi0xNSNzZWN0aW9uLTYgaXQgbG9va3MgbGlrZSBh IGNsaWVudCBuZWVkcyB0byBzZW5kIGluIHRoZSBjbGllbnQgY3JlZGVudGlhbHMsIGluY2x1ZGlu ZyB0aGUgY2xpZW50IHNlY3JldCwgdG8gcmVmcmVzaCBhbiBhY2Nlc3MgdG9rZW4uIFRoaXMgaXMg YSBuby1nbyBmb3IgY2xpZW50cyB0aGF0IGNhbid0IHNlY3VyZWx5IHNlY3VyZSBhIGNsaWVudCBz ZWNyZXQgbGlrZSBhIHdlYiBicm93c2VyLg0KDQpJcyBwcm92aWRpbmcgbm8gd2F5IGZvciBhbiBp bXBsaWNpdCBjbGllbnQgdG8gcmVmcmVzaCBhbiBhY2Nlc3MgdG9rZW4gd2l0aG91dCBpbnZvbHZp bmcgdGhlIHJlc291cmNlIG93bmVyIGludGVuZGVkPw0KDQotRG91ZyBUYW5ncmVuDQpodHRwOi8v bGVzc2lzLm1lDQo= --_000_90C41DD21FB7C64BB94121FBBC2E723447535BBC48P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+ PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlllcC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRp diBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFz cz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gb2F1dGgtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFs ZiBPZiA8L2I+RG91ZyBUYW5ncmVuPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMjEs IDIwMTEgOToyNiBBTTxicj48Yj5Ubzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6 PC9iPiBbT0FVVEgtV0ddIGltcGxpY2l0IGNsaWVudHMgYW5kIHJlZnJlc2ggdG9rZW5zPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+QWNjb3JkaW5nIHRvIDxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItMTUjc2VjdGlvbi00LjIu MiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi0xNSNzZWN0 aW9uLTQuMi4yPC9hPiBpdCBkb2Vzbid0IGxvb2sgbGlrZSBjbGllbnRzIG9mIHRoZSBpbXBsaWNp dCBvYXV0aDIgZmxvdyBzaG91bGQgcmVjZWl2ZSBhIHJlZnJlc2hpbmcgdG9rZW4gYWx0aG91Z2gg aXQgbG9va3MgbGlrZSB0aGUgYWNjZXNzIHRva2VuIGNhbiBvcHRpb25hbGx5IGhhdmUgYW4gZXhw aXJlc19pbiB0aW1lIHNldC4gRG9lcyB0aGlzIG1lYW4gdGhlcmUgaXMgbm8gc3RlcCBmb3IgYW4g aW1wbGljaXQgY2xpZW50IHRvIHJlZnJlc2ggdGhlaXIgYWNjZXNzIHRva2VuIHdpdGhvdXQgaW52 b2x2aW5nIHRoZSB1c2VyIGFnYWluPyA8YnI+PGJyPkFjY29yZGluZyB0byA8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLTE1I3NlY3Rpb24tNiI+ aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi0xNSNzZWN0aW9u LTY8L2E+IGl0IGxvb2tzIGxpa2UgYSBjbGllbnQgbmVlZHMgdG8gc2VuZCBpbiB0aGUgY2xpZW50 IGNyZWRlbnRpYWxzLCBpbmNsdWRpbmcgdGhlIGNsaWVudCBzZWNyZXQsIHRvIHJlZnJlc2ggYW4g YWNjZXNzIHRva2VuLiBUaGlzIGlzIGEgbm8tZ28gZm9yIGNsaWVudHMgdGhhdCBjYW4ndCBzZWN1 cmVseSBzZWN1cmUgYSBjbGllbnQgc2VjcmV0IGxpa2UgYSB3ZWIgYnJvd3Nlci48YnI+PGJyPklz IHByb3ZpZGluZyBubyB3YXkgZm9yIGFuIGltcGxpY2l0IGNsaWVudCB0byByZWZyZXNoIGFuIGFj Y2VzcyB0b2tlbiB3aXRob3V0IGludm9sdmluZyB0aGUgcmVzb3VyY2Ugb3duZXIgaW50ZW5kZWQ/ PGJyPjxiciBjbGVhcj1hbGw+LURvdWcgVGFuZ3Jlbjxicj48YSBocmVmPSJodHRwOi8vbGVzc2lz Lm1lIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2xlc3Npcy5tZTwvYT48bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_90C41DD21FB7C64BB94121FBBC2E723447535BBC48P3PW5EX1MB01E_-- From SRS0=uyABuI=XN=lodderstedt.net=torsten@srs.bis7.eu.blackberry.com Thu Apr 21 09:40:46 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CB8D4E078C; Thu, 21 Apr 2011 09:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYaFnn80hVIG; Thu, 21 Apr 2011 09:40:46 -0700 (PDT) Received: from smtp05.bis7.eu.blackberry.com (smtp05.bis7.eu.blackberry.com [178.239.85.10]) by ietfc.amsl.com (Postfix) with ESMTP id E7D59E0686; Thu, 21 Apr 2011 09:40:45 -0700 (PDT) Received: from b18.c11.bise7.blackberry ([192.168.0.118]) by srs.bis7.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p3LGefEr016051; Thu, 21 Apr 2011 16:40:41 GMT Received: from 172.18.204.204 (cmp34.c11.bise7.blackberry [172.18.204.204]) by b18.c11.bise7.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p3LGefVG018007; Thu, 21 Apr 2011 16:40:41 GMT X-rim-org-msg-ref-id: 236218688 Message-ID: <236218688-1303404040-cardhu_decombobulator_blackberry.rim.net-1061985377-@b13.c11.bise7.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <90C41DD21FB7C64BB94121FBBC2E723447535BBC48@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BBC48@P3PW5EX1MB01.EX1.SECURESERVER.NET> Sensitivity: Normal Importance: Normal To: "Eran Hammer-Lahav" , oauth-bounces@ietf.org, "Doug Tangren" , "oauth@ietf.org" From: torsten@lodderstedt.net Date: Thu, 21 Apr 2011 16:40:53 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] implicit clients and refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 16:42:05 -0000 V2hhdCBhcHAgZG8geW91IGludGVuZCB0byBpbXBsZW1lbnQ/IEl0IGNvdWxkIHVzZSB0aGUgYXV0 aG9yaXphdGlvbiBjb2RlIGZsb3cgaW4gb3JkZXIgdG8gYWxzbyBvYnRhaW4gcmVmcmVzaCB0b2tl bnMuICBBdXRob3JpemF0aW9uIHNlcnZlcnMgbWF5IGFsc28gc3VwcG9ydCB0b2tlbiByZWZyZXNo bWVudCBmb3IgY2xpZW50cyB3L28gc2VjcmV0cy4NCg0KUmVnYXJkcywNClRvcnN0ZW4uDQpHZXNl bmRldCBtaXQgQmxhY2tCZXJyea4gV2VibWFpbCB2b24gVGVsZWtvbSBEZXV0c2NobGFuZCAgDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiA8ZXJh bkBodWVuaXZlcnNlLmNvbT4NClNlbmRlcjogb2F1dGgtYm91bmNlc0BpZXRmLm9yZw0KRGF0ZTog VGh1LCAyMSBBcHIgMjAxMSAwOTozNDozMiANClRvOiBEb3VnIFRhbmdyZW48ZC50YW5ncmVuQGdt YWlsLmNvbT47IG9hdXRoQGlldGYub3JnPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtP QVVUSC1XR10gaW1wbGljaXQgY2xpZW50cyBhbmQgcmVmcmVzaCB0b2tlbnMNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz dA0KT0F1dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0K From d.tangren@gmail.com Thu Apr 21 11:22:28 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 66D53E07D5; Thu, 21 Apr 2011 11:22:28 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhcFTF9XdwHD; Thu, 21 Apr 2011 11:22:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfc.amsl.com (Postfix) with ESMTP id 8A0D4E0717; Thu, 21 Apr 2011 11:22:27 -0700 (PDT) Received: by yxk30 with SMTP id 30so661531yxk.31 for ; Thu, 21 Apr 2011 11:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KKoxRIDnT81vdmLY0RN3Ort8vmqRgcaoCTU6K2FZ6hk=; b=xK1RulEb4Hm+GKVHg3b4uekEufGuKGe64GIIPw1o2kGkvT2aQgt+nJ03d6QgCdFuN7 tXjeSVmgWmnH34OUX1wF5VWqMBkaqOat2FyWt3xBE1GuNl/HTMAdmqlugA8ftotzyRhS qPVK7tbafeJgi2nUxwshaOapthZcaofSLR3QM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=p5R+z9bbqjHr56ddPoRCQXrN/GixZcnNc+1c2mdK41NrNawvoQy5WtK2ro9IwnJJJz F/65IKi8NuBXLg5TOGK5d0BQRhGuRd0W0CBNOpoE6d3uNV8P4JSN1m55xef5/Mc2xF+K aWOgM5RMitPr1y5tuQznFazZ82MmqGzEB0/1k= Received: by 10.90.234.4 with SMTP id g4mr699743agh.139.1303410147156; Thu, 21 Apr 2011 11:22:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.57.33 with HTTP; Thu, 21 Apr 2011 11:22:07 -0700 (PDT) In-Reply-To: <236218688-1303404040-cardhu_decombobulator_blackberry.rim.net-1061985377-@b13.c11.bise7.blackberry> References: <90C41DD21FB7C64BB94121FBBC2E723447535BBC48@P3PW5EX1MB01.EX1.SECURESERVER.NET> <236218688-1303404040-cardhu_decombobulator_blackberry.rim.net-1061985377-@b13.c11.bise7.blackberry> From: Doug Tangren Date: Thu, 21 Apr 2011 14:22:07 -0400 Message-ID: To: torsten@lodderstedt.net Content-Type: multipart/alternative; boundary=00163630efdbd161f504a171d298 Cc: oauth-bounces@ietf.org, "oauth@ietf.org" Subject: Re: [OAUTH-WG] implicit clients and refresh tokens 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, 21 Apr 2011 18:22:28 -0000 --00163630efdbd161f504a171d298 Content-Type: text/plain; charset=UTF-8 I was thinking for something purely browser based, akin to facebook connect or twitter anywhere, where the client would only have to ask the user for authorization once. I don't know what the current practice is for storing an access token is client side (cookie/local storage), but regardless, either every time the user refreshes the page or access token expires, the client would have to ask the user again for authorization. Even if the user didn't revoke access. Is there a current practice for how an implicit client should store access tokens or if they should store them at all? Also what is the current state of which token type to implement for access to protected resources? I've heard a few arguments for and against both bearer and mac but for many oauth2 implementers, it seems the current practice is to use neither and just append the access_token to a client request. I see an understand the danger is in this if an access token were leaked so I am making sure to implement expiring tokens. I just wasn't sure if this was in the cards for clients implementing an implicit flow. Thanks for responding so quickly guys. -Doug Tangren http://lessis.me --00163630efdbd161f504a171d298 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was thinking for something purely browser based, akin to facebook connect= or twitter anywhere, where the client would only have to ask the user for = authorization once. I don't know what the current practice is for stori= ng an access token is client side (cookie/local storage), but regardless, e= ither every time the user refreshes the page or access token expires, the c= lient would have to ask the user again for authorization. Even if the user = didn't revoke access.

Is there a current practice for how an implicit client should store acc= ess tokens or if they should store them at all?

Also what is the cur= rent state of which token type to implement for access to protected resourc= es? I've heard a few arguments for and against both bearer and mac but = for many oauth2 implementers, it seems the current practice is to use neith= er and just append the access_token to a client request. I see an understan= d the danger is in this if an access token were leaked so I am making sure = to implement expiring tokens. I just wasn't sure if this was in the car= ds for clients implementing an implicit flow.

Thanks for responding so quickly guys.

-Doug Tangr= en
http://lessis.me
--00163630efdbd161f504a171d298-- From tonynad@microsoft.com Thu Apr 21 11:34:47 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7E3E4E0804 for ; Thu, 21 Apr 2011 11:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cghzZxzw-Kd0 for ; Thu, 21 Apr 2011 11:34:40 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id 0DD1FE07AF for ; Thu, 21 Apr 2011 11:34:40 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 21 Apr 2011 11:34:39 -0700 Received: from DB3EHSOBE002.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 21 Apr 2011 11:34:38 -0700 Received: from mail32-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.8; Thu, 21 Apr 2011 18:34:37 +0000 Received: from mail32-db3 (localhost.localdomain [127.0.0.1]) by mail32-db3-R.bigfish.com (Postfix) with ESMTP id BEE1F18886BF for ; Thu, 21 Apr 2011 18:34:36 +0000 (UTC) X-SpamScore: -48 X-BigFish: PS-48(zzbb2cK936eK9371O542M98dK148cMzzdafM1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail32-db3 (localhost.localdomain [127.0.0.1]) by mail32-db3 (MessageSwitch) id 1303410875300727_16809; Thu, 21 Apr 2011 18:34:35 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.250]) by mail32-db3.bigfish.com (Postfix) with ESMTP id 46D5A1840054; Thu, 21 Apr 2011 18:34:35 +0000 (UTC) Received: from CH1PRD0302HT002.namprd03.prod.outlook.com (157.55.61.146) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.8; Thu, 21 Apr 2011 18:34:34 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.238]) by CH1PRD0302HT002.namprd03.prod.outlook.com ([10.28.28.64]) with mapi id 14.01.0225.042; Thu, 21 Apr 2011 18:34:33 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , Dick Hardt Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAB2/gYAAA7I5gAADPdkAAAF71YAAAvT6gAABnOkAAAAhFQAAAJ1bAAABBRIAAAIBpIAAATynAAAAMeuAACk2iiAADuGQAAAm7+iA Date: Thu, 21 Apr 2011 18:34:32 +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: [10.28.29.112] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E71A47B28FCH1PRD0302MB115_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 21 Apr 2011 18:34:47 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A47B28FCH1PRD0302MB115_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Clarifications From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, April 20, 2011 4:52 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 I had a hard time following some of this but I'll try to clarify. From: Anthony Nadalin > Date: Wed, 20 Apr 2011 16:05:02 -0700 To: Dick Hardt >, Eran Ha= mmer-lahav > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Revised Section 3 So here is what I currently understand, I'm sure that I have some of this w= rong; 1. At the Prague meeting the general issue of Client Credentials remo= val from document was brought up, Thomas took the action item from the meet= ing to redraft the section that was removed. Thomas provided that. What Tho= mas provided is a replacement for the current section 3 in the latest draft= . 2. As Eran points out there are several parts to this issue, 1st issu= e is the thread going back to Yaron's text proposal ( http://www.ietf.org/m= ail-archive/web/oauth/current/msg03363.html ) which was added and then remo= ved (which were both done w/o consensus) which is authenticating with a acc= ess token request with two assertions, one from the client and one from the= resource owner This is the only requirement driving this open issue. The new proposed text= does not change any other normative part of v2. One additional note is that this doesn't mean the client has to use two ass= ertions, but that there are two assertions and each serves a different purp= ose (authenticate the client, denote the resource owner authorization). the 2nd part is about authentication with id and secret I assume you are referring to the client password credentials section? AJN -> Yes and the 3rd part is about authentication with assertion. Not sure what you mean here, but if you mean authenticating a client using = an assertion, that's already covered by the first part. If you mean using a= n assertion as the resource owner authorization, that's covered by 4.5 and = the 'assertion' extension parameter. AJN -> Yes section 4.5 3. The replacement Section 3 introduces the notion client identity an= d authentication and provides a means to specify a client identity and secr= et used for authentication and also provided is a means for client authenti= cation using assertions (such as SAML). The replacement only adds the assertion part. The rest is already in v2. Th= e new text includes some other useful prose, but that's purely editorial. I believe the way the replacement section 3 is worded it would solve the is= sue that Yaron was trying to solve and a extension could be posible. True, in that it bring's Yaron's proposal back practically unchanged (norma= tive language wise). 4. So with the current text in section 3 and section 4.5 we can't do = 2 assertions True to the extent it doesn't specify it. since it uses grant_type=3Dassertion. Nothing uses that. The 'assertion' grant type has been replaced with a more= generic extension mechanism. Basically, we combined the 'grant_type' and '= assertion_type' parameters into a single extension point. So what was previ= ously sent like this: grant_type=3Dassertion&assertion_type=3Dhttp://some.assertion.type.uri Is now send as: grant_type=3Dhttp://some.assertion.type.uri This change was made in -12 with WG consensus. At the time, the 'assertion'= parameter was relocated to the SAML draft. AJN -> OK, my mistake but still causes issues So I'm not sure that an extension based upon the current draft would help s= olve the problem. An extension grant type (which is the mechanism used by the SAML draft) wil= l not be suitable here. This use care requires defining a new way to authen= tication HTTP requests (traditional client authentication) using assertions= , similar to how Basic is used to authenticate requests using a username an= d password. AJN -> This is maybe where we differ, as taking revised section 3 solves th= e problem So a possible issue would be if you added something like 4.4.3 to 4.5 the e= xtension would have to conform to this, do we expect all extensions to defi= ne this in the way they want? Adding 4.4.3-like text to 4.5 does not have *any* normative implications. S= ection 4.5 provides an extension point to the token endpoint. Section 4.4.3= merely states the obvious in how responses to token requests are handled. = Adding it will be done purely for clarity. AJN -> OK, as long as it is not normative So I agree that the current specification doesn't address the use case of u= sing an assertion to authenticate the client. Beyond that we disagree on ev= erything else related to how to address it. AJN -> Agree, and maybe we don't agree that this is a problem to be solved? EHL From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 19, 2011 2:06 PM To: Eran Hammer-Lahav; Anthony Nadalin Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 Resolves *my* confusion. :) Tony: apologies if you covered this in earlier posts, but if 4.5 does not s= olve your use case, would you clarify what else is needed? Are you unhappy = that it is labeled an extension? -- Dick On 2011-04-19, at 2:00 PM, Eran Hammer-Lahav wrote: So your suggestions is to add something like 4.4.3 to 4.5? That sounds like= a good idea. Would that resolve the potential confusion here? EHL From: Dick Hardt > Date: Tue, 19 Apr 2011 13:25:15 -0700 To: Eran Hammer-lahav > Cc: "recordond@gmail.com" >, oauth > Subject: Re: [OAUTH-WG] Revised Section 3 Thanks for clarifying. Given how you have broken out Section 3 from the res= t of the flow, I missed 4.5. It is not clear in 4.5 that an access token is returned since in the previo= us sections, there is a separate request and response section. What is the = response supposed to look like when using an access token? Some of the con= fusion here may be that 4.5 is not as complete as the other sections. -- Dick On 2011-04-19, at 12:27 PM, Eran Hammer-Lahav wrote: Yes, you are confused... WRAP section 5.2 defines an assertion authorization grant type which is pro= vided in OAuth 2.0 via two parts: 1. v2 extensible grant types [1], which provides the wrap_assertion_format = parameter functionality. You simply provide a URI to identify the assertion= format and include it using the grant_type parameter. No additional parame= ters needed. 2. SAML bearer assertion grant type document [2] which provides the wrap_as= sertion parameter functionality via the assertion parameter. The assertion = parameter is defined in the context of the SAML extension, but is registere= d as a general purpose parameter and available for any future assertion gra= nt types if they so desire. This thread (and open issue) is about a new (to WRAP and OAuth 2.0 pre -11)= client authentication method using assertions. It can be combined with the= WRAP functionality described above to produce requests with two separate a= ssertions (in the same request). The two functionalities has nothing to do = with one another except that both use assertions as each assertions serves = a completely different purpose (one for client authentication, and the othe= r for access authorization). Therefore, this is new functionality that was never discussed or suggested = before Yaron Goland proposal was submitted and added to -11 and later remov= ed in -12. And to prevent a broken record reply I'll add: both actions, tak= en by me, were done without working group consensus. So while adding and re= moving the section between -11 and -12 was not proper IETF editorial proces= s, the end result is nevertheless the same - the section is out of the docu= ment pending working group consensus for inclusion. EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.5 [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03 -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 19, 2011 11:59 AM To: Eran Hammer-Lahav Cc: David Recordon; oauth Subject: Re: [OAUTH-WG] Revised Section 3 On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote: -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 19, 2011 11:37 AM The feature described was in OAuth-WRAP which was a basis for OAuth 2.0. Can you please point me to where this feature was in WRAP? I can't find it. http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 ... or am I confused about what we are talking about changing in Section 3? --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A47B28FCH1PRD0302MB115_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Clarifications=

 <= /p>

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, April 20, 2011 4:52 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

 

I had a hard time followi= ng some of this but I’ll try to clarify.

  

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Wed, 20 Apr 2011 16:05:02 -0700
To: Dick Hardt <dick.hard= t@gmail.com>, Eran Hammer-lahav <eran@hueniverse.com>
Cc: OAuth WG <oauth@ietf.org>
Subject: RE: [OAUTH-WG] Revised Section 3

 

So here is what I current= ly understand, I’m sure that I have some of this wrong;

 

1. &nb= sp;     At the Prague meeting the general issue o= f Client Credentials removal from document was brought up, Thomas took the = action item from the meeting to redraft the section that was removed. Thomas provided that. What Thomas provided is a replacement f= or the current section 3 in the latest draft.

2. &nb= sp;     As Eran points out there are several part= s to this issue, 1st issue is the thread going back to YaronR= 17;s text proposal ( http://www.ietf.org/mail-archive/web/oauth/current/msg03363.html ) wh= ich was added and then removed (which were both done w/o consensus) which i= s authenticating with a access token request with two assertions, one from the client and one from the resource= owner

 

This is the only requirement driving this open issue. The new propo= sed text does not change any other normative part of v2.

 =

One additional note is that this doesn't mean the client has to use= two assertions, but that there are two assertions and each serves a different purpose (authenticate the client, denote the resource o= wner authorization).

 <= /p>

the 2nd part is about authentication with id and secret

 

I assume you are referring = to the client password credentials section?

AJN -> Yes<= /span>

 

and the 3rd part is about authentication with assertion.<= span style=3D"color:black">

 

Not sure what you mean here= , but if you mean authenticating a client using an assertion, that's alread= y covered by the first part. If you mean using an assertion as the resource owner authorization, that's covered by 4.5 and the 'assert= ion' extension parameter.

AJN -> Yes section 4.5=

 <= /p>

 

3. &nb= sp;     The replacement Section 3 introduces the = notion client identity and authentication and provides a means to specify a= client identity and secret used for authentication and also provided is a means for client authentication using assertions (such = as SAML).

 

The replacement only adds t= he assertion part. The rest is already in v2. The new text includes some ot= her useful prose, but that's purely editorial.

 

I believe the way the replacement section 3 is worded it would s= olve the issue that Yaron was trying to solve and a extension could be posible.

 

True, in that it bring's Ya= ron's proposal back practically unchanged (normative language wise).

 

4. &nb= sp;     So with the current text in section 3 and= section 4.5 we can’t do 2 assertions

 

True to the extent it doesn= 't specify it.

 

since it uses grant_type=3Dassertion.

 

Nothing uses that. The 'ass= ertion' grant type has been replaced with a more generic extension mechanis= m. Basically, we combined the 'grant_type' and 'assertion_type' parameters into a single extension point. So what was previously sent like= this:

 

grant_type=3Dassertion&= assertion_type=3Dhttp://some.assertion.type.uri

 

Is now send as:<= /span>

 

grant_type=3Dhttp://some.as= sertion.type.uri 

 

This change was made in = 211;12 with WG consensus. At the time, the 'assertion' parameter was reloca= ted to the SAML draft.

AJN -> OK, my mistake = but still causes issues

 

So I’m not sure that an extension based upon the current d= raft would help solve the problem.<= /o:p>

 

An extension grant type (wh= ich is the mechanism used by the SAML draft) will not be suitable here. Thi= s use care requires defining a new way to authentication HTTP requests (traditional client authentication) using assertions, simila= r to how Basic is used to authenticate requests using a username and passwo= rd.

AJN -> This is maybe w= here we differ, as taking revised section 3 solves the problem

 <= /p>

 

So a possible issue would= be if you added something like 4.4.3 to 4.5 the extension would have to co= nform to this, do we expect all extensions to define this in the way they want? =

 

Adding 4.4.3-like text to 4= .5 does not have *any* normative implications. Section 4.5 provides an exte= nsion point to the token endpoint. Section 4.4.3 merely states the obvious in how responses to token requests are handled. Adding = it will be done purely for clarity.

AJN -> OK, as long as = it is not normative

 

So I agree that the current= specification doesn't address the use case of using an assertion to authen= ticate the client. Beyond that we disagree on everything else related to how to address it.

 <= /p>

AJN -> Agree, and mayb= e we don’t agree that this is a problem to be solved?

 <= /p>

 

EHL

 

From: Dick Hardt [mailto:= dick.hardt@gmail.com]
Sent: Tuesday, April 19, 2011 2:06 PM
To: Eran Hammer-Lahav; Anthony Nadalin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

 =

Resolves *my* confusion.= :)

 =

Tony: apologies if you c= overed this in earlier posts, but if 4.5 does not solve your use case, woul= d you clarify what else is needed? Are you unhappy that it is labeled an ex= tension?

 =

-- Dick

 =

On 2011-04-19, at 2:00 P= M, Eran Hammer-Lahav wrote:




So your suggestions is to a= dd something like 4.4.3 to 4.5? That sounds like a good idea.

 

Would that resolve the pote= ntial confusion here?<= /p>

 

EHL

 

From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 19 Apr 2011 13:25:15 -0700
To: Eran Hammer-lahav <era= n@hueniverse.com>
Cc: "recordond@gmail.com= " <recordond@gmail.com>, oauth <oauth@ietf.org><= br> Subject: Re: [OAUTH-WG] Revised Section 3

 

Thanks for clarifying. Give= n how you have broken out Section 3 from the rest of the flow, I missed 4.5= .

 

It is not clear in 4.5 that= an access token is returned since in the previous sections, there is a sep= arate request and response section. What is the response supposed to look like when using an access token?  Some of the c= onfusion here may be that 4.5 is not as complete as the other sections.

 

-- Dick

 

 

 

On 2011-04-19, at 12:27 PM,= Eran Hammer-Lahav wrote:

 

Yes, you are confused...

WRAP section 5.2 defines an= assertion authorization grant type which is provided in OAuth 2.0 via two = parts:

1. v2 extensible grant type= s [1], which provides the wrap_assertion_format parameter functionality. Yo= u simply provide a URI to identify the assertion format and include it using the grant_type parameter. No additional parameters ne= eded.

2. SAML bearer assertion gr= ant type document [2] which provides the wrap_assertion parameter functiona= lity via the assertion parameter. The assertion parameter is defined in the context of the SAML extension, but is registered as a ge= neral purpose parameter and available for any future assertion grant types = if they so desire.

This thread (and open issue= ) is about a new (to WRAP and OAuth 2.0 pre -11) client authentication meth= od using assertions. It can be combined with the WRAP functionality described above to produce requests with two separate assertions (in the s= ame request). The two functionalities has nothing to do with one another ex= cept that both use assertions as each assertions serves a completely differ= ent purpose (one for client authentication, and the other for access authorization).

Therefore, this is new func= tionality that was never discussed or suggested before Yaron Goland proposa= l was submitted and added to -11 and later removed in -12. And to prevent a broken record reply I'll add: both actions, taken by me, = were done without working group consensus. So while adding and removing the= section between -11 and -12 was not proper IETF editorial process, the end= result is nevertheless the same - the section is out of the document pending working group consensus for i= nclusion.

EHL

-----Original Message-----<= /span>

From: Dick Hardt [mailto:dick.hardt@gmail.com]

Sent: Tuesday, April 19, 20= 11 11:59 AM

To: Eran Hammer-Lahav

Cc: David Recordon; oauth

Subject: Re: [OAUTH-WG] Rev= ised Section 3

On 2011-04-19, at 11:41 AM,= Eran Hammer-Lahav wrote:

-----Original Message-----<= /span>

From: Dick Hardt [mailto:dick.hardt@gmail.com]

Sent: Tuesday, April 19, 20= 11 11:37 AM

The feature described was i= n OAuth-WRAP which was a basis for OAuth=

2.0.

Can you please point me to = where this feature was in WRAP? I can't find it.

... or am I confused about = what we are talking about changing in Section 3?

 

 

 =

--_000_B26C1EF377CB694EAB6BDDC8E624B6E71A47B28FCH1PRD0302MB115_-- From eran@hueniverse.com Thu Apr 21 12:27:46 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 88602E0778 for ; Thu, 21 Apr 2011 12:27:46 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYxxrKLD+7ln for ; Thu, 21 Apr 2011 12:27:45 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id EF9A0E076E for ; Thu, 21 Apr 2011 12:27:44 -0700 (PDT) Received: (qmail 14445 invoked from network); 21 Apr 2011 19:27:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Apr 2011 19:27:43 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 21 Apr 2011 12:27:38 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , Dick Hardt Date: Thu, 21 Apr 2011 12:27:33 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: AcwAWixUg4q8lIU9SZOZx8qI6WILKA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9D5CC5111448eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 21 Apr 2011 19:27:46 -0000 --_000_C9D5CC5111448eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This got a little bit too nested so I kept only the comments where we are n= ot on the same page. From: Anthony Nadalin > Date: Thu, 21 Apr 2011 11:34:32 -0700 To: Eran Hammer-lahav >, Di= ck Hardt > The 'assertion' grant type has been replaced with a more generic extension = mechanism. Basically, we combined the 'grant_type' and 'assertion_type' par= ameters into a single extension point. So what was previously sent like thi= s: grant_type=3Dassertion&assertion_type=3Dhttp://some.assertion.type.uri Is now send as: grant_type=3Dhttp://some.assertion.type.uri This change was made in =9612 with WG consensus. At the time, the 'assertio= n' parameter was relocated to the SAML draft. AJN -> OK, my mistake but still causes issues Can you please explain what issues this change causes? There is currently n= o open issue regarding this change, and it has nothing to do with this thre= ad. An extension grant type (which is the mechanism used by the SAML draft) wil= l not be suitable here. This use care requires defining a new way to authen= tication HTTP requests (traditional client authentication) using assertions= , similar to how Basic is used to authenticate requests using a username an= d password. AJN -> This is maybe where we differ, as taking revised section 3 solves th= e problem We agree here that the grant type extension mechanism does not address this= use case (which was Dick's question to you). The proposed section adds a n= ew extensibility point which does address the use case. We disagree on the = details of that proposal, but we agree that it does address the use case. Also, it doesn't matter if the new text doesn't set to define a new general= purpose HTTP client authentication scheme using assertions. In practice, t= hat's what it is creating. You can view it from the narrow perspective of t= he v2 specification, but in practice, deploying this client assertion crede= ntials method means deploying a new HTTP authentication scheme. For example, an authorization server supporting both client password creden= tials using HTTP Basic and this assertion alternative, will probably want t= o implement both at the same layer. This means that even though the asserti= on route does not use the HTTP authorization header, the web server will st= ill extract those form-encoded parameter at the same place it does Basic. O= therwise you perform the same functionality (authenticating a client) at di= fferent places which for many, is not a proper architecture. This is all philosophical about the big picture implications of what the ne= w assertion authentication proposal does, but it is important when done in = the context of an IETF standard. Much of my criticism and objections to the= proposed solution and text are coming out of my view that this is not a pr= oper way and place to define a new HTTP authentication scheme. Since our charter is useless at this point, I have refrained from bringing = up the fact that defining a new HTTP authentication scheme using assertions= is out of scope. But since the chairs are now working on fixing the charte= r to reflect reality, I guess they will need to directly address this speci= fic use case. Everything in =9615 is implicitly in scope because it directl= y originates from OAuth 1.0 and WRAP. This is completely new. Adding 4.4.3-like text to 4.5 does not have *any* normative implications. S= ection 4.5 provides an extension point to the token endpoint. Section 4.4.3= merely states the obvious in how responses to token requests are handled. = Adding it will be done purely for clarity. AJN -> OK, as long as it is not normative It is already normative =96 this is just clarifying it. Section 4.5 is an e= xtension of the access token endpoint. All responses to the access token en= dpoint must comply with section 5. Adding a 4.4.3-like text merely states t= hat. You cannot define a new grant type per 4.5 that does not comply with t= he normative text of section 5. If this is a problem (which means it is a problem in =9615 already), please= open a new issue. So I agree that the current specification doesn't address the use case of = using an assertion to authenticate the client. Beyond that we disagree on e= verything else related to how to address it. AJN -> Agree, and maybe we don=92t agree that this is a problem to be solve= d? We agree it is a problem and that since you want to deploy this use case, a= solution is required. I don't have anything against the use case. However, I don't think this WG or the v2 specification are the right place = to address it. EHL --_000_C9D5CC5111448eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
This got a little bit too neste= d so I kept only the comments where we are not on the same page.
=
From: Anthony Nadal= in <tonynad@microsoft.com&g= t;
Date: Thu, 21 Apr 2011 11:34= :32 -0700
To: Eran Hammer-lahav= <eran@hueniverse.com>, Di= ck Hardt <dick.hardt@gmail.com>

=
Can you please explain what issues this change causes? There is curren= tly no open issue regarding this change, and it has nothing to do with this= thread.

An extension grant type (which is the mechanism used by t= he SAML draft) will not be suitable here. This use care requires defining a= new way to authentication HTTP requests (traditional client authentication) using assertions, simila= r to how Basic is used to authenticate requests using a username and passwo= rd.

AJN ->= This is maybe where we differ, as taking revised section 3 solves the prob= lem 

=
We agree here that the grant type extension mechanism does not = address this use case (which was Dick's question to you). The proposed sect= ion adds a new extensibility point which does address the use case. We disa= gree on the details of that proposal, but we agree that it does address the= use case.

Also, it doesn't matter if the new text= doesn't set to define a new general purpose HTTP client authentication sch= eme using assertions. In practice, that's what it is creating. You can view= it from the narrow perspective of the v2 specification, but in practice, d= eploying this client assertion credentials method means deploying a new HTT= P authentication scheme.

For example, an authoriza= tion server supporting both client password credentials using HTTP Basic an= d this assertion alternative, will probably want to implement both at the s= ame layer. This means that even though the assertion route does not use the= HTTP authorization header, the web server will still extract those form-en= coded parameter at the same place it does Basic. Otherwise you perform the = same functionality (authenticating a client) at different places which for = many, is not a proper architecture.

This is all ph= ilosophical about the big picture implications of what the new assertion au= thentication proposal does, but it is important when done in the context of= an IETF standard. Much of my criticism and objections to the proposed solu= tion and text are coming out of my view that this is not a proper way and p= lace to define a new HTTP authentication scheme.

S= ince our charter is useless at this point, I have refrained from bringing u= p the fact that defining a new HTTP authentication scheme using assertions = is out of scope. But since the chairs are now working on fixing the charter= to reflect reality, I guess they will need to directly address this specif= ic use case. Everything in =9615 is implicitly in scope because it directly= originates from OAuth 1.0 and WRAP. This is completely new.

Adding 4.4.3-= like text to 4.5 does not have *any* normative implications. Section 4.5 pr= ovides an extension point to the token endpoint. Section 4.4.3 merely states the obvious in how responses to token requests are handled. Adding = it will be done purely for clarity.

AJN -> OK, as long as it is not normative

It is already normative =96 th= is is just clarifying it. Section 4.5 is an extension of the access token e= ndpoint. All responses to the access token endpoint must comply with sectio= n 5. Adding a 4.4.3-like text merely states that. You cannot define a new g= rant type per 4.5 that does not comply with the normative text of section 5= .

If this is a problem (which means it is a proble= m in =9615 already), please open a new issue.

 So I agree that the cu= rrent specification doesn't address the use case of using an assertion to a= uthenticate the client. Beyond that we disagree on everything else related to how to address it.

AJN -> Agree, and maybe we don=92t agree that this is a = problem to be solved?

We agree it is a problem and that since you want to deploy this use c= ase, a solution is required. I don't have anything against the use case.

However, I don't think this WG or the v2 specificati= on are the right place to address it.

EHL

--_000_C9D5CC5111448eranhueniversecom_-- From hannes.tschofenig@gmx.net Fri Apr 22 08:01:05 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 484A4E067C for ; Fri, 22 Apr 2011 08:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.041 X-Spam-Level: X-Spam-Status: No, score=-102.041 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovg5B0R5NeMq for ; Fri, 22 Apr 2011 08:01:04 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfc.amsl.com (Postfix) with SMTP id 624D0E05F5 for ; Fri, 22 Apr 2011 08:01:04 -0700 (PDT) Received: (qmail invoked by alias); 22 Apr 2011 15:01:02 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp066) with SMTP; 22 Apr 2011 17:01:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Mb/EoZYjMT7tsUoC8UDGoDWG31ZpdV/4DwB8RRi hBcWYX/oO6GzMw From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Apr 2011 18:01:01 +0300 Message-Id: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] OAuth Interim 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, 22 Apr 2011 15:01:05 -0000 Hi all,=20 we are planning to hold a 1-day interim meeting for the OAuth working = group.=20 Date: 23rd May, 2011 (9am - 6pm) Location: Mountain View, CA, US Host: Tbd.=20 Agenda: Discussion of remaining open issues with the OAuth 2.0 = specification, and other working group items.=20 Ciao Hannes & Blaine & Barry PS: You may noticed that the W3C Workshop on Identity in the Browser = takes place in Mountain View on the 24/25th May 2011.=20 From recordond@gmail.com Fri Apr 22 10:44:38 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 26C9FE0668 for ; Fri, 22 Apr 2011 10:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QKfiPuOJBQq for ; Fri, 22 Apr 2011 10:44:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 41A6CE0655 for ; Fri, 22 Apr 2011 10:44:37 -0700 (PDT) Received: by vxg33 with SMTP id 33so721132vxg.31 for ; Fri, 22 Apr 2011 10:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K2ba5mXLKxRpWM3g79Q05pJQXHvxm7X3bZdI5+QZdkY=; b=ezZSq6mDeNUeUxttHH5mDMgEYonzvZVShr97o66ZxN2ufacB4x6El1ltP+rZmUlXHT RWWp1uELbdvow04CB5mpm4fX3ZsFsNYtXQQwK5/yhJt2ejehH7/PhubCg2XQT6jpvkl6 m3wHqZv8nN29TkiurGn4aaNfcxJ64xKOibEmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=unP0snKNVlu51IE+9p2RjE9k65bDQtYAOcVBXtlGDENTScoYZ7KzeVTx9L9YeTWEgx YNWzajYAC1Ntsurz4u3mmnQlvMrpa9FKEluqmUlGiUOwO//5FLsGzpw+DGESIu5E1WsD Q73dj+00b7DxN13rpN9FrweOxMSQl3K0gYj8I= MIME-Version: 1.0 Received: by 10.52.76.10 with SMTP id g10mr1985454vdw.252.1303494275286; Fri, 22 Apr 2011 10:44:35 -0700 (PDT) Received: by 10.52.185.65 with HTTP; Fri, 22 Apr 2011 10:44:35 -0700 (PDT) In-Reply-To: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> Date: Fri, 22 Apr 2011 10:44:35 -0700 Message-ID: From: David Recordon To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Interim 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, 22 Apr 2011 17:44:38 -0000 Happy to host in Palo Alto. On Fri, Apr 22, 2011 at 8:01 AM, Hannes Tschofenig wrote: > Hi all, > > we are planning to hold a 1-day interim meeting for the OAuth working group. > > Date: 23rd May, 2011 (9am - 6pm) > Location: Mountain View, CA, US > Host: Tbd. > Agenda: Discussion of remaining open issues with the OAuth 2.0 specification, and other working group items. > > Ciao > Hannes & Blaine & Barry > > PS: You may noticed that the W3C Workshop on Identity in the Browser takes place in Mountain View on the 24/25th May 2011. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From barryleiba.mailing.lists@gmail.com Fri Apr 22 11:25:20 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C212CE07C6 for ; Fri, 22 Apr 2011 11:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.821 X-Spam-Level: X-Spam-Status: No, score=-102.821 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVZh6pw-vbKM for ; Fri, 22 Apr 2011 11:25:20 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfc.amsl.com (Postfix) with ESMTP id 00406E0762 for ; Fri, 22 Apr 2011 11:25:19 -0700 (PDT) Received: by gxk19 with SMTP id 19so259027gxk.31 for ; Fri, 22 Apr 2011 11:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=VvXaiviFANZNWNtiz2H1iM0mqpBL/CgD2oBH9VnQkX0=; b=yCtmJ7tXVNA0ZK+Ju05giuKET1tY6HrXL/kn7yuWWIBFvz+zKwXyLKWYGv2txEmuJ+ aFqDS8DahCBF74+6fpfc6Mo1x2eAotLrU611IU5Ne2yTG+yBNZ7ehSlcaloHsyz0lmz4 0leKrZjVTx07l4r4bNBsEowpsTR8erMK2E2dk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=Ae2rXUXj+uIGvocQSHzJcpkRNjc16cCDA9w1agmReseQ9mIh5GnEbcxjqgv+BPN2pr v8TBooVUtG9qpbh1HhFiqXjZ0V57b9fe128DNyNUbhDSxwqNDNrxhkRZvzFu+3mou3hf vu4JRQabMew/uBGuYbRz+pNqYcRNAHLsPoXh0= MIME-Version: 1.0 Received: by 10.236.190.166 with SMTP id e26mr1366187yhn.265.1303496718665; Fri, 22 Apr 2011 11:25:18 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.10 with HTTP; Fri, 22 Apr 2011 11:25:18 -0700 (PDT) In-Reply-To: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> Date: Fri, 22 Apr 2011 14:25:18 -0400 X-Google-Sender-Auth: l4UtrrGDw-iSlFYw46YofKFVN-E Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] OAuth Interim 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, 22 Apr 2011 18:25:20 -0000 To make it easier to keep track of how many attendees we might get, I've created a wiki page for probable attendees to record their intent: http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeetingAttendance If you intend to attend, please help by going to that page and editing it, and adding your name to the list. The list is only to give us a reasonable expectation of who plans to be there. We ask you to indicate your intent there, but there's no requirement that you do, and doing so doesn't obligate you. Attendance is open to all. The meeting details, as specified in Hannes's note, are here: http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeeting Barry From stephen.farrell@cs.tcd.ie Fri Apr 22 11:51:23 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A2EDFE0757; Fri, 22 Apr 2011 11:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9IrnxA+l4T7; Fri, 22 Apr 2011 11:51:22 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id 8BF88E073A; Fri, 22 Apr 2011 11:51:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0EFF1171C5F; Fri, 22 Apr 2011 19:51:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1303498280; bh=iFngUYHzmwY630 r1gM4bcQ3Og5jZgseUQW2+a6CajAs=; b=Z+Pjz7rgCrcTXPSdeJPuvddltGHjuQ nuVhNJ7C6uyfqBrw1ReK72epRqgQuiWgKSUT+xKsXvEcCV7x3ax1vGoJYSms5KsE ycbyqS/Vhe5F0htjey0PLaJh2kqbwTd21LcQ1VrIvciDdOSVZHk9JvLpemvGBfF7 Tgl+fEmelyxo7JDI4KJuCuzR1X3nUGDoH5ulJeqMPqOa0tzBKmU38mvB+OluOvy2 YvgblxOsboBBsthKYsp3yWbFdpURIR0HkniPLdvgpIhjAsad17SJoOKohcpOAOaJ IG8DsB8H51n94Cs3ahqLhwMCeHLqkt1hI8q8/BlyvNMGmEfBymoEEOFA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id H+oMJukRmjfh; Fri, 22 Apr 2011 19:51:20 +0100 (IST) Received: from [10.87.48.10] (unknown [86.44.75.91]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 81056171C5B; Fri, 22 Apr 2011 19:51:20 +0100 (IST) Message-ID: <4DB1CE24.9070209@cs.tcd.ie> Date: Fri, 22 Apr 2011 19:51:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Hannes Tschofenig References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> In-Reply-To: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: The IESG , OAuth WG Subject: Re: [OAUTH-WG] OAuth Interim 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, 22 Apr 2011 18:51:23 -0000 Secretary - this is approved, you can send a note to ietf-announce. In case folks aren't familiar with them the guidelines for interim meetings are at [1]. I think this is a fine idea. Unfortunately I can't be there due to another commitment. Stephen. [1] http://www.ietf.org/iesg/statement/interim-meetings.html On 22/04/11 16:01, Hannes Tschofenig wrote: > Hi all, > > we are planning to hold a 1-day interim meeting for the OAuth working group. > > Date: 23rd May, 2011 (9am - 6pm) > Location: Mountain View, CA, US > Host: Tbd. > Agenda: Discussion of remaining open issues with the OAuth 2.0 specification, and other working group items. > > Ciao > Hannes & Blaine & Barry > > PS: You may noticed that the W3C Workshop on Identity in the Browser takes place in Mountain View on the 24/25th May 2011. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From melinda.shore@gmail.com Fri Apr 22 12:13:12 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 26560E076D for ; Fri, 22 Apr 2011 12:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bole3k0o-t8y for ; Fri, 22 Apr 2011 12:13:11 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 067EDE06E8 for ; Fri, 22 Apr 2011 12:13:10 -0700 (PDT) Received: by vws12 with SMTP id 12so761361vws.31 for ; Fri, 22 Apr 2011 12:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BcuFWMU5lwBdhNbav9wQpBJUWdC8ln5YQ4e43edzbG8=; b=B9yWrX/hD38ypsge39XJWJLZRTVgTYHUe7LX6nL1KZeDOBmIzVDf/6nzj2pz+ZHOi/ nqbZmLm8bdoS8HzJRh+bzAqrME8Y20womkw8TXJSbNMjHpEzgH5QfG27A4kFlR4+yT2W /ygsn9pSsbfzC8j6BbuqBKBSn+P54pZmztiZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=se8sIT9dEBl292Q6hbigb0ycOP2I4YpVkZNBOfPn9T3uvOCxHJYu8N0f/Bop9ATSLK Odse2p4ZOC8dTOv7yV6QrKHV/5ljVPolNrVnL1hpdmv5PtTx6U7QGltKbUZ51Ay8YmLQ B3ArTR2zOPBIq4OHkX+h4m6eA3o8JdIXXYTOY= MIME-Version: 1.0 Received: by 10.220.20.80 with SMTP id e16mr406304vcb.219.1303499590668; Fri, 22 Apr 2011 12:13:10 -0700 (PDT) Received: by 10.220.19.21 with HTTP; Fri, 22 Apr 2011 12:13:10 -0700 (PDT) In-Reply-To: References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> Date: Fri, 22 Apr 2011 11:13:10 -0800 Message-ID: From: Melinda Shore To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Interim 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, 22 Apr 2011 19:13:12 -0000 I'm unable to attend in person but I'm hoping that remote participation will be an option - any hope of that? Thanks, Melinda From recordond@gmail.com Fri Apr 22 14:26:09 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 506E1E0757 for ; Fri, 22 Apr 2011 14:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZltxeScPJM8p for ; Fri, 22 Apr 2011 14:26:08 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id BF6E1E067D for ; Fri, 22 Apr 2011 14:26:08 -0700 (PDT) Received: by vxg33 with SMTP id 33so839782vxg.31 for ; Fri, 22 Apr 2011 14:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+5aXUaMuFvFY8rfqZKYF0d/2EZudMyl2i/2xyTMqo0o=; b=UJcDc1pLY6jVdZbQRR0J8R8H9766pyeuyWfwAqaDp5gzNCvHKcQIExvt8IFRx8MZ/7 YmRp+QcUl9JvQoSXbDWCun9EMjWem+/SyQYu8fsi+7J6zNcPSMYfSCfStiEKXk7SDu0D stxWTuFBl/tnTclCZapecOY4wbuxLYnyRz3DA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XTOsGoJalDYrvYf84q6bRwqIaAhW98MGlT5MCXcMw89s0OqP23M+EbNmMrBNQ/J0lE xTtZp+RcJI+1cM1i70n6qYLhq6wWiixtq88s/RIcYrZp6TmnjrK+997wiNyYDJ5JUIs/ XPr530QXchuhvB7WaB+qcs5BFUwqsAMNyFoXA= MIME-Version: 1.0 Received: by 10.52.74.74 with SMTP id r10mr2260172vdv.212.1303507568414; Fri, 22 Apr 2011 14:26:08 -0700 (PDT) Received: by 10.52.185.65 with HTTP; Fri, 22 Apr 2011 14:26:08 -0700 (PDT) In-Reply-To: References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> Date: Fri, 22 Apr 2011 14:26:08 -0700 Message-ID: From: David Recordon To: Melinda Shore Content-Type: text/plain; charset=ISO-8859-1 Cc: Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] OAuth Interim 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, 22 Apr 2011 21:26:09 -0000 I can setup audio and video conferencing if it's at Facebook. On Fri, Apr 22, 2011 at 12:13 PM, Melinda Shore wrote: > I'm unable to attend in person but I'm hoping that remote participation > will be an option - any hope of that? > > Thanks, > > Melinda > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From tonynad@microsoft.com Fri Apr 22 14:51:59 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4F12FE067D for ; Fri, 22 Apr 2011 14:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.166 X-Spam-Level: X-Spam-Status: No, score=-7.166 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzA6bOiRc+Zm for ; Fri, 22 Apr 2011 14:51:54 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id 957B7E0613 for ; Fri, 22 Apr 2011 14:51:53 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 22 Apr 2011 14:51:52 -0700 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 22 Apr 2011 14:51:52 -0700 Received: from mail13-ch1-R.bigfish.com (216.32.181.168) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.8; Fri, 22 Apr 2011 21:51:52 +0000 Received: from mail13-ch1 (localhost.localdomain [127.0.0.1]) by mail13-ch1-R.bigfish.com (Postfix) with ESMTP id 1E68B17F846D for ; Fri, 22 Apr 2011 21:51:52 +0000 (UTC) X-SpamScore: -17 X-BigFish: PS-17(zzbb2cK9371Oc1dMzzdafM1202h1082kzz8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT008.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail13-ch1 (localhost.localdomain [127.0.0.1]) by mail13-ch1 (MessageSwitch) id 1303509102689488_8779; Fri, 22 Apr 2011 21:51:42 +0000 (UTC) Received: from CH1EHSMHS026.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail13-ch1.bigfish.com (Postfix) with ESMTP id 99F86196004F; Fri, 22 Apr 2011 21:51:42 +0000 (UTC) Received: from CH1PRD0302HT008.namprd03.prod.outlook.com (207.46.198.24) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 22 Apr 2011 21:51:33 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.221]) by CH1PRD0302HT008.namprd03.prod.outlook.com ([10.28.29.127]) with mapi id 14.01.0225.042; Fri, 22 Apr 2011 21:51:33 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , Dick Hardt Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAB2/gYAAA7I5gAADPdkAAAF71YAAAvT6gAABnOkAAAAhFQAAAJ1bAAABBRIAAAIBpIAAATynAAAAMeuAACk2iiAADuGQAAAm7+iAAAIawIAALNYVsA== Date: Fri, 22 Apr 2011 21:51:33 +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: [10.28.29.165] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480C92CH1PRD0302MB115_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT008.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 22 Apr 2011 21:51:59 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480C92CH1PRD0302MB115_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some additional input From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, April 21, 2011 12:28 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 This got a little bit too nested so I kept only the comments where we are n= ot on the same page. From: Anthony Nadalin > Date: Thu, 21 Apr 2011 11:34:32 -0700 To: Eran Hammer-lahav >, Di= ck Hardt > The 'assertion' grant type has been replaced with a more generic extension = mechanism. Basically, we combined the 'grant_type' and 'assertion_type' par= ameters into a single extension point. So what was previously sent like thi= s: grant_type=3Dassertion&assertion_type=3Dhttp://some.assertion.type.uri Is now send as: grant_type=3Dhttp://some.assertion.type.uri This change was made in -12 with WG consensus. At the time, the 'assertion'= parameter was relocated to the SAML draft. AJN -> OK, my mistake but still causes issues Can you please explain what issues this change causes? There is currently n= o open issue regarding this change, and it has nothing to do with this thre= ad. AJN-> just an issue for the use case that we have as this does not allow fo= r the usage of 2 assertions, not a new issue An extension grant type (which is the mechanism used by the SAML draft) wil= l not be suitable here. This use care requires defining a new way to authen= tication HTTP requests (traditional client authentication) using assertions= , similar to how Basic is used to authenticate requests using a username an= d password. AJN -> This is maybe where we differ, as taking revised section 3 solves th= e problem We agree here that the grant type extension mechanism does not address this= use case (which was Dick's question to you). The proposed section adds a n= ew extensibility point which does address the use case. We disagree on the = details of that proposal, but we agree that it does address the use case. Also, it doesn't matter if the new text doesn't set to define a new general= purpose HTTP client authentication scheme using assertions. In practice, t= hat's what it is creating. You can view it from the narrow perspective of t= he v2 specification, but in practice, deploying this client assertion crede= ntials method means deploying a new HTTP authentication scheme. For example, an authorization server supporting both client password creden= tials using HTTP Basic and this assertion alternative, will probably want t= o implement both at the same layer. This means that even though the asserti= on route does not use the HTTP authorization header, the web server will st= ill extract those form-encoded parameter at the same place it does Basic. O= therwise you perform the same functionality (authenticating a client) at di= fferent places which for many, is not a proper architecture. This is all philosophical about the big picture implications of what the ne= w assertion authentication proposal does, but it is important when done in = the context of an IETF standard. Much of my criticism and objections to the= proposed solution and text are coming out of my view that this is not a pr= oper way and place to define a new HTTP authentication scheme. Since our charter is useless at this point, I have refrained from bringing = up the fact that defining a new HTTP authentication scheme using assertions= is out of scope. But since the chairs are now working on fixing the charte= r to reflect reality, I guess they will need to directly address this speci= fic use case. Everything in -15 is implicitly in scope because it directly = originates from OAuth 1.0 and WRAP. This is completely new. AJN-> So the client credentials originate from WRAP also, it's not complete= ly new, it may be new the way that it got worded but the same functionality= was in WRAP. The section 5.2 (and subsections) in the WAP specification i= s where you see the assertion documented but what is not explicitly stated = (other than additional parameters clause)there but not disallowed is the ab= ility to have the access_token (additional parameters) also specified so yo= u were allowed to have 2 assertions in WRAP for authentication Adding 4.4.3-like text to 4.5 does not have *any* normative implications. S= ection 4.5 provides an extension point to the token endpoint. Section 4.4.3= merely states the obvious in how responses to token requests are handled. = Adding it will be done purely for clarity. AJN -> OK, as long as it is not normative It is already normative - this is just clarifying it. Section 4.5 is an ext= ension of the access token endpoint. All responses to the access token endp= oint must comply with section 5. Adding a 4.4.3-like text merely states tha= t. You cannot define a new grant type per 4.5 that does not comply with the= normative text of section 5. If this is a problem (which means it is a problem in -15 already), please o= pen a new issue. AJN-> I need to think on this and make sure we don't have a case where the = extension would not return what is in th base So I agree that the current specification doesn't address the use case of = using an assertion to authenticate the client. Beyond that we disagree on e= verything else related to how to address it. AJN -> Agree, and maybe we don't agree that this is a problem to be solved? We agree it is a problem and that since you want to deploy this use case, a= solution is required. I don't have anything against the use case. However, I don't think this WG or the v2 specification are the right place = to address it. EHL --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480C92CH1PRD0302MB115_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some additional input

 <= /p>

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, April 21, 2011 12:28 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

 

This got a little bit too n= ested so I kept only the comments where we are not on the same page.

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Thu, 21 Apr 2011 11:34:32 -0700
To: Eran Hammer-lahav <era= n@hueniverse.com>, Dick Hardt <dick.hardt@gmail.com>

 

The 'assertion' grant type has been re= placed with a more generic extension mechanism. Basically, we combined the = 'grant_type' and 'assertion_type' parameters into a single extension point. So what was previously sent like this:=

 = grant_type=3Dassertion&assertion_type=3Dhttp://some.assertion.type.uri

Is now send as:

This change was made in –12 with WG= consensus. At the time, the 'assertion' parameter was relocated to the SAML draft.

AJN -> OK, my mistake but still caus= es issues

Can you please explain what= issues this change causes? There is currently no open issue regarding this= change, and it has nothing to do with this thread.

AJN-> just an issue fo= r the use case that we have as this does not allow for the usage of 2 asser= tions, not a new issue

An extension grant type (which is the mec= hanism used by the SAML draft) will not be suitable here. This use care requires defining a new way to authentication HTTP requests = (traditional client authentication) using assertions, similar to how Basic = is used to authenticate requests using a username and password.

AJN -> This is maybe where we differ= , as taking revised section 3 solves the problem 

We agree here that the gran= t type extension mechanism does not address this use case (which was Dick's= question to you). The proposed section adds a new extensibility point which does address the use case. We disagree on the details of that = proposal, but we agree that it does address the use case.=

 

Also, it doesn't matter if = the new text doesn't set to define a new general purpose HTTP client authen= tication scheme using assertions. In practice, that's what it is creating. You can view it from the narrow perspective of the v2 spec= ification, but in practice, deploying this client assertion credentials met= hod means deploying a new HTTP authentication scheme.

 

For example, an authorizati= on server supporting both client password credentials using HTTP Basic and = this assertion alternative, will probably want to implement both at the same layer. This means that even though the assertion route do= es not use the HTTP authorization header, the web server will still extract= those form-encoded parameter at the same place it does Basic. Otherwise yo= u perform the same functionality (authenticating a client) at different places which for many, is not a pro= per architecture.

 

This is all philosophical a= bout the big picture implications of what the new assertion authentication = proposal does, but it is important when done in the context of an IETF standard. Much of my criticism and objections to the proposed s= olution and text are coming out of my view that this is not a proper way an= d place to define a new HTTP authentication scheme.

 

Since our charter is useles= s at this point, I have refrained from bringing up the fact that defining a= new HTTP authentication scheme using assertions is out of scope. But since the chairs are now working on fixing the charter to re= flect reality, I guess they will need to directly address this specific use= case. Everything in –15 is implicitly in scope because it directly o= riginates from OAuth 1.0 and WRAP. This is completely new.

 <= /p>

AJN-> So the client cr= edentials originate from WRAP also, it’s not completely new, it may b= e new the way that it got worded but the same functionality was in WRAP. The  section 5.2 (and subsections) in the WAP specification is = where you see the assertion documented but what is not explicitly stated (o= ther than additional parameters clause)there but not disallowed is the abil= ity to have the access_token (additional parameters) also specified so you were allowed to have 2 assertions in WRA= P for authentication

Adding 4.4.3-like text to 4.5 does not= have *any* normative implications. Section 4.5 provides an extension point= to the token endpoint. Section 4.4.3 merely states the obvious in how responses to token requests are handled. = Adding it will be done purely for clarity.

AJN -> OK, as long as it is not norm= ative

It is already normative = 211; this is just clarifying it. Section 4.5 is an extension of the access = token endpoint. All responses to the access token endpoint must comply with section 5. Adding a 4.4.3-like text merely states that. You ca= nnot define a new grant type per 4.5 that does not comply with the normativ= e text of section 5.

 

If this is a problem (which= means it is a problem in –15 already), please open a new issue.=

AJN-> I need to think = on this and make sure we don’t have a case where the extension would = not return what is in th base

 So I agree that the current spec= ification doesn't address the use case of using an assertion to authenticat= e the client. Beyond that we disagree on everything else related to how to address it.

AJN -> Agree, and maybe we don’= ;t agree that this is a problem to be solved?

We agree it is a problem an= d that since you want to deploy this use case, a solution is required. I do= n't have anything against the use case.

 

However, I don't think this= WG or the v2 specification are the right place to address it.

 

EHL

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480C92CH1PRD0302MB115_-- From eran@hueniverse.com Fri Apr 22 15:25:09 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 52B59E079D for ; Fri, 22 Apr 2011 15:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pmDqcI9h14p for ; Fri, 22 Apr 2011 15:24:52 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id 7EAA0E076C for ; Fri, 22 Apr 2011 15:24:52 -0700 (PDT) Received: (qmail 23131 invoked from network); 22 Apr 2011 22:24:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Apr 2011 22:24:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 22 Apr 2011 15:24:50 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , Dick Hardt Date: Fri, 22 Apr 2011 15:24:46 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: AcwBPBgMrTreAgUoRnuL9zlmNYscDg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9D748FE11633eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 22 Apr 2011 22:25:09 -0000 --_000_C9D748FE11633eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Anthony Nadalin > Date: Fri, 22 Apr 2011 14:51:33 -0700 AJN-> So the client credentials originate from WRAP also, it=92s not comple= tely new, it may be new the way that it got worded but the same functionali= ty was in WRAP. The section 5.2 (and subsections) in the WAP specification= is where you see the assertion documented but what is not explicitly state= d (other than additional parameters clause)there but not disallowed is the = ability to have the access_token (additional parameters) also specified so = you were allowed to have 2 assertions in WRAP for authentication It is completely new. The two assertions functionality is certainly NOT in WRAP. It is not even h= inted at. Seems to me you just made my case for dropping this issue. If this is your = rational for adding two assertions support in v2, then we can be done right= now. v2 already gives you the exact same 'additional parameters' support a= nd does not disallow two assertions. You have made statements in the past t= hat WRAP did everything you needed and that v2 has to cover the same scope. Well, it already does. We can certainly continue to debate whether v2 needs to address this new us= e case, and if so how to accomplish it, but that is based solely on new req= uirements and is an expansion of the agreed protocol scope (WRAP + OAuth 1.= 0). EHL --_000_C9D748FE11633eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


<= span style=3D"font-weight:bold">From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 22 Apr 2011 14:51:33 -0700
<= /div>

AJN-> So the client credentials origin= ate from WRAP also, it=92s not completely new, it may be new the way that i= t got worded but the same functionality was in WRAP. The  section 5.2 (and subsections) in the WAP specification is = where you see the assertion documented but what is not explicitly stated (o= ther than additional parameters clause)there but not disallowed is the abil= ity to have the access_token (additional parameters) also specified so you were allowed to have 2 assertions in WRA= P for authentication

<= br>
It is completely new.

The two assert= ions functionality is certainly NOT in WRAP. It is not even hinted at.

Seems to me you just made my case for dropping this is= sue. If this is your rational for adding two assertions support in v2, then= we can be done right now. v2 already gives you the exact same 'additional = parameters' support and does not disallow two assertions. You have made sta= tements in the past that WRAP did everything you needed and that v2 has to = cover the same scope.

Well, it already does.
=

We can certainly continue to debate whether v2 needs to= address this new use case, and if so how to accomplish it, but that is bas= ed solely on new requirements and is an expansion of the agreed protocol sc= ope (WRAP + OAuth 1.0).

EHL


--_000_C9D748FE11633eranhueniversecom_-- From tonynad@microsoft.com Fri Apr 22 15:34:30 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 494C4E0757 for ; Fri, 22 Apr 2011 15:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.016 X-Spam-Level: X-Spam-Status: No, score=-7.016 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgWvgGVgkJHL for ; Fri, 22 Apr 2011 15:34:28 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id C09D3E068E for ; Fri, 22 Apr 2011 15:34:27 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 22 Apr 2011 15:34:26 -0700 Received: from VA3EHSOBE005.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 22 Apr 2011 15:34:26 -0700 Received: from mail46-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.8; Fri, 22 Apr 2011 22:34:25 +0000 Received: from mail46-va3 (localhost.localdomain [127.0.0.1]) by mail46-va3-R.bigfish.com (Postfix) with ESMTP id 7D52314C0107 for ; Fri, 22 Apr 2011 22:34:25 +0000 (UTC) X-SpamScore: -9 X-BigFish: PS-9(zz9371OzzdafM1202h1082kzz8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT006.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail46-va3 (localhost.localdomain [127.0.0.1]) by mail46-va3 (MessageSwitch) id 1303511664872772_32265; Fri, 22 Apr 2011 22:34:24 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.236]) by mail46-va3.bigfish.com (Postfix) with ESMTP id C7AB09E0093; Fri, 22 Apr 2011 22:34:24 +0000 (UTC) Received: from CH1PRD0302HT006.namprd03.prod.outlook.com (207.46.198.24) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 22 Apr 2011 22:34:24 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.221]) by CH1PRD0302HT006.namprd03.prod.outlook.com ([10.28.29.125]) with mapi id 14.01.0225.042; Fri, 22 Apr 2011 22:34:23 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , Dick Hardt Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAB2/gYAAA7I5gAADPdkAAAF71YAAAvT6gAABnOkAAAAhFQAAAJ1bAAABBRIAAAIBpIAAATynAAAAMeuAACk2iiAADuGQAAAm7+iAAAIawIAALNYVsAALpPcAAAAY5aA= Date: Fri, 22 Apr 2011 22:34:23 +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: [10.28.29.165] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480CF1CH1PRD0302MB115_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT006.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 22 Apr 2011 22:34:30 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480CF1CH1PRD0302MB115_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I disagree here, this is not new or even completely new use case as this wa= s in WRAP as we are using this feature now. I would agree that it's not ver= y well documented but that was attempted by Yaron in his append was to clar= ify the support. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, April 22, 2011 3:25 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 From: Anthony Nadalin > Date: Fri, 22 Apr 2011 14:51:33 -0700 AJN-> So the client credentials originate from WRAP also, it's not complete= ly new, it may be new the way that it got worded but the same functionality= was in WRAP. The section 5.2 (and subsections) in the WAP specification i= s where you see the assertion documented but what is not explicitly stated = (other than additional parameters clause)there but not disallowed is the ab= ility to have the access_token (additional parameters) also specified so yo= u were allowed to have 2 assertions in WRAP for authentication It is completely new. The two assertions functionality is certainly NOT in WRAP. It is not even h= inted at. Seems to me you just made my case for dropping this issue. If this is your = rational for adding two assertions support in v2, then we can be done right= now. v2 already gives you the exact same 'additional parameters' support a= nd does not disallow two assertions. You have made statements in the past t= hat WRAP did everything you needed and that v2 has to cover the same scope. Well, it already does. We can certainly continue to debate whether v2 needs to address this new us= e case, and if so how to accomplish it, but that is based solely on new req= uirements and is an expansion of the agreed protocol scope (WRAP + OAuth 1.= 0). EHL --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480CF1CH1PRD0302MB115_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I disagree here, this is = not new or even completely new use case as this was in WRAP as we are using= this feature now. I would agree that it’s not very well documented but that was attempted by Yaron in his append was to clarify th= e support.

 <= /p>

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Friday, April 22, 2011 3:25 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

 

 

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 22 Apr 2011 14:51:33 -0700

 

AJN-> So the client credentials originate from WRAP also, itR= 17;s not completely new, it may be new the way that it got worded but the same functionality was in WRAP. The  section 5.2 (and subsections= ) in the WAP specification is where you see the assertion documented but wh= at is not explicitly stated (other than additional parameters clause)there = but not disallowed is the ability to have the access_token (additional parameters) also specified so you were a= llowed to have 2 assertions in WRAP for authentication

 

It is completely new.<= /o:p>

 

The two assertions function= ality is certainly NOT in WRAP. It is not even hinted at.=

 

Seems to me you just made m= y case for dropping this issue. If this is your rational for adding two ass= ertions support in v2, then we can be done right now. v2 already gives you the exact same 'additional parameters' support and does = not disallow two assertions. You have made statements in the past that WRAP= did everything you needed and that v2 has to cover the same scope.

 

Well, it already does.=

 

We can certainly continue t= o debate whether v2 needs to address this new use case, and if so how to ac= complish it, but that is based solely on new requirements and is an expansion of the agreed protocol scope (WRAP + OAuth 1.0).

 

EHL

 

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480CF1CH1PRD0302MB115_-- From eran@hueniverse.com Fri Apr 22 15:40:07 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6475CE0727 for ; Fri, 22 Apr 2011 15:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bg7qYDkWTO1e for ; Fri, 22 Apr 2011 15:40:04 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id 50577E0685 for ; Fri, 22 Apr 2011 15:40:04 -0700 (PDT) Received: (qmail 9642 invoked from network); 22 Apr 2011 22:40:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Apr 2011 22:40:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 22 Apr 2011 15:40:03 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , Dick Hardt Date: Fri, 22 Apr 2011 15:39:51 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAB2/gYAAA7I5gAADPdkAAAF71YAAAvT6gAABnOkAAAAhFQAAAJ1bAAABBRIAAAIBpIAAATynAAAAMeuAACk2iiAADuGQAAAm7+iAAAIawIAALNYVsAALpPcAAAAY5aAAAEP/cA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BBF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723447535BBF8FP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 22 Apr 2011 22:40:07 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447535BBF8FP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let me make sure we're clear here: Your argument is that this is not a new use case because WRAP allows 'addit= ional parameters' and doesn't explicitly forbids it? If I missed something, please quote the exact normative language in WRAP sh= owing how to use two assertions, or any text differentiating between using = an assertion for client authentication vs. using an assertion for resource = owner authorization. Show me anything that pre-dates Yaron's text documenti= ng the two assertions use case. EHL From: Anthony Nadalin [mailto:tonynad@microsoft.com] Sent: Friday, April 22, 2011 3:34 PM To: Eran Hammer-Lahav; Dick Hardt Cc: OAuth WG Subject: RE: [OAUTH-WG] Revised Section 3 I disagree here, this is not new or even completely new use case as this wa= s in WRAP as we are using this feature now. I would agree that it's not ver= y well documented but that was attempted by Yaron in his append was to clar= ify the support. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, April 22, 2011 3:25 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 From: Anthony Nadalin > Date: Fri, 22 Apr 2011 14:51:33 -0700 AJN-> So the client credentials originate from WRAP also, it's not complete= ly new, it may be new the way that it got worded but the same functionality= was in WRAP. The section 5.2 (and subsections) in the WAP specification i= s where you see the assertion documented but what is not explicitly stated = (other than additional parameters clause)there but not disallowed is the ab= ility to have the access_token (additional parameters) also specified so yo= u were allowed to have 2 assertions in WRAP for authentication It is completely new. The two assertions functionality is certainly NOT in WRAP. It is not even h= inted at. Seems to me you just made my case for dropping this issue. If this is your = rational for adding two assertions support in v2, then we can be done right= now. v2 already gives you the exact same 'additional parameters' support a= nd does not disallow two assertions. You have made statements in the past t= hat WRAP did everything you needed and that v2 has to cover the same scope. Well, it already does. We can certainly continue to debate whether v2 needs to address this new us= e case, and if so how to accomplish it, but that is based solely on new req= uirements and is an expansion of the agreed protocol scope (WRAP + OAuth 1.= 0). EHL --_000_90C41DD21FB7C64BB94121FBBC2E723447535BBF8FP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let me ma= ke sure we’re clear here:

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

Your argument= is that this is not a new use case because WRAP allows ‘additional p= arameters’ and doesn’t explicitly forbids it?=

 

If I missed something, please quote the exact normative langua= ge in WRAP showing how to use two assertions, or any text differentiating b= etween using an assertion for client authentication vs. using an assertion = for resource owner authorization. Show me anything that pre-dates YaronR= 17;s text documenting the two assertions use case.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>EHL

 

 

=

From: Anthony Nadalin [mailto:tonynad@micr= osoft.com]
Sent: Friday, April 22, 2011 3:34 PM
To: Er= an Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [= OAUTH-WG] Revised Section 3

 

I disagree here, th= is is not new or even completely new use case as this was in WRAP as we are= using this feature now. I would agree that it’s not very well docume= nted but that was attempted by Yaron in his append was to clarify the suppo= rt.

 

From: Eran Hammer-Lahav [mailto:era= n@hueniverse.com]
Sent: Friday, April 22, 2011 3:25 PM
To:= Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: = Re: [OAUTH-WG] Revised Section 3

 

 = ;

 

From: A= nthony Nadalin <tonynad@microso= ft.com>
Date: Fri, 22 Apr 2011 14:51:33 -0700

 

<= /div>

AJN-> So the cli= ent credentials originate from WRAP also, it’s not completely new, it= may be new the way that it got worded but the same functionality was in WR= AP. The  section 5.2 (and subsections) in the WAP specification is whe= re you see the assertion documented but what is not explicitly stated (othe= r than additional parameters clause)there but not disallowed is the ability= to have the access_token (additional parameters) also specified so you wer= e allowed to have 2 assertions in WRAP for authentication

 

It is completely new.

 

The two assertions functionality is certainly NOT in WRAP. It = is not even hinted at.

 

Seem= s to me you just made my case for dropping this issue. If this is your rati= onal for adding two assertions support in v2, then we can be done right now= . v2 already gives you the exact same 'additional parameters' support and d= oes not disallow two assertions. You have made statements in the past that = WRAP did everything you needed and that v2 has to cover the same scope.

 

Well, it already does.

 =

We can certainly continue to debat= e whether v2 needs to address this new use case, and if so how to accomplis= h it, but that is based solely on new requirements and is an expansion of t= he agreed protocol scope (WRAP + OAuth 1.0).

 

EHL

=  

=  

= --_000_90C41DD21FB7C64BB94121FBBC2E723447535BBF8FP3PW5EX1MB01E_-- From tonynad@microsoft.com Fri Apr 22 15:45:38 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C273EE066B for ; Fri, 22 Apr 2011 15:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.166 X-Spam-Level: X-Spam-Status: No, score=-7.166 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7UsYlWMq06A for ; Fri, 22 Apr 2011 15:45:35 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id 41DF7E065F for ; Fri, 22 Apr 2011 15:45:35 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 22 Apr 2011 15:45:34 -0700 Received: from TX2EHSOBE001.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 22 Apr 2011 15:45:34 -0700 Received: from mail145-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.8; Fri, 22 Apr 2011 22:45:33 +0000 Received: from mail145-tx2 (localhost.localdomain [127.0.0.1]) by mail145-tx2-R.bigfish.com (Postfix) with ESMTP id 6A6D11A10451 for ; Fri, 22 Apr 2011 22:45:33 +0000 (UTC) X-SpamScore: -9 X-BigFish: PS-9(zz9371OzzdafM1202h1082kzz8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail145-tx2 (localhost.localdomain [127.0.0.1]) by mail145-tx2 (MessageSwitch) id 1303512332760253_15767; Fri, 22 Apr 2011 22:45:32 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.242]) by mail145-tx2.bigfish.com (Postfix) with ESMTP id B46DF10053; Fri, 22 Apr 2011 22:45:32 +0000 (UTC) Received: from CH1PRD0302HT004.namprd03.prod.outlook.com (157.55.61.146) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 22 Apr 2011 22:45:27 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.221]) by CH1PRD0302HT004.namprd03.prod.outlook.com ([10.28.29.123]) with mapi id 14.01.0225.042; Fri, 22 Apr 2011 22:45:27 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , Dick Hardt Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAB2/gYAAA7I5gAADPdkAAAF71YAAAvT6gAABnOkAAAAhFQAAAJ1bAAABBRIAAAIBpIAAATynAAAAMeuAACk2iiAADuGQAAAm7+iAAAIawIAALNYVsAALpPcAAAAY5aAAAEP/cAAANtkA Date: Fri, 22 Apr 2011 22:45:25 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723447535BBF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BBF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.165] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480D35CH1PRD0302MB115_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 22 Apr 2011 22:45:38 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480D35CH1PRD0302MB115_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not sure I have to show you anything. The WRAP specification does not precl= ude the usage of 2 assertions as this was one of the must support use cases= for WRAP. As I indicated this was not the best spelled out feature in the = WRAP specification. Yaron's append was an attempt to clarify the use case w= ith additional text. If you want to come on site you can see the code and t= he dates on the code that predates Yaron's text. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, April 22, 2011 3:40 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG Subject: RE: [OAUTH-WG] Revised Section 3 Let me make sure we're clear here: Your argument is that this is not a new use case because WRAP allows 'addit= ional parameters' and doesn't explicitly forbids it? If I missed something, please quote the exact normative language in WRAP sh= owing how to use two assertions, or any text differentiating between using = an assertion for client authentication vs. using an assertion for resource = owner authorization. Show me anything that pre-dates Yaron's text documenti= ng the two assertions use case. EHL From: Anthony Nadalin [mailto:tonynad@microsoft.com] Sent: Friday, April 22, 2011 3:34 PM To: Eran Hammer-Lahav; Dick Hardt Cc: OAuth WG Subject: RE: [OAUTH-WG] Revised Section 3 I disagree here, this is not new or even completely new use case as this wa= s in WRAP as we are using this feature now. I would agree that it's not ver= y well documented but that was attempted by Yaron in his append was to clar= ify the support. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, April 22, 2011 3:25 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 From: Anthony Nadalin > Date: Fri, 22 Apr 2011 14:51:33 -0700 AJN-> So the client credentials originate from WRAP also, it's not complete= ly new, it may be new the way that it got worded but the same functionality= was in WRAP. The section 5.2 (and subsections) in the WAP specification i= s where you see the assertion documented but what is not explicitly stated = (other than additional parameters clause)there but not disallowed is the ab= ility to have the access_token (additional parameters) also specified so yo= u were allowed to have 2 assertions in WRAP for authentication It is completely new. The two assertions functionality is certainly NOT in WRAP. It is not even h= inted at. Seems to me you just made my case for dropping this issue. If this is your = rational for adding two assertions support in v2, then we can be done right= now. v2 already gives you the exact same 'additional parameters' support a= nd does not disallow two assertions. You have made statements in the past t= hat WRAP did everything you needed and that v2 has to cover the same scope. Well, it already does. We can certainly continue to debate whether v2 needs to address this new us= e case, and if so how to accomplish it, but that is based solely on new req= uirements and is an expansion of the agreed protocol scope (WRAP + OAuth 1.= 0). EHL --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480D35CH1PRD0302MB115_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not sure I have to show y= ou anything. The WRAP specification does not preclude the usage of 2 assert= ions as this was one of the must support use cases for WRAP. As I indicated this was not the best spelled out feature in the WRAP speci= fication. Yaron’s append was an attempt to clarify the use case with = additional text. If you want to come on site you can see the code and the d= ates on the code that predates Yaron’s text.

 <= /p>

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Friday, April 22, 2011 3:40 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3

 

Let me make sure we’= ;re clear here:

 <= /p>

Your argument is that thi= s is not a new use case because WRAP allows ‘additional parameters= 217; and doesn’t explicitly forbids it?

 <= /p>

If I missed something, pl= ease quote the exact normative language in WRAP showing how to use two asse= rtions, or any text differentiating between using an assertion for client authentication vs. using an assertion for resource owner author= ization. Show me anything that pre-dates Yaron’s text documenting the= two assertions use case.

 <= /p>

EHL

 <= /p>

 <= /p>

From: Anthony = Nadalin [mailto:tonynad@microsoft= .com]
Sent: Friday, April 22, 2011 3:34 PM
To: Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3

 

I disagree here, this is = not new or even completely new use case as this was in WRAP as we are using= this feature now. I would agree that it’s not very well documented but that was attempted by Yaron in his append was to clarify th= e support.

 <= /p>

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com= ]
Sent: Friday, April 22, 2011 3:25 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

 

 

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 22 Apr 2011 14:51:33 -0700

 

AJN-> So the client credentials originate from WRAP also, itR= 17;s not completely new, it may be new the way that it got worded but the same functionality was in WRAP. The  section 5.2 (and subsections= ) in the WAP specification is where you see the assertion documented but wh= at is not explicitly stated (other than additional parameters clause)there = but not disallowed is the ability to have the access_token (additional parameters) also specified so you were a= llowed to have 2 assertions in WRAP for authentication

 

It is completely new.<= /o:p>

 

The two assertions function= ality is certainly NOT in WRAP. It is not even hinted at.=

 

Seems to me you just made m= y case for dropping this issue. If this is your rational for adding two ass= ertions support in v2, then we can be done right now. v2 already gives you the exact same 'additional parameters' support and does = not disallow two assertions. You have made statements in the past that WRAP= did everything you needed and that v2 has to cover the same scope.

 

Well, it already does.=

 

We can certainly continue t= o debate whether v2 needs to address this new use case, and if so how to ac= complish it, but that is based solely on new requirements and is an expansion of the agreed protocol scope (WRAP + OAuth 1.0).

 

EHL

 

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480D35CH1PRD0302MB115_-- From wwwrun@ietfc.amsl.com Fri Apr 22 15:47:46 2011 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id 83D26E068E; Fri, 22 Apr 2011 15:47:46 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110422224746.83D26E068E@ietfc.amsl.com> Date: Fri, 22 Apr 2011 15:47:46 -0700 (PDT) Cc: oauth@ietf.org Subject: [OAUTH-WG] OAUTH WG Interim Meeting, May 23, 2011 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, 22 Apr 2011 22:47:46 -0000 The OAUTH Working Group will hold a 1-day interim meeting as follows: Date: 23rd May, 2011 (9am - 6pm) Location: Mountain View, CA, US Host: TBD Agenda: Discussion of remaining open issues with the OAuth 2.0 specification, and other working group items. Further details will be posted to the OAUTH mailing list (http://www.ietf.org/mail-archive/web/oauth/) as soon as available. From wmills@yahoo-inc.com Fri Apr 22 16:09:40 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4E632E067F for ; Fri, 22 Apr 2011 16:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.998 X-Spam-Level: X-Spam-Status: No, score=-16.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWme9iZbnRsW for ; Fri, 22 Apr 2011 16:09:39 -0700 (PDT) Received: from nm20-vm0.bullet.mail.sp2.yahoo.com (nm20-vm0.bullet.mail.sp2.yahoo.com [98.139.91.218]) by ietfc.amsl.com (Postfix) with SMTP id C0D67E066E for ; Fri, 22 Apr 2011 16:09:38 -0700 (PDT) Received: from [98.139.91.70] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 22 Apr 2011 23:09:35 -0000 Received: from [98.139.91.38] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 22 Apr 2011 23:09:34 -0000 Received: from [127.0.0.1] by omp1038.mail.sp2.yahoo.com with NNFMP; 22 Apr 2011 23:09:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 910993.49253.bm@omp1038.mail.sp2.yahoo.com Received: (qmail 72433 invoked by uid 60001); 22 Apr 2011 23:09:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1303513774; bh=XGjk2snSWNxQ6vpcfjCn+pHOlovNq9GGu1KEC/SBrNE=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=o9d/J5rDYOlPJigZ/d15i5vf6TyZJWUyl1miO4IJmEAFJEH7Dq4qD/mnm2Qt/U8wCBogm+GrkI8XZEs+oL5xBCHdIrjvRSVW5rJArBlTJnFI5ZLgf+0fx5lZrxSjamZTsPpORd7RFGdQccCEsWsAWzqotg3DCX1OAZyZo6mPqhM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nndkMfI1kRgzhcCXpqdE6mEuMp+q8Y9t/VSBkUDGq99pO2/95VcCN+6Z/jcM2O4ZRIkIpUM2LFawtfkA+CgackFOwQafuYmcBlXhU1seVCEmzL5b/QSmtYAf/AIsNxonwr3o+BQbCw3K+OU/TGnQmeCSUHHjGKN4qPmPxUfH+mo=; Message-ID: <242018.69896.qm@web31811.mail.mud.yahoo.com> X-YMail-OSG: dHDDwHMVM1kk1B2jGbgZUqga3xjhgGtjovmqysDI8471zMj Y7JSviYzE0wJ7VwqqvTuiPs9O6adEC0_kpG2xZKHsKE.p9.313SXcAsUpnbg 3A2dlb7yggxxI2uiXtE0YZY9L1h2LvWfUSwplop8jT3Zfbek52xWAEHUTJO9 vuLbA5vqIsaTI.a0adePRuiZYT3y98ph10p4w4cIO6i7PcToP69bQQIS1r1L JHLAG7_jnEYX1BhPR4QvrnADxWKh.IEUWpDwYjlEBNic.HVLngxD_50uPTzi XtISk9Zltzhhjtrvt8xrM7FcdIU_tYwty8uPGRvxAafwUR6QSaujTvONsfvj n5GDb5flc.oHD2pUTkmypqXn3Bx5jblEHFyheZgcW Received: from [209.131.62.115] by web31811.mail.mud.yahoo.com via HTTP; Fri, 22 Apr 2011 16:09:33 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.111.303096 References: <90C41DD21FB7C64BB94121FBBC2E723447535BBF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 22 Apr 2011 16:09:33 -0700 (PDT) From: "William J. Mills" To: Anthony Nadalin , Eran Hammer-Lahav , Dick Hardt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2001306941-1303513773=:69896" Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 23:09:40 -0000 --0-2001306941-1303513773=:69896 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable That WRAP allowed extension and that someone extended with a second asserti= on does not imply that a second assertion is provided for in WRAP.=C2=A0 It= means that WRAP allowed extension.=C2=A0 AQre we trying to bring that exte= nsion into the main spec as a needed use case?=0A=0A=0A=0A_________________= _______________=0AFrom: Anthony Nadalin =0ATo: Eran = Hammer-Lahav ; Dick Hardt =0ACc:= OAuth WG =0ASent: Friday, April 22, 2011 3:45 PM=0ASubject= : Re: [OAUTH-WG] Revised Section 3=0A=0A=0A =0ANot sure I have to show you = anything. The WRAP specification does not preclude the usage of 2 assertion= s as this was one of the must support use cases for WRAP. As I indicated th= is was not the best spelled out feature in the WRAP specification. Yaron=E2= =80=99s append was an attempt to clarify the use case with additional text.= If you want to come on site you can see the code and the dates on the code= that predates Yaron=E2=80=99s text. =0A=C2=A0=0AFrom:Eran Hammer-Lahav [ma= ilto:eran@hueniverse.com] =0ASent: Friday, April 22, 2011 3:40 PM=0ATo: Ant= hony Nadalin; Dick Hardt=0ACc: OAuth WG=0ASubject: RE: [OAUTH-WG] Revised S= ection 3=0A=C2=A0=0ALet me make sure we=E2=80=99re clear here:=0A=C2=A0=0AY= our argument is that this is not a new use case because WRAP allows =E2=80= =98additional parameters=E2=80=99 and doesn=E2=80=99t explicitly forbids it= ?=0A=C2=A0=0AIf I missed something, please quote the exact normative langua= ge in WRAP showing how to use two assertions, or any text differentiating b= etween using an assertion for client authentication vs. using an assertion = for resource owner authorization. Show me anything that pre-dates Yaron=E2= =80=99s text documenting the two assertions use case.=0A=C2=A0=0AEHL=0A=C2= =A0=0A=C2=A0=0AFrom:Anthony Nadalin [mailto:tonynad@microsoft.com] =0ASent:= Friday, April 22, 2011 3:34 PM=0ATo: Eran Hammer-Lahav; Dick Hardt=0ACc: O= Auth WG=0ASubject: RE: [OAUTH-WG] Revised Section 3=0A=C2=A0=0AI disagree h= ere, this is not new or even completely new use case as this was in WRAP as= we are using this feature now. I would agree that it=E2=80=99s not very we= ll documented but that was attempted by Yaron in his append was to clarify = the support. =0A=C2=A0=0AFrom:Eran Hammer-Lahav [mailto:eran@hueniverse.com= ] =0ASent: Friday, April 22, 2011 3:25 PM=0ATo: Anthony Nadalin; Dick Hardt= =0ACc: OAuth WG=0ASubject: Re: [OAUTH-WG] Revised Section 3=0A=C2=A0=0A=C2= =A0=0A=C2=A0=0AFrom: Anthony Nadalin =0ADate: Fri, 2= 2 Apr 2011 14:51:33 -0700=0A=C2=A0=0AAJN-> So the client credentials origin= ate from WRAP also, it=E2=80=99s not completely new, it may be new the way = that it got worded but the same functionality was in WRAP. The=C2=A0 sectio= n 5.2 (and subsections) in the WAP specification is where you see the asser= tion documented but what is not explicitly stated (other than additional pa= rameters clause)there but not disallowed is the ability to have the access_= token (additional parameters) also specified so you were allowed to have 2 = assertions in WRAP for authentication=0A=C2=A0=0AIt is completely new.=0A= =C2=A0=0AThe two assertions functionality is certainly NOT in WRAP. It is n= ot even hinted at.=0A=C2=A0=0ASeems to me you just made my case for droppin= g this issue. If this is your rational for adding two assertions support in= v2, then we can be done right now. v2 already gives you the exact same 'ad= ditional parameters' support and does not disallow two assertions. You have= made statements in the past that WRAP did everything you needed and that v= 2 has to cover the same scope.=0A=C2=A0=0AWell, it already does.=0A=C2=A0= =0AWe can certainly continue to debate whether v2 needs to address this new= use case, and if so how to accomplish it, but that is based solely on new = requirements and is an expansion of the agreed protocol scope (WRAP + OAuth= 1.0).=0A=C2=A0=0AEHL=0A=C2=A0=0A=C2=A0=0A_________________________________= ______________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org= /mailman/listinfo/oauth --0-2001306941-1303513773=:69896 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
That WRAP allowed extension and that someone extended with a second asser= tion does not imply that a second assertion is provided for in WRAP.  = It means that WRAP allowed extension.  AQre we trying to bring that ex= tension into the main spec as a needed use case?

<= /div>
From: Anthony Nadalin = <tonynad@microsoft.com>
To:<= /span> Eran Hammer-Lahav <eran@hueniverse.com>; Dick Hardt <di= ck.hardt@gmail.com>
Cc:<= /b> OAuth WG <oauth@ietf.org>
Sent: Friday, April 22, 2011 3:45 PM
Subject: Re: [OAUTH-WG] Revised Section 3

= =0A
=0A=0A =0A =0A=0A
=0A
Not sure I have to show you any= thing. The WRAP specification does not preclude the usage of 2 assertions a= s this was one of the must support use cases for WRAP.=0A As I indicated th= is was not the best spelled out feature in the WRAP specification. Yaron=E2= =80=99s append was an attempt to clarify the use case with additional text.= If you want to come on site you can see the code and the dates on the code= that predates Yaron=E2=80=99s=0A text.
=0A
 
=0A
=0A
=0A
From: Eran Hammer= -Lahav [mailto:eran@hueniverse.com]=0A
=0ASent: Friday, April 22,= 2011 3:40 PM
=0ATo: Anthony Nadalin; Dick Hardt
=0ACc:= OAuth WG
=0ASubject: RE: [OAUTH-WG] Revised Section 3 =0A
=0A
=0A
 
= =0A
Let me make sure we=E2=80=99re clear here:<= /div> =0A
 
=0A
= Your argument is that this is not a new use case because WRAP allows =E2=80= =98additional parameters=E2=80=99 and doesn=E2=80=99t explicitly forbids it= ?
=0A
 
=0A
If I missed something, please quote the exact normative language= in WRAP showing how to use two assertions, or any text differentiating bet= ween using an assertion=0A for client authentication vs. using an assertion= for resource owner authorization. Show me anything that pre-dates Yaron=E2= =80=99s text documenting the two assertions use case.
=0A
 
=0A
EHL =0A
 
=0A
&n= bsp;
=0A
=0A=0A
=0A
From: Anthony Nadalin=0A[mailto:tonynad@microsoft.com]=0A=
=0ASent: Friday, April 22, 2011 3:34 PM
=0ATo: Eran Ha= mmer-Lahav; Dick Hardt
=0ACc: OAuth WG
=0ASubject: RE: = [OAUTH-WG] Revised Section 3
=0A
=0A
=0A
 
=0A
I disagre= e here, this is not new or even completely new use case as this was in WRAP= as we are using this feature now. I would agree that it=E2=80=99s not very= well=0A documented but that was attempted by Yaron in his append was to cl= arify the support.=0A
=0A
  =0A=0A
=0A
 
=0A
=0A
 
=0A
=0A
=0A
 
=0A
= =0A
=0A
From= :=0AAnthony Nadal= in <tonynad@microsoft.com= >
=0ADate: Fri, 22 Apr 2011 14:51:33 -0700
=0A=0A
=0A
 
=0A
=0A
=0A
=0A=0A
= AJN-> So the client credentials originate from WRAP also, it=E2=80=99s n= ot completely new, it may be new the way that it got worded but=0A the same= functionality was in WRAP. The  section 5.2 (and subsections) in the = WAP specification is where you see the assertion documented but what is not= explicitly stated (other than additional parameters clause)there but not d= isallowed is the ability to=0A have the access_token (additional parameters= ) also specified so you were allowed to have 2 assertions in WRAP for authe= ntication
=0A=0A
=0A
=0A
=0A
=  
=0A=0A
=0A
It is completely new.
=0A
=0A<= div>=0A
 
=0A
=0A
=0A
The= two assertions functionality is certainly NOT in WRAP. It is not even hint= ed at.
=0A
=0A
=0A
 
= =0A
=0A
=0A
Seems to me you just made my case for dropp= ing this issue. If this is your rational for adding two assertions support = in v2, then we can be done right now. v2=0A already gives you the exact sam= e 'additional parameters' support and does not disallow two assertions. You= have made statements in the past that WRAP did everything you needed and t= hat v2 has to cover the same scope.
=0A
=0A
=0A
 
=0A
=0A
=0A
Well, it already= does.
=0A
=0A
=0A
 
= =0A
=0A
=0A
We can certainly continue to debate whether= v2 needs to address this new use case, and if so how to accomplish it, but= that is based solely on new requirements=0A and is an expansion of the agr= eed protocol scope (WRAP + OAuth 1.0).
=0A
=0A
=0A  
=0A
=0A
=0A
EHL =0A
=0A
=0A
 
=0A
=0A=0A
 
=0A
=0A
=0A
=0A =0A
__________= _____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


=
--0-2001306941-1303513773=:69896-- From tonynad@microsoft.com Fri Apr 22 16:12:17 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3E4ADE0669 for ; Fri, 22 Apr 2011 16:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.016 X-Spam-Level: X-Spam-Status: No, score=-7.016 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq0CLKYdFl8U for ; Fri, 22 Apr 2011 16:12:15 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id 34CAEE065F for ; Fri, 22 Apr 2011 16:12:15 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 22 Apr 2011 16:12:13 -0700 Received: from VA3EHSOBE009.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 22 Apr 2011 16:12:14 -0700 Received: from mail63-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.8; Fri, 22 Apr 2011 23:12:13 +0000 Received: from mail63-va3 (localhost.localdomain [127.0.0.1]) by mail63-va3-R.bigfish.com (Postfix) with ESMTP id 1947AA381B3 for ; Fri, 22 Apr 2011 23:12:13 +0000 (UTC) X-SpamScore: -29 X-BigFish: PS-29(zz9371OzzdafM1202h1082kzz8275bh8275dh1033ILz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail63-va3 (localhost.localdomain [127.0.0.1]) by mail63-va3 (MessageSwitch) id 1303513928891538_15963; Fri, 22 Apr 2011 23:12:08 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.253]) by mail63-va3.bigfish.com (Postfix) with ESMTP id C81FE228050; Fri, 22 Apr 2011 23:12:08 +0000 (UTC) Received: from CH1PRD0302HT002.namprd03.prod.outlook.com (157.55.61.146) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 22 Apr 2011 23:12:01 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.221]) by CH1PRD0302HT002.namprd03.prod.outlook.com ([10.28.28.64]) with mapi id 14.01.0225.042; Fri, 22 Apr 2011 23:11:59 +0000 From: Anthony Nadalin To: "William J. Mills" , Eran Hammer-Lahav , Dick Hardt Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAB2/gYAAA7I5gAADPdkAAAF71YAAAvT6gAABnOkAAAAhFQAAAJ1bAAABBRIAAAIBpIAAATynAAAAMeuAACk2iiAADuGQAAAm7+iAAAIawIAALNYVsAALpPcAAAAY5aAAAEP/cAAANtkAAAD8qIAAAA/YwA== Date: Fri, 22 Apr 2011 23:11:59 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723447535BBF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <242018.69896.qm@web31811.mail.mud.yahoo.com> In-Reply-To: <242018.69896.qm@web31811.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.165] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480DDBCH1PRD0302MB115_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%YAHOO-INC.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 22 Apr 2011 23:12:17 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480DDBCH1PRD0302MB115_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgaXMgbm8gZXh0ZW5zaW9uIGluIFdSQVAgdG8gYWxsb3cgdGhpcywgaXTigJlzIGFsbG93 ZWQgYXMgcGFydCBvZiBXUkFQLg0KDQpGcm9tOiBXaWxsaWFtIEouIE1pbGxzIFttYWlsdG86d21p bGxzQHlhaG9vLWluYy5jb21dDQpTZW50OiBGcmlkYXksIEFwcmlsIDIyLCAyMDExIDQ6MTAgUE0N ClRvOiBBbnRob255IE5hZGFsaW47IEVyYW4gSGFtbWVyLUxhaGF2OyBEaWNrIEhhcmR0DQpDYzog T0F1dGggV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJldmlzZWQgU2VjdGlvbiAzDQoNClRo YXQgV1JBUCBhbGxvd2VkIGV4dGVuc2lvbiBhbmQgdGhhdCBzb21lb25lIGV4dGVuZGVkIHdpdGgg YSBzZWNvbmQgYXNzZXJ0aW9uIGRvZXMgbm90IGltcGx5IHRoYXQgYSBzZWNvbmQgYXNzZXJ0aW9u IGlzIHByb3ZpZGVkIGZvciBpbiBXUkFQLiAgSXQgbWVhbnMgdGhhdCBXUkFQIGFsbG93ZWQgZXh0 ZW5zaW9uLiAgQVFyZSB3ZSB0cnlpbmcgdG8gYnJpbmcgdGhhdCBleHRlbnNpb24gaW50byB0aGUg bWFpbiBzcGVjIGFzIGEgbmVlZGVkIHVzZSBjYXNlPw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRnJvbTogQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb208 bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+DQpUbzogRXJhbiBIYW1tZXItTGFoYXYgPGVy YW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PjsgRGljayBIYXJk dCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkNj OiBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClNlbnQ6 IEZyaWRheSwgQXByaWwgMjIsIDIwMTEgMzo0NSBQTQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g UmV2aXNlZCBTZWN0aW9uIDMNCg0KDQpOb3Qgc3VyZSBJIGhhdmUgdG8gc2hvdyB5b3UgYW55dGhp bmcuIFRoZSBXUkFQIHNwZWNpZmljYXRpb24gZG9lcyBub3QgcHJlY2x1ZGUgdGhlIHVzYWdlIG9m IDIgYXNzZXJ0aW9ucyBhcyB0aGlzIHdhcyBvbmUgb2YgdGhlIG11c3Qgc3VwcG9ydCB1c2UgY2Fz ZXMgZm9yIFdSQVAuIEFzIEkgaW5kaWNhdGVkIHRoaXMgd2FzIG5vdCB0aGUgYmVzdCBzcGVsbGVk IG91dCBmZWF0dXJlIGluIHRoZSBXUkFQIHNwZWNpZmljYXRpb24uIFlhcm9u4oCZcyBhcHBlbmQg d2FzIGFuIGF0dGVtcHQgdG8gY2xhcmlmeSB0aGUgdXNlIGNhc2Ugd2l0aCBhZGRpdGlvbmFsIHRl eHQuIElmIHlvdSB3YW50IHRvIGNvbWUgb24gc2l0ZSB5b3UgY2FuIHNlZSB0aGUgY29kZSBhbmQg dGhlIGRhdGVzIG9uIHRoZSBjb2RlIHRoYXQgcHJlZGF0ZXMgWWFyb27igJlzIHRleHQuDQoNCkZy b206IEVyYW4gSGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV08bWFpbHRv OlttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0+DQpTZW50OiBGcmlkYXksIEFwcmlsIDIyLCAy MDExIDM6NDAgUE0NClRvOiBBbnRob255IE5hZGFsaW47IERpY2sgSGFyZHQNCkNjOiBPQXV0aCBX Rw0KU3ViamVjdDogUkU6IFtPQVVUSC1XR10gUmV2aXNlZCBTZWN0aW9uIDMNCg0KTGV0IG1lIG1h a2Ugc3VyZSB3ZeKAmXJlIGNsZWFyIGhlcmU6DQoNCllvdXIgYXJndW1lbnQgaXMgdGhhdCB0aGlz IGlzIG5vdCBhIG5ldyB1c2UgY2FzZSBiZWNhdXNlIFdSQVAgYWxsb3dzIOKAmGFkZGl0aW9uYWwg cGFyYW1ldGVyc+KAmSBhbmQgZG9lc27igJl0IGV4cGxpY2l0bHkgZm9yYmlkcyBpdD8NCg0KSWYg SSBtaXNzZWQgc29tZXRoaW5nLCBwbGVhc2UgcXVvdGUgdGhlIGV4YWN0IG5vcm1hdGl2ZSBsYW5n dWFnZSBpbiBXUkFQIHNob3dpbmcgaG93IHRvIHVzZSB0d28gYXNzZXJ0aW9ucywgb3IgYW55IHRl eHQgZGlmZmVyZW50aWF0aW5nIGJldHdlZW4gdXNpbmcgYW4gYXNzZXJ0aW9uIGZvciBjbGllbnQg YXV0aGVudGljYXRpb24gdnMuIHVzaW5nIGFuIGFzc2VydGlvbiBmb3IgcmVzb3VyY2Ugb3duZXIg YXV0aG9yaXphdGlvbi4gU2hvdyBtZSBhbnl0aGluZyB0aGF0IHByZS1kYXRlcyBZYXJvbuKAmXMg dGV4dCBkb2N1bWVudGluZyB0aGUgdHdvIGFzc2VydGlvbnMgdXNlIGNhc2UuDQoNCkVITA0KDQoN CkZyb206IEFudGhvbnkgTmFkYWxpbiBbbWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbV08bWFp bHRvOlttYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tXT4NClNlbnQ6IEZyaWRheSwgQXByaWwg MjIsIDIwMTEgMzozNCBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBEaWNrIEhhcmR0DQpDYzog T0F1dGggV0cNClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIFJldmlzZWQgU2VjdGlvbiAzDQoNCkkg ZGlzYWdyZWUgaGVyZSwgdGhpcyBpcyBub3QgbmV3IG9yIGV2ZW4gY29tcGxldGVseSBuZXcgdXNl IGNhc2UgYXMgdGhpcyB3YXMgaW4gV1JBUCBhcyB3ZSBhcmUgdXNpbmcgdGhpcyBmZWF0dXJlIG5v dy4gSSB3b3VsZCBhZ3JlZSB0aGF0IGl04oCZcyBub3QgdmVyeSB3ZWxsIGRvY3VtZW50ZWQgYnV0 IHRoYXQgd2FzIGF0dGVtcHRlZCBieSBZYXJvbiBpbiBoaXMgYXBwZW5kIHdhcyB0byBjbGFyaWZ5 IHRoZSBzdXBwb3J0Lg0KDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVl bml2ZXJzZS5jb21dPG1haWx0bzpbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dPg0KU2VudDog RnJpZGF5LCBBcHJpbCAyMiwgMjAxMSAzOjI1IFBNDQpUbzogQW50aG9ueSBOYWRhbGluOyBEaWNr IEhhcmR0DQpDYzogT0F1dGggV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJldmlzZWQgU2Vj dGlvbiAzDQoNCg0KDQpGcm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNv bTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCkRhdGU6IEZyaSwgMjIgQXByIDIwMTEg MTQ6NTE6MzMgLTA3MDANCg0KQUpOLT4gU28gdGhlIGNsaWVudCBjcmVkZW50aWFscyBvcmlnaW5h dGUgZnJvbSBXUkFQIGFsc28sIGl04oCZcyBub3QgY29tcGxldGVseSBuZXcsIGl0IG1heSBiZSBu ZXcgdGhlIHdheSB0aGF0IGl0IGdvdCB3b3JkZWQgYnV0IHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkg d2FzIGluIFdSQVAuIFRoZSAgc2VjdGlvbiA1LjIgKGFuZCBzdWJzZWN0aW9ucykgaW4gdGhlIFdB UCBzcGVjaWZpY2F0aW9uIGlzIHdoZXJlIHlvdSBzZWUgdGhlIGFzc2VydGlvbiBkb2N1bWVudGVk IGJ1dCB3aGF0IGlzIG5vdCBleHBsaWNpdGx5IHN0YXRlZCAob3RoZXIgdGhhbiBhZGRpdGlvbmFs IHBhcmFtZXRlcnMgY2xhdXNlKXRoZXJlIGJ1dCBub3QgZGlzYWxsb3dlZCBpcyB0aGUgYWJpbGl0 eSB0byBoYXZlIHRoZSBhY2Nlc3NfdG9rZW4gKGFkZGl0aW9uYWwgcGFyYW1ldGVycykgYWxzbyBz cGVjaWZpZWQgc28geW91IHdlcmUgYWxsb3dlZCB0byBoYXZlIDIgYXNzZXJ0aW9ucyBpbiBXUkFQ IGZvciBhdXRoZW50aWNhdGlvbg0KDQpJdCBpcyBjb21wbGV0ZWx5IG5ldy4NCg0KVGhlIHR3byBh c3NlcnRpb25zIGZ1bmN0aW9uYWxpdHkgaXMgY2VydGFpbmx5IE5PVCBpbiBXUkFQLiBJdCBpcyBu b3QgZXZlbiBoaW50ZWQgYXQuDQoNClNlZW1zIHRvIG1lIHlvdSBqdXN0IG1hZGUgbXkgY2FzZSBm b3IgZHJvcHBpbmcgdGhpcyBpc3N1ZS4gSWYgdGhpcyBpcyB5b3VyIHJhdGlvbmFsIGZvciBhZGRp bmcgdHdvIGFzc2VydGlvbnMgc3VwcG9ydCBpbiB2MiwgdGhlbiB3ZSBjYW4gYmUgZG9uZSByaWdo dCBub3cuIHYyIGFscmVhZHkgZ2l2ZXMgeW91IHRoZSBleGFjdCBzYW1lICdhZGRpdGlvbmFsIHBh cmFtZXRlcnMnIHN1cHBvcnQgYW5kIGRvZXMgbm90IGRpc2FsbG93IHR3byBhc3NlcnRpb25zLiBZ b3UgaGF2ZSBtYWRlIHN0YXRlbWVudHMgaW4gdGhlIHBhc3QgdGhhdCBXUkFQIGRpZCBldmVyeXRo aW5nIHlvdSBuZWVkZWQgYW5kIHRoYXQgdjIgaGFzIHRvIGNvdmVyIHRoZSBzYW1lIHNjb3BlLg0K DQpXZWxsLCBpdCBhbHJlYWR5IGRvZXMuDQoNCldlIGNhbiBjZXJ0YWlubHkgY29udGludWUgdG8g ZGViYXRlIHdoZXRoZXIgdjIgbmVlZHMgdG8gYWRkcmVzcyB0aGlzIG5ldyB1c2UgY2FzZSwgYW5k IGlmIHNvIGhvdyB0byBhY2NvbXBsaXNoIGl0LCBidXQgdGhhdCBpcyBiYXNlZCBzb2xlbHkgb24g bmV3IHJlcXVpcmVtZW50cyBhbmQgaXMgYW4gZXhwYW5zaW9uIG9mIHRoZSBhZ3JlZWQgcHJvdG9j b2wgc2NvcGUgKFdSQVAgKyBPQXV0aCAxLjApLg0KDQpFSEwNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480DDBCH1PRD0302MB115_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLnlpdjEyMDE4Njc5NDJtc29hY2V0YXRlLCBsaS55 aXYxMjAxODY3OTQybXNvYWNldGF0ZSwgZGl2LnlpdjEyMDE4Njc5NDJtc29hY2V0YXRlDQoJe21z by1zdHlsZS1uYW1lOnlpdjEyMDE4Njc5NDJtc29hY2V0YXRlOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLnlpdjEyMDE4Njc5NDJtc29ub3JtYWwsIGxpLnlp djEyMDE4Njc5NDJtc29ub3JtYWwsIGRpdi55aXYxMjAxODY3OTQybXNvbm9ybWFsDQoJe21zby1z dHlsZS1uYW1lOnlpdjEyMDE4Njc5NDJtc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2MTIwMTg2Nzk0Mm1zb2NocGRlZmF1bHQsIGxpLnlp djEyMDE4Njc5NDJtc29jaHBkZWZhdWx0LCBkaXYueWl2MTIwMTg2Nzk0Mm1zb2NocGRlZmF1bHQN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2MTIwMTg2Nzk0Mm1zb2NocGRlZmF1bHQ7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2MTIwMTg2Nzk0Mm1zb2h5 cGVybGluaw0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjAxODY3OTQybXNvaHlwZXJsaW5rO30NCnNw YW4ueWl2MTIwMTg2Nzk0Mm1zb2h5cGVybGlua2ZvbGxvd2VkDQoJe21zby1zdHlsZS1uYW1lOnlp djEyMDE4Njc5NDJtc29oeXBlcmxpbmtmb2xsb3dlZDt9DQpzcGFuLnlpdjEyMDE4Njc5NDJiYWxs b29udGV4dGNoYXINCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTIwMTg2Nzk0MmJhbGxvb250ZXh0Y2hh cjt9DQpzcGFuLnlpdjEyMDE4Njc5NDJlbWFpbHN0eWxlMjANCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MTIwMTg2Nzk0MmVtYWlsc3R5bGUyMDt9DQpzcGFuLnlpdjEyMDE4Njc5NDJlbWFpbHN0eWxlMjEN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2MTIwMTg2Nzk0MmVtYWlsc3R5bGUyMTt9DQpzcGFuLnlpdjEy MDE4Njc5NDJlbWFpbHN0eWxlMjINCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTIwMTg2Nzk0MmVtYWls c3R5bGUyMjt9DQpzcGFuLnlpdjEyMDE4Njc5NDJlbWFpbHN0eWxlMjMNCgl7bXNvLXN0eWxlLW5h bWU6eWl2MTIwMTg2Nzk0MmVtYWlsc3R5bGUyMzt9DQpwLnlpdjEyMDE4Njc5NDJtc29ub3JtYWwx LCBsaS55aXYxMjAxODY3OTQybXNvbm9ybWFsMSwgZGl2LnlpdjEyMDE4Njc5NDJtc29ub3JtYWwx DQoJe21zby1zdHlsZS1uYW1lOnlpdjEyMDE4Njc5NDJtc29ub3JtYWwxOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLnlpdjEyMDE4Njc5NDJtc29oeXBl cmxpbmsxDQoJe21zby1zdHlsZS1uYW1lOnlpdjEyMDE4Njc5NDJtc29oeXBlcmxpbmsxOw0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLnlpdjEyMDE4Njc5 NDJtc29oeXBlcmxpbmtmb2xsb3dlZDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTIwMTg2Nzk0Mm1z b2h5cGVybGlua2ZvbGxvd2VkMTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLnlpdjEyMDE4Njc5NDJtc29hY2V0YXRlMSwgbGkueWl2MTIwMTg2Nzk0Mm1z b2FjZXRhdGUxLCBkaXYueWl2MTIwMTg2Nzk0Mm1zb2FjZXRhdGUxDQoJe21zby1zdHlsZS1uYW1l OnlpdjEyMDE4Njc5NDJtc29hY2V0YXRlMTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi55aXYxMjAxODY3OTQyYmFsbG9vbnRleHRjaGFyMQ0KCXttc28tc3R5bGUt bmFtZTp5aXYxMjAxODY3OTQyYmFsbG9vbnRleHRjaGFyMTsNCglmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLnlpdjEyMDE4Njc5NDJlbWFpbHN0eWxlMjAxDQoJe21zby1z dHlsZS1uYW1lOnlpdjEyMDE4Njc5NDJlbWFpbHN0eWxlMjAxOw0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi55aXYxMjAxODY3OTQyZW1h aWxzdHlsZTIxMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjAxODY3OTQyZW1haWxzdHlsZTIxMTsN Cglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4ueWl2MTIwMTg2Nzk0MmVtYWlsc3R5bGUyMjENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTIwMTg2 Nzk0MmVtYWlsc3R5bGUyMjE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLnlpdjEyMDE4Njc5NDJlbWFpbHN0eWxlMjMxDQoJe21zby1z dHlsZS1uYW1lOnlpdjEyMDE4Njc5NDJlbWFpbHN0eWxlMjMxOw0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KcC55aXYxMjAxODY3OTQybXNvY2hw ZGVmYXVsdDEsIGxpLnlpdjEyMDE4Njc5NDJtc29jaHBkZWZhdWx0MSwgZGl2LnlpdjEyMDE4Njc5 NDJtc29jaHBkZWZhdWx0MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjAxODY3OTQybXNvY2hwZGVm YXVsdDE7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4u eWl2MTIwMTg2Nzk0MmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTIwMTg2 Nzk0MmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTQwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoZXJlIGlzIG5vIGV4dGVuc2lvbiBpbiBXUkFQIHRvIGFsbG93IHRoaXMsIGl04oCZcyBhbGxv d2VkIGFzIHBhcnQgb2YgV1JBUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBXaWxsaWFtIEouIE1pbGxz IFttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBBcHJpbCAyMiwgMjAxMSA0OjEwIFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFsaW47 IEVyYW4gSGFtbWVyLUxhaGF2OyBEaWNrIEhhcmR0PGJyPg0KPGI+Q2M6PC9iPiBPQXV0aCBXRzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZXZpc2VkIFNlY3Rpb24gMzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhdCBXUkFQIGFsbG93ZWQgZXh0ZW5zaW9u IGFuZCB0aGF0IHNvbWVvbmUgZXh0ZW5kZWQgd2l0aCBhIHNlY29uZCBhc3NlcnRpb24gZG9lcyBu b3QgaW1wbHkgdGhhdCBhIHNlY29uZCBhc3NlcnRpb24gaXMgcHJvdmlkZWQgZm9yIGluIFdSQVAu Jm5ic3A7IEl0IG1lYW5zIHRoYXQgV1JBUA0KIGFsbG93ZWQgZXh0ZW5zaW9uLiZuYnNwOyBBUXJl IHdlIHRyeWluZyB0byBicmluZyB0aGF0IGV4dGVuc2lvbiBpbnRvIHRoZSBtYWluIHNwZWMgYXMg YSBuZWVkZWQgdXNlIGNhc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8 aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVm PSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+ Jmd0Ozxicj4NCjxiPlRvOjwvYj4gRXJhbiBIYW1tZXItTGFoYXYgJmx0OzxhIGhyZWY9Im1haWx0 bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDs7IERpY2sg SGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+ZGljay5oYXJk dEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gT0F1dGggV0cgJmx0OzxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNl bnQ6PC9iPiBGcmlkYXksIEFwcmlsIDIyLCAyMDExIDM6NDUgUE08YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPQVVUSC1XR10gUmV2aXNlZCBTZWN0aW9uIDM8YnI+DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IGlkPSJ5aXYxMjAxODY3OTQyIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOiMxRjQ5N0QiPk5vdCBzdXJlIEkgaGF2ZSB0byBzaG93IHlvdSBhbnl0aGluZy4gVGhlIFdS QVAgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBwcmVjbHVkZSB0aGUgdXNhZ2Ugb2YgMiBhc3NlcnRp b25zIGFzIHRoaXMgd2FzIG9uZSBvZiB0aGUgbXVzdCBzdXBwb3J0IHVzZSBjYXNlcyBmb3IgV1JB UC4gQXMgSQ0KIGluZGljYXRlZCB0aGlzIHdhcyBub3QgdGhlIGJlc3Qgc3BlbGxlZCBvdXQgZmVh dHVyZSBpbiB0aGUgV1JBUCBzcGVjaWZpY2F0aW9uLiBZYXJvbuKAmXMgYXBwZW5kIHdhcyBhbiBh dHRlbXB0IHRvIGNsYXJpZnkgdGhlIHVzZSBjYXNlIHdpdGggYWRkaXRpb25hbCB0ZXh0LiBJZiB5 b3Ugd2FudCB0byBjb21lIG9uIHNpdGUgeW91IGNhbiBzZWUgdGhlIGNvZGUgYW5kIHRoZSBkYXRl cyBvbiB0aGUgY29kZSB0aGF0IHByZWRhdGVzIFlhcm9u4oCZcyB0ZXh0Lg0KPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjotbW96LXVzZS10ZXh0LWNv bG9yIC1tb3otdXNlLXRleHQtY29sb3IiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2NvbG9yOmJsYWNrIj4gRXJhbiBIYW1tZXItTGFoYXYNCjxhIGhyZWY9Im1haWx0bzpbbWFpbHRv OmVyYW5AaHVlbml2ZXJzZS5jb21dIj5bbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dPC9hPiA8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAyMiwgMjAxMSAzOjQwIFBNPGJyPg0KPGI+ VG86PC9iPiBBbnRob255IE5hZGFsaW47IERpY2sgSGFyZHQ8YnI+DQo8Yj5DYzo8L2I+IE9BdXRo IFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbT0FVVEgtV0ddIFJldmlzZWQgU2VjdGlvbiAz PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEIj5MZXQgbWUgbWFrZSBzdXJlIHdl4oCZcmUgY2xlYXIgaGVyZTo8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPllvdXIgYXJndW1lbnQgaXMgdGhh dCB0aGlzIGlzIG5vdCBhIG5ldyB1c2UgY2FzZSBiZWNhdXNlIFdSQVAgYWxsb3dzIOKAmGFkZGl0 aW9uYWwgcGFyYW1ldGVyc+KAmSBhbmQgZG9lc27igJl0IGV4cGxpY2l0bHkgZm9yYmlkcyBpdD88 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPklmIEkgbWlzc2Vk IHNvbWV0aGluZywgcGxlYXNlIHF1b3RlIHRoZSBleGFjdCBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4g V1JBUCBzaG93aW5nIGhvdyB0byB1c2UgdHdvIGFzc2VydGlvbnMsIG9yIGFueSB0ZXh0IGRpZmZl cmVudGlhdGluZyBiZXR3ZWVuIHVzaW5nIGFuIGFzc2VydGlvbiBmb3INCiBjbGllbnQgYXV0aGVu dGljYXRpb24gdnMuIHVzaW5nIGFuIGFzc2VydGlvbiBmb3IgcmVzb3VyY2Ugb3duZXIgYXV0aG9y aXphdGlvbi4gU2hvdyBtZSBhbnl0aGluZyB0aGF0IHByZS1kYXRlcyBZYXJvbuKAmXMgdGV4dCBk b2N1bWVudGluZyB0aGUgdHdvIGFzc2VydGlvbnMgdXNlIGNhc2UuPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5FSEw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0O2JvcmRlci1jb2xvcjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29s b3IgLW1vei11c2UtdGV4dC1jb2xvciBibHVlIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbjtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNv bG9yIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+IEFudGhv bnkgTmFkYWxpbg0KPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29t XSIgdGFyZ2V0PSJfYmxhbmsiPlttYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tXTwvYT4NCjxi cj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDIyLCAyMDExIDM6MzQgUE08YnI+DQo8Yj5U bzo8L2I+IEVyYW4gSGFtbWVyLUxhaGF2OyBEaWNrIEhhcmR0PGJyPg0KPGI+Q2M6PC9iPiBPQXV0 aCBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdHXSBSZXZpc2VkIFNlY3Rpb24g Mzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RCI+SSBkaXNhZ3JlZSBoZXJlLCB0aGlzIGlzIG5vdCBuZXcgb3IgZXZlbiBjb21w bGV0ZWx5IG5ldyB1c2UgY2FzZSBhcyB0aGlzIHdhcyBpbiBXUkFQIGFzIHdlIGFyZSB1c2luZyB0 aGlzIGZlYXR1cmUgbm93LiBJIHdvdWxkIGFncmVlIHRoYXQgaXTigJlzIG5vdCB2ZXJ5IHdlbGwg ZG9jdW1lbnRlZA0KIGJ1dCB0aGF0IHdhcyBhdHRlbXB0ZWQgYnkgWWFyb24gaW4gaGlzIGFwcGVu ZCB3YXMgdG8gY2xhcmlmeSB0aGUgc3VwcG9ydC4gPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2Ut dGV4dC1jb2xvciI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2si PiBFcmFuIEhhbW1lci1MYWhhdg0KPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86ZXJhbkBodWVuaXZl cnNlLmNvbV0iIHRhcmdldD0iX2JsYW5rIj5bbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dPC9h Pg0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMjIsIDIwMTEgMzoyNSBQTTxicj4N CjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluOyBEaWNrIEhhcmR0PGJyPg0KPGI+Q2M6PC9iPiBP QXV0aCBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZXZpc2VkIFNlY3Rp b24gMzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAt bW96LXVzZS10ZXh0LWNvbG9yIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOmJsYWNrIj5BbnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1p Y3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmksIDIyIEFwciAyMDExIDE0OjUxOjMzIC0wNzAwPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtt YXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2Ut dGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yIHJnYigxODEsIDE5NiwgMjIzKSIgaWQ9Inlp djEyMDE4Njc5NDJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBjbGFzcz0ieWl2MTIwMTg2Nzk0MmFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2NvbG9yOiMxRjQ5N0QiPkFKTi0mZ3Q7IFNvIHRoZSBjbGllbnQg Y3JlZGVudGlhbHMgb3JpZ2luYXRlIGZyb20gV1JBUCBhbHNvLCBpdOKAmXMgbm90IGNvbXBsZXRl bHkgbmV3LCBpdCBtYXkgYmUgbmV3IHRoZSB3YXkgdGhhdCBpdCBnb3Qgd29yZGVkDQogYnV0IHRo ZSBzYW1lIGZ1bmN0aW9uYWxpdHkgd2FzIGluIFdSQVAuIFRoZSZuYnNwOyBzZWN0aW9uIDUuMiAo YW5kIHN1YnNlY3Rpb25zKSBpbiB0aGUgV0FQIHNwZWNpZmljYXRpb24gaXMgd2hlcmUgeW91IHNl ZSB0aGUgYXNzZXJ0aW9uIGRvY3VtZW50ZWQgYnV0IHdoYXQgaXMgbm90IGV4cGxpY2l0bHkgc3Rh dGVkIChvdGhlciB0aGFuIGFkZGl0aW9uYWwgcGFyYW1ldGVycyBjbGF1c2UpdGhlcmUgYnV0IG5v dCBkaXNhbGxvd2VkIGlzIHRoZSBhYmlsaXR5DQogdG8gaGF2ZSB0aGUgYWNjZXNzX3Rva2VuIChh ZGRpdGlvbmFsIHBhcmFtZXRlcnMpIGFsc28gc3BlY2lmaWVkIHNvIHlvdSB3ZXJlIGFsbG93ZWQg dG8gaGF2ZSAyIGFzc2VydGlvbnMgaW4gV1JBUCBmb3IgYXV0aGVudGljYXRpb248L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SXQgaXMgY29tcGxldGVseSBuZXcu PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPlRoZSB0d28gYXNzZXJ0aW9ucyBmdW5jdGlvbmFsaXR5IGlzIGNlcnRh aW5seSBOT1QgaW4gV1JBUC4gSXQgaXMgbm90IGV2ZW4gaGludGVkIGF0Ljwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij5TZWVtcyB0byBtZSB5b3UganVzdCBtYWRlIG15IGNhc2UgZm9yIGRyb3BwaW5nIHRoaXMgaXNz dWUuIElmIHRoaXMgaXMgeW91ciByYXRpb25hbCBmb3IgYWRkaW5nIHR3byBhc3NlcnRpb25zIHN1 cHBvcnQgaW4gdjIsIHRoZW4gd2UgY2FuIGJlIGRvbmUgcmlnaHQgbm93LiB2MiBhbHJlYWR5IGdp dmVzDQogeW91IHRoZSBleGFjdCBzYW1lICdhZGRpdGlvbmFsIHBhcmFtZXRlcnMnIHN1cHBvcnQg YW5kIGRvZXMgbm90IGRpc2FsbG93IHR3byBhc3NlcnRpb25zLiBZb3UgaGF2ZSBtYWRlIHN0YXRl bWVudHMgaW4gdGhlIHBhc3QgdGhhdCBXUkFQIGRpZCBldmVyeXRoaW5nIHlvdSBuZWVkZWQgYW5k IHRoYXQgdjIgaGFzIHRvIGNvdmVyIHRoZSBzYW1lIHNjb3BlLjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5XZWxs LCBpdCBhbHJlYWR5IGRvZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPldlIGNhbiBjZXJ0YWlubHkgY29udGlu dWUgdG8gZGViYXRlIHdoZXRoZXIgdjIgbmVlZHMgdG8gYWRkcmVzcyB0aGlzIG5ldyB1c2UgY2Fz ZSwgYW5kIGlmIHNvIGhvdyB0byBhY2NvbXBsaXNoIGl0LCBidXQgdGhhdCBpcyBiYXNlZCBzb2xl bHkgb24gbmV3IHJlcXVpcmVtZW50cyBhbmQgaXMgYW4NCiBleHBhbnNpb24gb2YgdGhlIGFncmVl ZCBwcm90b2NvbCBzY29wZSAoV1JBUCAmIzQzOyBPQXV0aCAxLjApLjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5F SEw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDti YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480DDBCH1PRD0302MB115_-- From eran@hueniverse.com Fri Apr 22 17:06:56 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 51F2CE06A0 for ; Fri, 22 Apr 2011 17:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC23-B2MNyEz for ; Fri, 22 Apr 2011 17:06:55 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfc.amsl.com (Postfix) with SMTP id A42FEE067D for ; Fri, 22 Apr 2011 17:06:54 -0700 (PDT) Received: (qmail 21032 invoked from network); 23 Apr 2011 00:06:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 23 Apr 2011 00:06:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 22 Apr 2011 17:05:48 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , "William J. Mills" , Dick Hardt Date: Fri, 22 Apr 2011 17:05:36 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAB2/gYAAA7I5gAADPdkAAAF71YAAAvT6gAABnOkAAAAhFQAAAJ1bAAABBRIAAAIBpIAAATynAAAAMeuAACk2iiAADuGQAAAm7+iAAAIawIAALNYVsAALpPcAAAAY5aAAAEP/cAAANtkAAAD8qIAAAA/YwAAB4j/w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BBFA6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447535BBF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <242018.69896.qm@web31811.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723447535BBFA6P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 23 Apr 2011 00:06:56 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447535BBFA6P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzISBFeGFjdGx5IGFzIGl0IGlzIGFscmVhZHkgYWxsb3dlZCBpbiB2Mi4NCg0KRUhMDQoNCkZy b206IEFudGhvbnkgTmFkYWxpbiBbbWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbV0NClNlbnQ6 IEZyaWRheSwgQXByaWwgMjIsIDIwMTEgNDoxMiBQTQ0KVG86IFdpbGxpYW0gSi4gTWlsbHM7IEVy YW4gSGFtbWVyLUxhaGF2OyBEaWNrIEhhcmR0DQpDYzogT0F1dGggV0cNClN1YmplY3Q6IFJFOiBb T0FVVEgtV0ddIFJldmlzZWQgU2VjdGlvbiAzDQoNClRoZXJlIGlzIG5vIGV4dGVuc2lvbiBpbiBX UkFQIHRvIGFsbG93IHRoaXMsIGl04oCZcyBhbGxvd2VkIGFzIHBhcnQgb2YgV1JBUC4NCg0KRnJv bTogV2lsbGlhbSBKLiBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXQ0KU2VudDog RnJpZGF5LCBBcHJpbCAyMiwgMjAxMSA0OjEwIFBNDQpUbzogQW50aG9ueSBOYWRhbGluOyBFcmFu IEhhbW1lci1MYWhhdjsgRGljayBIYXJkdA0KQ2M6IE9BdXRoIFdHDQpTdWJqZWN0OiBSZTogW09B VVRILVdHXSBSZXZpc2VkIFNlY3Rpb24gMw0KDQpUaGF0IFdSQVAgYWxsb3dlZCBleHRlbnNpb24g YW5kIHRoYXQgc29tZW9uZSBleHRlbmRlZCB3aXRoIGEgc2Vjb25kIGFzc2VydGlvbiBkb2VzIG5v dCBpbXBseSB0aGF0IGEgc2Vjb25kIGFzc2VydGlvbiBpcyBwcm92aWRlZCBmb3IgaW4gV1JBUC4g IEl0IG1lYW5zIHRoYXQgV1JBUCBhbGxvd2VkIGV4dGVuc2lvbi4gIEFRcmUgd2UgdHJ5aW5nIHRv IGJyaW5nIHRoYXQgZXh0ZW5zaW9uIGludG8gdGhlIG1haW4gc3BlYyBhcyBhIG5lZWRlZCB1c2Ug Y2FzZT8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEFudGhvbnkg TmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5j b20+Pg0KVG86IEVyYW4gSGFtbWVyLUxhaGF2IDxlcmFuQGh1ZW5pdmVyc2UuY29tPG1haWx0bzpl cmFuQGh1ZW5pdmVyc2UuY29tPj47IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1h aWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpDYzogT0F1dGggV0cgPG9hdXRoQGlldGYub3Jn PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTZW50OiBGcmlkYXksIEFwcmlsIDIyLCAyMDExIDM6 NDUgUE0NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJldmlzZWQgU2VjdGlvbiAzDQoNCk5vdCBz dXJlIEkgaGF2ZSB0byBzaG93IHlvdSBhbnl0aGluZy4gVGhlIFdSQVAgc3BlY2lmaWNhdGlvbiBk b2VzIG5vdCBwcmVjbHVkZSB0aGUgdXNhZ2Ugb2YgMiBhc3NlcnRpb25zIGFzIHRoaXMgd2FzIG9u ZSBvZiB0aGUgbXVzdCBzdXBwb3J0IHVzZSBjYXNlcyBmb3IgV1JBUC4gQXMgSSBpbmRpY2F0ZWQg dGhpcyB3YXMgbm90IHRoZSBiZXN0IHNwZWxsZWQgb3V0IGZlYXR1cmUgaW4gdGhlIFdSQVAgc3Bl Y2lmaWNhdGlvbi4gWWFyb27igJlzIGFwcGVuZCB3YXMgYW4gYXR0ZW1wdCB0byBjbGFyaWZ5IHRo ZSB1c2UgY2FzZSB3aXRoIGFkZGl0aW9uYWwgdGV4dC4gSWYgeW91IHdhbnQgdG8gY29tZSBvbiBz aXRlIHlvdSBjYW4gc2VlIHRoZSBjb2RlIGFuZCB0aGUgZGF0ZXMgb24gdGhlIGNvZGUgdGhhdCBw cmVkYXRlcyBZYXJvbuKAmXMgdGV4dC4NCg0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYgW21haWx0 bzplcmFuQGh1ZW5pdmVyc2UuY29tXTxtYWlsdG86W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29t XT4NClNlbnQ6IEZyaWRheSwgQXByaWwgMjIsIDIwMTEgMzo0MCBQTQ0KVG86IEFudGhvbnkgTmFk YWxpbjsgRGljayBIYXJkdA0KQ2M6IE9BdXRoIFdHDQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBS ZXZpc2VkIFNlY3Rpb24gMw0KDQpMZXQgbWUgbWFrZSBzdXJlIHdl4oCZcmUgY2xlYXIgaGVyZToN Cg0KWW91ciBhcmd1bWVudCBpcyB0aGF0IHRoaXMgaXMgbm90IGEgbmV3IHVzZSBjYXNlIGJlY2F1 c2UgV1JBUCBhbGxvd3Mg4oCYYWRkaXRpb25hbCBwYXJhbWV0ZXJz4oCZIGFuZCBkb2VzbuKAmXQg ZXhwbGljaXRseSBmb3JiaWRzIGl0Pw0KDQpJZiBJIG1pc3NlZCBzb21ldGhpbmcsIHBsZWFzZSBx dW90ZSB0aGUgZXhhY3Qgbm9ybWF0aXZlIGxhbmd1YWdlIGluIFdSQVAgc2hvd2luZyBob3cgdG8g dXNlIHR3byBhc3NlcnRpb25zLCBvciBhbnkgdGV4dCBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiB1 c2luZyBhbiBhc3NlcnRpb24gZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiB2cy4gdXNpbmcgYW4g YXNzZXJ0aW9uIGZvciByZXNvdXJjZSBvd25lciBhdXRob3JpemF0aW9uLiBTaG93IG1lIGFueXRo aW5nIHRoYXQgcHJlLWRhdGVzIFlhcm9u4oCZcyB0ZXh0IGRvY3VtZW50aW5nIHRoZSB0d28gYXNz ZXJ0aW9ucyB1c2UgY2FzZS4NCg0KRUhMDQoNCg0KRnJvbTogQW50aG9ueSBOYWRhbGluIFttYWls dG86dG9ueW5hZEBtaWNyb3NvZnQuY29tXTxtYWlsdG86W21haWx0bzp0b255bmFkQG1pY3Jvc29m dC5jb21dPg0KU2VudDogRnJpZGF5LCBBcHJpbCAyMiwgMjAxMSAzOjM0IFBNDQpUbzogRXJhbiBI YW1tZXItTGFoYXY7IERpY2sgSGFyZHQNCkNjOiBPQXV0aCBXRw0KU3ViamVjdDogUkU6IFtPQVVU SC1XR10gUmV2aXNlZCBTZWN0aW9uIDMNCg0KSSBkaXNhZ3JlZSBoZXJlLCB0aGlzIGlzIG5vdCBu ZXcgb3IgZXZlbiBjb21wbGV0ZWx5IG5ldyB1c2UgY2FzZSBhcyB0aGlzIHdhcyBpbiBXUkFQIGFz IHdlIGFyZSB1c2luZyB0aGlzIGZlYXR1cmUgbm93LiBJIHdvdWxkIGFncmVlIHRoYXQgaXTigJlz IG5vdCB2ZXJ5IHdlbGwgZG9jdW1lbnRlZCBidXQgdGhhdCB3YXMgYXR0ZW1wdGVkIGJ5IFlhcm9u IGluIGhpcyBhcHBlbmQgd2FzIHRvIGNsYXJpZnkgdGhlIHN1cHBvcnQuDQoNCkZyb206IEVyYW4g SGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV08bWFpbHRvOlttYWlsdG86 ZXJhbkBodWVuaXZlcnNlLmNvbV0+DQpTZW50OiBGcmlkYXksIEFwcmlsIDIyLCAyMDExIDM6MjUg UE0NClRvOiBBbnRob255IE5hZGFsaW47IERpY2sgSGFyZHQNCkNjOiBPQXV0aCBXRw0KU3ViamVj dDogUmU6IFtPQVVUSC1XR10gUmV2aXNlZCBTZWN0aW9uIDMNCg0KDQoNCkZyb206IEFudGhvbnkg TmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5j b20+Pg0KRGF0ZTogRnJpLCAyMiBBcHIgMjAxMSAxNDo1MTozMyAtMDcwMA0KDQpBSk4tPiBTbyB0 aGUgY2xpZW50IGNyZWRlbnRpYWxzIG9yaWdpbmF0ZSBmcm9tIFdSQVAgYWxzbywgaXTigJlzIG5v dCBjb21wbGV0ZWx5IG5ldywgaXQgbWF5IGJlIG5ldyB0aGUgd2F5IHRoYXQgaXQgZ290IHdvcmRl ZCBidXQgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSB3YXMgaW4gV1JBUC4gVGhlICBzZWN0aW9uIDUu MiAoYW5kIHN1YnNlY3Rpb25zKSBpbiB0aGUgV0FQIHNwZWNpZmljYXRpb24gaXMgd2hlcmUgeW91 IHNlZSB0aGUgYXNzZXJ0aW9uIGRvY3VtZW50ZWQgYnV0IHdoYXQgaXMgbm90IGV4cGxpY2l0bHkg c3RhdGVkIChvdGhlciB0aGFuIGFkZGl0aW9uYWwgcGFyYW1ldGVycyBjbGF1c2UpdGhlcmUgYnV0 IG5vdCBkaXNhbGxvd2VkIGlzIHRoZSBhYmlsaXR5IHRvIGhhdmUgdGhlIGFjY2Vzc190b2tlbiAo YWRkaXRpb25hbCBwYXJhbWV0ZXJzKSBhbHNvIHNwZWNpZmllZCBzbyB5b3Ugd2VyZSBhbGxvd2Vk IHRvIGhhdmUgMiBhc3NlcnRpb25zIGluIFdSQVAgZm9yIGF1dGhlbnRpY2F0aW9uDQoNCkl0IGlz IGNvbXBsZXRlbHkgbmV3Lg0KDQpUaGUgdHdvIGFzc2VydGlvbnMgZnVuY3Rpb25hbGl0eSBpcyBj ZXJ0YWlubHkgTk9UIGluIFdSQVAuIEl0IGlzIG5vdCBldmVuIGhpbnRlZCBhdC4NCg0KU2VlbXMg dG8gbWUgeW91IGp1c3QgbWFkZSBteSBjYXNlIGZvciBkcm9wcGluZyB0aGlzIGlzc3VlLiBJZiB0 aGlzIGlzIHlvdXIgcmF0aW9uYWwgZm9yIGFkZGluZyB0d28gYXNzZXJ0aW9ucyBzdXBwb3J0IGlu IHYyLCB0aGVuIHdlIGNhbiBiZSBkb25lIHJpZ2h0IG5vdy4gdjIgYWxyZWFkeSBnaXZlcyB5b3Ug dGhlIGV4YWN0IHNhbWUgJ2FkZGl0aW9uYWwgcGFyYW1ldGVycycgc3VwcG9ydCBhbmQgZG9lcyBu b3QgZGlzYWxsb3cgdHdvIGFzc2VydGlvbnMuIFlvdSBoYXZlIG1hZGUgc3RhdGVtZW50cyBpbiB0 aGUgcGFzdCB0aGF0IFdSQVAgZGlkIGV2ZXJ5dGhpbmcgeW91IG5lZWRlZCBhbmQgdGhhdCB2MiBo YXMgdG8gY292ZXIgdGhlIHNhbWUgc2NvcGUuDQoNCldlbGwsIGl0IGFscmVhZHkgZG9lcy4NCg0K V2UgY2FuIGNlcnRhaW5seSBjb250aW51ZSB0byBkZWJhdGUgd2hldGhlciB2MiBuZWVkcyB0byBh ZGRyZXNzIHRoaXMgbmV3IHVzZSBjYXNlLCBhbmQgaWYgc28gaG93IHRvIGFjY29tcGxpc2ggaXQs IGJ1dCB0aGF0IGlzIGJhc2VkIHNvbGVseSBvbiBuZXcgcmVxdWlyZW1lbnRzIGFuZCBpcyBhbiBl eHBhbnNpb24gb2YgdGhlIGFncmVlZCBwcm90b2NvbCBzY29wZSAoV1JBUCArIE9BdXRoIDEuMCku DQoNCkVITA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_90C41DD21FB7C64BB94121FBBC2E723447535BBFA6P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K cC55aXYxMjAxODY3OTQybXNvYWNldGF0ZSwgbGkueWl2MTIwMTg2Nzk0Mm1zb2FjZXRhdGUsIGRp di55aXYxMjAxODY3OTQybXNvYWNldGF0ZQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjAxODY3OTQy bXNvYWNldGF0ZTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K cC55aXYxMjAxODY3OTQybXNvbm9ybWFsLCBsaS55aXYxMjAxODY3OTQybXNvbm9ybWFsLCBkaXYu eWl2MTIwMTg2Nzk0Mm1zb25vcm1hbA0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjAxODY3OTQybXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLnlp djEyMDE4Njc5NDJtc29jaHBkZWZhdWx0LCBsaS55aXYxMjAxODY3OTQybXNvY2hwZGVmYXVsdCwg ZGl2LnlpdjEyMDE4Njc5NDJtc29jaHBkZWZhdWx0DQoJe21zby1zdHlsZS1uYW1lOnlpdjEyMDE4 Njc5NDJtc29jaHBkZWZhdWx0Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLnlpdjEyMDE4Njc5NDJtc29ub3JtYWwxLCBsaS55aXYxMjAxODY3OTQybXNvbm9y bWFsMSwgZGl2LnlpdjEyMDE4Njc5NDJtc29ub3JtYWwxDQoJe21zby1zdHlsZS1uYW1lOnlpdjEy MDE4Njc5NDJtc29ub3JtYWwxOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLnlpdjEyMDE4Njc5NDJtc29hY2V0YXRlMSwgbGkueWl2MTIwMTg2Nzk0Mm1zb2Fj ZXRhdGUxLCBkaXYueWl2MTIwMTg2Nzk0Mm1zb2FjZXRhdGUxDQoJe21zby1zdHlsZS1uYW1lOnlp djEyMDE4Njc5NDJtc29hY2V0YXRlMTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7fQ0KcC55aXYxMjAxODY3OTQybXNvY2hwZGVmYXVsdDEsIGxpLnlpdjEyMDE4Njc5NDJtc29j aHBkZWZhdWx0MSwgZGl2LnlpdjEyMDE4Njc5NDJtc29jaHBkZWZhdWx0MQ0KCXttc28tc3R5bGUt bmFtZTp5aXYxMjAxODY3OTQybXNvY2hwZGVmYXVsdDE7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2MTIwMTg2Nzk0Mm1zb2h5cGVybGluaw0KCXtt c28tc3R5bGUtbmFtZTp5aXYxMjAxODY3OTQybXNvaHlwZXJsaW5rO30NCnNwYW4ueWl2MTIwMTg2 Nzk0Mm1zb2h5cGVybGlua2ZvbGxvd2VkDQoJe21zby1zdHlsZS1uYW1lOnlpdjEyMDE4Njc5NDJt c29oeXBlcmxpbmtmb2xsb3dlZDt9DQpzcGFuLnlpdjEyMDE4Njc5NDJiYWxsb29udGV4dGNoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2MTIwMTg2Nzk0MmJhbGxvb250ZXh0Y2hhcjt9DQpzcGFuLnlp djEyMDE4Njc5NDJlbWFpbHN0eWxlMjANCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTIwMTg2Nzk0MmVt YWlsc3R5bGUyMDt9DQpzcGFuLnlpdjEyMDE4Njc5NDJlbWFpbHN0eWxlMjENCgl7bXNvLXN0eWxl LW5hbWU6eWl2MTIwMTg2Nzk0MmVtYWlsc3R5bGUyMTt9DQpzcGFuLnlpdjEyMDE4Njc5NDJlbWFp bHN0eWxlMjINCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTIwMTg2Nzk0MmVtYWlsc3R5bGUyMjt9DQpz cGFuLnlpdjEyMDE4Njc5NDJlbWFpbHN0eWxlMjMNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTIwMTg2 Nzk0MmVtYWlsc3R5bGUyMzt9DQpzcGFuLnlpdjEyMDE4Njc5NDJtc29oeXBlcmxpbmsxDQoJe21z by1zdHlsZS1uYW1lOnlpdjEyMDE4Njc5NDJtc29oeXBlcmxpbmsxOw0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLnlpdjEyMDE4Njc5NDJtc29oeXBlcmxp bmtmb2xsb3dlZDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTIwMTg2Nzk0Mm1zb2h5cGVybGlua2Zv bGxvd2VkMTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLnlpdjEyMDE4Njc5NDJiYWxsb29udGV4dGNoYXIxDQoJe21zby1zdHlsZS1uYW1lOnlpdjEy MDE4Njc5NDJiYWxsb29udGV4dGNoYXIxOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO30NCnNwYW4ueWl2MTIwMTg2Nzk0MmVtYWlsc3R5bGUyMDENCgl7bXNvLXN0eWxlLW5hbWU6 eWl2MTIwMTg2Nzk0MmVtYWlsc3R5bGUyMDE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLnlpdjEyMDE4Njc5NDJlbWFpbHN0eWxlMjEx DQoJe21zby1zdHlsZS1uYW1lOnlpdjEyMDE4Njc5NDJlbWFpbHN0eWxlMjExOw0KCWZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi55aXYxMjAx ODY3OTQyZW1haWxzdHlsZTIyMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjAxODY3OTQyZW1haWxz dHlsZTIyMTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4ueWl2MTIwMTg2Nzk0MmVtYWlsc3R5bGUyMzENCgl7bXNvLXN0eWxlLW5hbWU6 eWl2MTIwMTg2Nzk0MmVtYWlsc3R5bGUyMzE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLnlpdjEyMDE4Njc5NDJhcHBsZS1zdHlsZS1z cGFuDQoJe21zby1zdHlsZS1uYW1lOnlpdjEyMDE4Njc5NDJhcHBsZS1zdHlsZS1zcGFuO30NCnNw YW4uRW1haWxTdHlsZTQwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGU0MQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwv aGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1X b3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+WWVz ISBFeGFjdGx5IGFzIGl0IGlzIGFscmVhZHkgYWxsb3dlZCBpbiB2Mi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gQW50aG9ueSBOYWRhbGluIFttYWls dG86dG9ueW5hZEBtaWNyb3NvZnQuY29tXSA8YnI+PGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwg MjIsIDIwMTEgNDoxMiBQTTxicj48Yj5Ubzo8L2I+IFdpbGxpYW0gSi4gTWlsbHM7IEVyYW4gSGFt bWVyLUxhaGF2OyBEaWNrIEhhcmR0PGJyPjxiPkNjOjwvYj4gT0F1dGggV0c8YnI+PGI+U3ViamVj dDo8L2I+IFJFOiBbT0FVVEgtV0ddIFJldmlzZWQgU2VjdGlvbiAzPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGVyZSBpcyBubyBleHRl bnNpb24gaW4gV1JBUCB0byBhbGxvdyB0aGlzLCBpdOKAmXMgYWxsb3dlZCBhcyBwYXJ0IG9mIFdS QVAuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz4gV2lsbGlhbSBKLiBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXSA8 YnI+PGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMjIsIDIwMTEgNDoxMCBQTTxicj48Yj5Ubzo8 L2I+IEFudGhvbnkgTmFkYWxpbjsgRXJhbiBIYW1tZXItTGFoYXY7IERpY2sgSGFyZHQ8YnI+PGI+ Q2M6PC9iPiBPQXV0aCBXRzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmV2aXNl ZCBTZWN0aW9uIDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmll ciBOZXciO2NvbG9yOmJsYWNrJz5UaGF0IFdSQVAgYWxsb3dlZCBleHRlbnNpb24gYW5kIHRoYXQg c29tZW9uZSBleHRlbmRlZCB3aXRoIGEgc2Vjb25kIGFzc2VydGlvbiBkb2VzIG5vdCBpbXBseSB0 aGF0IGEgc2Vjb25kIGFzc2VydGlvbiBpcyBwcm92aWRlZCBmb3IgaW4gV1JBUC4mbmJzcDsgSXQg bWVhbnMgdGhhdCBXUkFQIGFsbG93ZWQgZXh0ZW5zaW9uLiZuYnNwOyBBUXJlIHdlIHRyeWluZyB0 byBicmluZyB0aGF0IGV4dGVuc2lvbiBpbnRvIHRoZSBtYWluIHNwZWMgYXMgYSBuZWVkZWQgdXNl IGNhc2U/PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PGRpdj48ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxp Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48aHIgc2l6ZT0x IHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+PC9zcGFuPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSc+PGI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IEFudGhvbnkg TmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+dG9ueW5h ZEBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+PGI+VG86PC9iPiBFcmFuIEhhbW1lci1MYWhhdiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5j b208L2E+Jmd0OzsgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21h aWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPjxiPkNjOjwvYj4gT0F1dGgg V0cgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj48Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAyMiwgMjAxMSAzOjQ1IFBNPGJyPjxi PlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZXZpc2VkIFNlY3Rpb24gMzxicj48YnI+PC9z cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXYg aWQ9eWl2MTIwMTg2Nzk0Mj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNr Z3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Jz5Ob3Qgc3VyZSBJIGhhdmUgdG8gc2hvdyB5b3UgYW55dGhpbmcuIFRoZSBXUkFQIHNwZWNpZmlj YXRpb24gZG9lcyBub3QgcHJlY2x1ZGUgdGhlIHVzYWdlIG9mIDIgYXNzZXJ0aW9ucyBhcyB0aGlz IHdhcyBvbmUgb2YgdGhlIG11c3Qgc3VwcG9ydCB1c2UgY2FzZXMgZm9yIFdSQVAuIEFzIEkgaW5k aWNhdGVkIHRoaXMgd2FzIG5vdCB0aGUgYmVzdCBzcGVsbGVkIG91dCBmZWF0dXJlIGluIHRoZSBX UkFQIHNwZWNpZmljYXRpb24uIFlhcm9u4oCZcyBhcHBlbmQgd2FzIGFuIGF0dGVtcHQgdG8gY2xh cmlmeSB0aGUgdXNlIGNhc2Ugd2l0aCBhZGRpdGlvbmFsIHRleHQuIElmIHlvdSB3YW50IHRvIGNv bWUgb24gc2l0ZSB5b3UgY2FuIHNlZSB0aGUgY29kZSBhbmQgdGhlIGRhdGVzIG9uIHRoZSBjb2Rl IHRoYXQgcHJlZGF0ZXMgWWFyb27igJlzIHRleHQuIDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47 Ym9yZGVyLWNvbG9yOi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvcic+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2snPiBFcmFuIEhhbW1lci1MYWhhdiA8 YSBocmVmPSJtYWlsdG86W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXSI+W21haWx0bzplcmFu QGh1ZW5pdmVyc2UuY29tXTwvYT4gPGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDIyLCAy MDExIDM6NDAgUE08YnI+PGI+VG86PC9iPiBBbnRob255IE5hZGFsaW47IERpY2sgSGFyZHQ8YnI+ PGI+Q2M6PC9iPiBPQXV0aCBXRzxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10gUmV2 aXNlZCBTZWN0aW9uIDM8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0 OTdEJz5MZXQgbWUgbWFrZSBzdXJlIHdl4oCZcmUgY2xlYXIgaGVyZTo8L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RCc+WW91ciBhcmd1bWVudCBpcyB0aGF0IHRoaXMgaXMgbm90IGEgbmV3IHVz ZSBjYXNlIGJlY2F1c2UgV1JBUCBhbGxvd3Mg4oCYYWRkaXRpb25hbCBwYXJhbWV0ZXJz4oCZIGFu ZCBkb2VzbuKAmXQgZXhwbGljaXRseSBmb3JiaWRzIGl0Pzwvc3Bhbj48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEJz5JZiBJIG1pc3NlZCBzb21ldGhpbmcsIHBsZWFzZSBxdW90ZSB0aGUgZXhhY3Qgbm9y bWF0aXZlIGxhbmd1YWdlIGluIFdSQVAgc2hvd2luZyBob3cgdG8gdXNlIHR3byBhc3NlcnRpb25z LCBvciBhbnkgdGV4dCBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiB1c2luZyBhbiBhc3NlcnRpb24g Zm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiB2cy4gdXNpbmcgYW4gYXNzZXJ0aW9uIGZvciByZXNv dXJjZSBvd25lciBhdXRob3JpemF0aW9uLiBTaG93IG1lIGFueXRoaW5nIHRoYXQgcHJlLWRhdGVz IFlhcm9u4oCZcyB0ZXh0IGRvY3VtZW50aW5nIHRoZSB0d28gYXNzZXJ0aW9ucyB1c2UgY2FzZS48 L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+RUhMPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCB3aW5kb3d0ZXh0IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7Ym9yZGVyLWNvbG9y Oi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNv bG9yIGJsdWUnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3 aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOi1t b3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvcic+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6YmxhY2snPiBBbnRob255IE5hZGFsaW4gPGEgaHJlZj0ibWFpbHRvOltt YWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tXSIgdGFyZ2V0PSJfYmxhbmsiPlttYWlsdG86dG9u eW5hZEBtaWNyb3NvZnQuY29tXTwvYT4gPGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDIy LCAyMDExIDM6MzQgUE08YnI+PGI+VG86PC9iPiBFcmFuIEhhbW1lci1MYWhhdjsgRGljayBIYXJk dDxicj48Yj5DYzo8L2I+IE9BdXRoIFdHPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdH XSBSZXZpc2VkIFNlY3Rpb24gMzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0QnPkkgZGlzYWdyZWUgaGVyZSwgdGhpcyBpcyBub3QgbmV3IG9yIGV2ZW4gY29tcGxl dGVseSBuZXcgdXNlIGNhc2UgYXMgdGhpcyB3YXMgaW4gV1JBUCBhcyB3ZSBhcmUgdXNpbmcgdGhp cyBmZWF0dXJlIG5vdy4gSSB3b3VsZCBhZ3JlZSB0aGF0IGl04oCZcyBub3QgdmVyeSB3ZWxsIGRv Y3VtZW50ZWQgYnV0IHRoYXQgd2FzIGF0dGVtcHRlZCBieSBZYXJvbiBpbiBoaXMgYXBwZW5kIHdh cyB0byBjbGFyaWZ5IHRoZSBzdXBwb3J0LiA8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRl ci1jb2xvcjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3InPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48Yj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrJz4gRXJhbiBIYW1tZXItTGFoYXYgPGEgaHJl Zj0ibWFpbHRvOlttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0iIHRhcmdldD0iX2JsYW5rIj5b bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dPC9hPiA8YnI+PGI+U2VudDo8L2I+IEZyaWRheSwg QXByaWwgMjIsIDIwMTEgMzoyNSBQTTxicj48Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbjsgRGlj ayBIYXJkdDxicj48Yj5DYzo8L2I+IE9BdXRoIFdHPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBSZXZpc2VkIFNlY3Rpb24gMzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluO2JvcmRlci1jb2xvcjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3In PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayc+RnJvbTogPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayc+QW50aG9ueSBOYWRhbGlu ICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+PGI+RGF0ZTogPC9iPkZyaSwgMjIg QXByIDIwMTEgMTQ6NTE6MzMgLTA3MDA8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCA0LjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xv ciAtbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3IgcmdiKDE4MSwgMTk2LCAy MjMpJyBpZD0ieWl2MTIwMTg2Nzk0Mk1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUi PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0 ZSc+PHNwYW4gY2xhc3M9eWl2MTIwMTg2Nzk0MmFwcGxlLXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6IzFGNDk3RCc+QUpOLSZndDsgU28gdGhlIGNsaWVudCBj cmVkZW50aWFscyBvcmlnaW5hdGUgZnJvbSBXUkFQIGFsc28sIGl04oCZcyBub3QgY29tcGxldGVs eSBuZXcsIGl0IG1heSBiZSBuZXcgdGhlIHdheSB0aGF0IGl0IGdvdCB3b3JkZWQgYnV0IHRoZSBz YW1lIGZ1bmN0aW9uYWxpdHkgd2FzIGluIFdSQVAuIFRoZSZuYnNwOyBzZWN0aW9uIDUuMiAoYW5k IHN1YnNlY3Rpb25zKSBpbiB0aGUgV0FQIHNwZWNpZmljYXRpb24gaXMgd2hlcmUgeW91IHNlZSB0 aGUgYXNzZXJ0aW9uIGRvY3VtZW50ZWQgYnV0IHdoYXQgaXMgbm90IGV4cGxpY2l0bHkgc3RhdGVk IChvdGhlciB0aGFuIGFkZGl0aW9uYWwgcGFyYW1ldGVycyBjbGF1c2UpdGhlcmUgYnV0IG5vdCBk aXNhbGxvd2VkIGlzIHRoZSBhYmlsaXR5IHRvIGhhdmUgdGhlIGFjY2Vzc190b2tlbiAoYWRkaXRp b25hbCBwYXJhbWV0ZXJzKSBhbHNvIHNwZWNpZmllZCBzbyB5b3Ugd2VyZSBhbGxvd2VkIHRvIGhh dmUgMiBhc3NlcnRpb25zIGluIFdSQVAgZm9yIGF1dGhlbnRpY2F0aW9uPC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh Y2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayc+SXQgaXMgY29tcGxldGVseSBuZXcuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2snPlRoZSB0d28gYXNzZXJ0aW9ucyBmdW5jdGlvbmFsaXR5IGlzIGNlcnRh aW5seSBOT1QgaW4gV1JBUC4gSXQgaXMgbm90IGV2ZW4gaGludGVkIGF0Ljwvc3Bhbj48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrJz5TZWVtcyB0byBtZSB5b3UganVzdCBt YWRlIG15IGNhc2UgZm9yIGRyb3BwaW5nIHRoaXMgaXNzdWUuIElmIHRoaXMgaXMgeW91ciByYXRp b25hbCBmb3IgYWRkaW5nIHR3byBhc3NlcnRpb25zIHN1cHBvcnQgaW4gdjIsIHRoZW4gd2UgY2Fu IGJlIGRvbmUgcmlnaHQgbm93LiB2MiBhbHJlYWR5IGdpdmVzIHlvdSB0aGUgZXhhY3Qgc2FtZSAn YWRkaXRpb25hbCBwYXJhbWV0ZXJzJyBzdXBwb3J0IGFuZCBkb2VzIG5vdCBkaXNhbGxvdyB0d28g YXNzZXJ0aW9ucy4gWW91IGhhdmUgbWFkZSBzdGF0ZW1lbnRzIGluIHRoZSBwYXN0IHRoYXQgV1JB UCBkaWQgZXZlcnl0aGluZyB5b3UgbmVlZGVkIGFuZCB0aGF0IHYyIGhhcyB0byBjb3ZlciB0aGUg c2FtZSBzY29wZS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh Y2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayc+V2VsbCwgaXQgYWxyZWFkeSBkb2VzLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrJz5XZSBjYW4gY2VydGFpbmx5IGNvbnRpbnVlIHRvIGRlYmF0ZSB3aGV0 aGVyIHYyIG5lZWRzIHRvIGFkZHJlc3MgdGhpcyBuZXcgdXNlIGNhc2UsIGFuZCBpZiBzbyBob3cg dG8gYWNjb21wbGlzaCBpdCwgYnV0IHRoYXQgaXMgYmFzZWQgc29sZWx5IG9uIG5ldyByZXF1aXJl bWVudHMgYW5kIGlzIGFuIGV4cGFuc2lvbiBvZiB0aGUgYWdyZWVkIHByb3RvY29sIHNjb3BlIChX UkFQICsgT0F1dGggMS4wKS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtjb2xv cjpibGFjayc+RUhMPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh Y2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPk9BdXRoIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E723447535BBFA6P3PW5EX1MB01E_-- From eran@hueniverse.com Fri Apr 22 17:18:37 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D111BE066B for ; Fri, 22 Apr 2011 17:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGBLevbgRWfL for ; Fri, 22 Apr 2011 17:18:34 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id E8510E00BE for ; Fri, 22 Apr 2011 17:18:33 -0700 (PDT) Received: (qmail 12958 invoked from network); 23 Apr 2011 00:18:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 23 Apr 2011 00:18:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 22 Apr 2011 17:18:31 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , Dick Hardt Date: Fri, 22 Apr 2011 17:18:18 -0700 Thread-Topic: [OAUTH-WG] Revised Section 3 Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAB2/gYAAA7I5gAADPdkAAAF71YAAAvT6gAABnOkAAAAhFQAAAJ1bAAABBRIAAAIBpIAAATynAAAAMeuAACk2iiAADuGQAAAm7+iAAAIawIAALNYVsAALpPcAAAAY5aAAAEP/cAAANtkAAALyxiA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BBFA8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447535BBF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723447535BBFA8P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 23 Apr 2011 00:18:38 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447535BBFA8P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are you kidding me? "Not the best spelled out feature"? It is not spelled at all. Not using a single character! Maybe Dick was usin= g magic ink for this section. Here are the facts: The WRAP specification does not preclude the usage of 2 assertions. V2 does= not preclude the usage of 2 assertions. WRAP supports additional parameters. V2 supports additional parameters. V2's support for 2 assertions is IDENTICAL to that of WRAP. Whatever code is running at Microsoft is clearly not based on any *publishe= d* specification presented to this working group. EHL From: Anthony Nadalin [mailto:tonynad@microsoft.com] Sent: Friday, April 22, 2011 3:45 PM To: Eran Hammer-Lahav; Dick Hardt Cc: OAuth WG Subject: RE: [OAUTH-WG] Revised Section 3 Not sure I have to show you anything. The WRAP specification does not precl= ude the usage of 2 assertions as this was one of the must support use cases= for WRAP. As I indicated this was not the best spelled out feature in the = WRAP specification. Yaron's append was an attempt to clarify the use case w= ith additional text. If you want to come on site you can see the code and t= he dates on the code that predates Yaron's text. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, April 22, 2011 3:40 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG Subject: RE: [OAUTH-WG] Revised Section 3 Let me make sure we're clear here: Your argument is that this is not a new use case because WRAP allows 'addit= ional parameters' and doesn't explicitly forbids it? If I missed something, please quote the exact normative language in WRAP sh= owing how to use two assertions, or any text differentiating between using = an assertion for client authentication vs. using an assertion for resource = owner authorization. Show me anything that pre-dates Yaron's text documenti= ng the two assertions use case. EHL From: Anthony Nadalin [mailto:tonynad@microsoft.com] Sent: Friday, April 22, 2011 3:34 PM To: Eran Hammer-Lahav; Dick Hardt Cc: OAuth WG Subject: RE: [OAUTH-WG] Revised Section 3 I disagree here, this is not new or even completely new use case as this wa= s in WRAP as we are using this feature now. I would agree that it's not ver= y well documented but that was attempted by Yaron in his append was to clar= ify the support. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, April 22, 2011 3:25 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 From: Anthony Nadalin > Date: Fri, 22 Apr 2011 14:51:33 -0700 AJN-> So the client credentials originate from WRAP also, it's not complete= ly new, it may be new the way that it got worded but the same functionality= was in WRAP. The section 5.2 (and subsections) in the WAP specification i= s where you see the assertion documented but what is not explicitly stated = (other than additional parameters clause)there but not disallowed is the ab= ility to have the access_token (additional parameters) also specified so yo= u were allowed to have 2 assertions in WRAP for authentication It is completely new. The two assertions functionality is certainly NOT in WRAP. It is not even h= inted at. Seems to me you just made my case for dropping this issue. If this is your = rational for adding two assertions support in v2, then we can be done right= now. v2 already gives you the exact same 'additional parameters' support a= nd does not disallow two assertions. You have made statements in the past t= hat WRAP did everything you needed and that v2 has to cover the same scope. Well, it already does. We can certainly continue to debate whether v2 needs to address this new us= e case, and if so how to accomplish it, but that is based solely on new req= uirements and is an expansion of the agreed protocol scope (WRAP + OAuth 1.= 0). EHL --_000_90C41DD21FB7C64BB94121FBBC2E723447535BBFA8P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are you k= idding me? “Not the best spelled out feature”?

 

It is not spelled at all. Not using a single character! Maybe= Dick was using magic ink for this section.

 

Here are the facts:

 

The WRAP specification = does not preclude the usage of 2 assertions. V2 does not preclude the usage= of 2 assertions.

WRAP sup= ports additional parameters. V2 supports additional parameters.<= /span>

 

V2’s support for 2 assertions is IDENTICAL to tha= t of WRAP.

 

Whatever code is running at Micros= oft is clearly not based on any *published* specification presented = to this working group.

 

EHL<= /p>

 

 

&n= bsp;

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Anthony = Nadalin [mailto:tonynad@microsoft.com]
Sent: Friday, April 22, 2= 011 3:45 PM
To: Eran Hammer-Lahav; Dick Hardt
Cc: OAuth= WG
Subject: RE: [OAUTH-WG] Revised Section 3

 

Not sure I have to show you anything. The WRAP specification does = not preclude the usage of 2 assertions as this was one of the must support = use cases for WRAP. As I indicated this was not the best spelled out featur= e in the WRAP specification. Yaron’s append was an attempt to clarify= the use case with additional text. If you want to come on site you can see= the code and the dates on the code that predates Yaron’s text. =

 

From: Eran Hammer-Lahav [mailto:eran@huenive= rse.com]
Sent: Friday, April 22, 2011 3:40 PM
To: Anth= ony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUT= H-WG] Revised Section 3

 

Let me make sure weR= 17;re clear here:

&nb= sp;

Your argument is that this = is not a new use case because WRAP allows ‘additional parameters̵= 7; and doesn’t explicitly forbids it?

 

If I missed something, please quote the exact normative language in WRAP s= howing how to use two assertions, or any text differentiating between using= an assertion for client authentication vs. using an assertion for resource= owner authorization. Show me anything that pre-dates Yaron’s text do= cumenting the two assertions use case.

 

EHL<= o:p>

 

 

From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Fri= day, April 22, 2011 3:34 PM
To: Eran Hammer-Lahav; Dick Hardt
= Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3

 

I disagree here, this is not new or even completel= y new use case as this was in WRAP as we are using this feature now. I woul= d agree that it’s not very well documented but that was attempted by = Yaron in his append was to clarify the support.

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Friday, April 22,= 2011 3:25 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth= WG
Subject: Re: [OAUTH-WG] Revised Section 3

 

 

 

F= rom: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 22 Apr 2011 14:51= :33 -0700

&= nbsp;

AJN-> So the client credentials originate from WRAP also, it’s= not completely new, it may be new the way that it got worded but the same = functionality was in WRAP. The  section 5.2 (and subsections) in the W= AP specification is where you see the assertion documented but what is not = explicitly stated (other than additional parameters clause)there but not di= sallowed is the ability to have the access_token (additional parameters) al= so specified so you were allowed to have 2 assertions in WRAP for authentic= ation

=

 <= /p>

It is completely new.

 

The two assertions functionality is cert= ainly NOT in WRAP. It is not even hinted at.

 

Seems to me you just made my case for dropping this issue= . If this is your rational for adding two assertions support in v2, then we= can be done right now. v2 already gives you the exact same 'additional par= ameters' support and does not disallow two assertions. You have made statem= ents in the past that WRAP did everything you needed and that v2 has to cov= er the same scope.

 

Well, = it already does.

=  

We can cer= tainly continue to debate whether v2 needs to address this new use case, an= d if so how to accomplish it, but that is based solely on new requirements = and is an expansion of the agreed protocol scope (WRAP + OAuth 1.0).

 

EHL

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723447535BBFA8P3PW5EX1MB01E_-- From eran@hueniverse.com Fri Apr 22 17:30:30 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9A571E066B for ; Fri, 22 Apr 2011 17:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMvUkK2FGT8X for ; Fri, 22 Apr 2011 17:30:30 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfc.amsl.com (Postfix) with SMTP id DAE18E00BE for ; Fri, 22 Apr 2011 17:30:29 -0700 (PDT) Received: (qmail 27919 invoked from network); 23 Apr 2011 00:30:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 23 Apr 2011 00:30:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 22 Apr 2011 17:30:29 -0700 From: Eran Hammer-Lahav To: David Recordon , Melinda Shore Date: Fri, 22 Apr 2011 17:30:16 -0700 Thread-Topic: [OAUTH-WG] OAuth Interim Meeting Thread-Index: AcwBM+uijnc1kDylTxOG/UlZG4P89AAGa4Kg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447535BBFAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] OAuth Interim 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, 23 Apr 2011 00:30:30 -0000 +1 for Facebook. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of David Recordon > Sent: Friday, April 22, 2011 2:26 PM > To: Melinda Shore > Cc: Barry Leiba; OAuth WG > Subject: Re: [OAUTH-WG] OAuth Interim Meeting >=20 > I can setup audio and video conferencing if it's at Facebook. >=20 > On Fri, Apr 22, 2011 at 12:13 PM, Melinda Shore > wrote: > > I'm unable to attend in person but I'm hoping that remote > > participation will be an option - any hope of that? > > > > Thanks, > > > > Melinda > > _______________________________________________ > > OAuth mailing 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 dick.hardt@gmail.com Fri Apr 22 18:25:34 2011 Return-Path: X-Original-To: oauth@ietfc.amsl.com Delivered-To: oauth@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CA432E06C6 for ; Fri, 22 Apr 2011 18:25:34 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ncs0ALsdRIUy for ; Fri, 22 Apr 2011 18:25:34 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfc.amsl.com (Postfix) with ESMTP id 09D67E06C0 for ; Fri, 22 Apr 2011 18:25:33 -0700 (PDT) Received: by pvh1 with SMTP id 1so685644pvh.31 for ; Fri, 22 Apr 2011 18:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=dCm6slZ4cqw6zAcXM+afWCTmIgzjzCqUlCHlIPN1ms4=; b=kAV+tvWD1hqr/sTFhdp3j5PRl1XPNj9AdQAIwY8MDSO1/LXSwnM/ZcqlSG6tricewy TEqSbBbHegRCglmkoQunrV/kjomMOYeecwjVFwuUe1bVG6uN0+FLzOpRkzrQWUvoY51v ArBT+V1ITrMp8ZbFE74OB8SSiYIHivEAAxkV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=GQM9XEpBo/Gjkr2gdtBsfKx6jf4wqX7CpAPl79fq6anjsCmSlqxqexdOf1dwk0suuD b/xUd43P9ZI6J8TUebb4q2Yd6LJAL+dNf2CBnv268f1MIRNo+nNHK4KYnyLSngQVaJhw RwvmlpJ/D2Oy8cIg9tgxWH+ABq9xCHLg/3nYg= Received: by 10.68.36.199 with SMTP id s7mr2652800pbj.131.1303521933470; Fri, 22 Apr 2011 18:25:33 -0700 (PDT) Received: from [192.168.1.16] (c-24-5-83-209.hsd1.ca.comcast.net [24.5.83.209]) by mx.google.com with ESMTPS id r5sm2326254pbe.101.2011.04.22.18.25.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2011 18:25:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6-944698505 From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BBFA8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 22 Apr 2011 18:25:29 -0700 Message-Id: <3F9C736A-3DA6-4712-AFD1-93BFD7648CA8@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E723447535BBF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447535BBFA8@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 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, 23 Apr 2011 01:25:35 -0000 --Apple-Mail-6-944698505 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2011-04-22, at 5:18 PM, Eran Hammer-Lahav wrote: > Are you kidding me? =93Not the best spelled out feature=94? > =20 > It is not spelled at all. Not using a single character! Maybe Dick was = using magic ink for this section. No magic ink was used. :) Tony: I looked over your last emails and while I can guess what you = want, a *clear* description of the flow you are looking for would enable = me to bridge the gap between WRAP and OAuth 2.0. -- Dick= --Apple-Mail-6-944698505 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 2011-04-22, at 5:18 PM, Eran = Hammer-Lahav wrote:

Are = you kidding me? =93Not the best spelled out = feature=94?
It is = not spelled at all. Not using a single character! Maybe Dick was using = magic ink for this = section.

No = magic ink was used. :)

Tony: I looked over your = last emails and while I can guess what you want, a *clear* description = of the flow you are looking for would enable me to bridge the gap = between WRAP and OAuth 2.0.

-- = Dick
= --Apple-Mail-6-944698505-- From hannes.tschofenig@gmx.net Wed Apr 27 08:06:37 2011 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 ABD7DE06EE for ; Wed, 27 Apr 2011 08:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 yzzMZ761X6w3 for ; Wed, 27 Apr 2011 08:06:33 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 214BBE06EC for ; Wed, 27 Apr 2011 08:06:32 -0700 (PDT) Received: (qmail invoked by alias); 27 Apr 2011 15:06:30 -0000 Received: from 173-15-128-153-BusName-Philadelphia.hfc.comcastbusiness.net (EHLO [10.77.87.102]) [173.15.128.153] by mail.gmx.net (mp062) with SMTP; 27 Apr 2011 17:06:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19RIrYpzW1RxtVYjkPbavNQncAFmqGmJIHFqS99lh qCy+8MfQFwW5dp From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Apr 2011 18:06:28 +0300 Message-Id: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about 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: Wed, 27 Apr 2011 15:06:37 -0000 Hi guys,=20 Barry, Blaine and I compiled a short position paper for the upcoming W3C = identity in the browser workshop.=20 Here is the call for participation: = http://www.tschofenig.priv.at/svn/w3c-browser-identity/ Here is the position paper:=20 http://www.tschofenig.priv.at/svn/w3c-browser-identity/oauth.pdf Let us know if you have some comments. We are happy to incorporate them. = The submission deadline is unfortunately today. This is yet another one = of these last minute things, I know.=20 Ciao Hannes From paul.madsen@gmail.com Wed Apr 27 08:17:49 2011 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 603F2E07AD for ; Wed, 27 Apr 2011 08:17: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=[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 sp+jKhp1m1vr for ; Wed, 27 Apr 2011 08:17:48 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A761E07AA for ; Wed, 27 Apr 2011 08:17:48 -0700 (PDT) Received: by gxk19 with SMTP id 19so769999gxk.31 for ; Wed, 27 Apr 2011 08:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=O8+UE/eE5a6VVz6c6DbE5Hdd5BE8kwU6fdBQqq7jcSk=; b=NO6ZvQKCjtz+EIkvdGUAJ5PB92gY2v35JUfaLWZ2dW2VWjQhCvt7Uiaz3Hzo+NmCSn fCRtaQ7xVfKLFk+wfR01x7y14Dxcu+JrrOA/wDFMfUih8CKkRFiS74SDxpoei+xfqfjl cgxyAVzsvIArM4emcZ+bNKHAzcKpvlgfhff6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Rw2bB/zmsiSmsvgl8UrRuUO+vdhhUQBSPeQ6tmJ0kxmKy9BJi7nSYKVVfS6uE76+nI EeulNBC2vP7SQrNztY/hpo4PV/Mfi9571rjxMgfowwdjWTIiIeSlDrxQG+VlkJvAos+6 vTeCNkZAdh3UkbN/f+75gbEZP3+mfr/Brd+eM= Received: by 10.101.72.9 with SMTP id z9mr1503903ank.64.1303917467712; Wed, 27 Apr 2011 08:17:47 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id g37sm866496anj.28.2011.04.27.08.17.45 (version=SSLv3 cipher=OTHER); Wed, 27 Apr 2011 08:17:45 -0700 (PDT) Message-ID: <4DB83397.4080800@gmail.com> Date: Wed, 27 Apr 2011 11:17:43 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: oauth@ietf.org References: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> In-Reply-To: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about 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: Wed, 27 Apr 2011 15:17:49 -0000 'Open Web Authentication protocol'? authentication? On 4/27/11 11:06 AM, Hannes Tschofenig wrote: > Hi guys, > > Barry, Blaine and I compiled a short position paper for the upcoming W3C identity in the browser workshop. > Here is the call for participation: http://www.tschofenig.priv.at/svn/w3c-browser-identity/ > > Here is the position paper: > http://www.tschofenig.priv.at/svn/w3c-browser-identity/oauth.pdf > > Let us know if you have some comments. We are happy to incorporate them. The submission deadline is unfortunately today. This is yet another one of these last minute things, I know. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dnelson@elbrys.com Wed Apr 27 08:23:26 2011 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 7056AE06EC for ; Wed, 27 Apr 2011 08:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 eH3bkruxyh8X for ; Wed, 27 Apr 2011 08:23:25 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with SMTP id 41A8DE070B for ; Wed, 27 Apr 2011 08:23:25 -0700 (PDT) Received: from mail-yi0-f51.google.com ([209.85.218.51]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTbg07HlXaOjp2RKeOSl7LZaT2tnfex/8@postini.com; Wed, 27 Apr 2011 08:23:25 PDT Received: by mail-yi0-f51.google.com with SMTP id 2so632627yib.10 for ; Wed, 27 Apr 2011 08:23:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.189.101 with SMTP id b65mr2911739yhn.115.1303917801928; Wed, 27 Apr 2011 08:23:21 -0700 (PDT) Received: by 10.236.111.45 with HTTP; Wed, 27 Apr 2011 08:23:21 -0700 (PDT) In-Reply-To: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> References: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> Date: Wed, 27 Apr 2011 11:23:21 -0400 Message-ID: From: Dave Nelson To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about 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: Wed, 27 Apr 2011 15:23:26 -0000 Hi Hannes, One comment immediately in the title. Isn't OAuth short for Open Authorization, not Authentication? Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 From eran@hueniverse.com Wed Apr 27 08:24:09 2011 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 3542BE0759 for ; Wed, 27 Apr 2011 08:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDIrajRIaSVQ for ; Wed, 27 Apr 2011 08:24:08 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 49338E06EC for ; Wed, 27 Apr 2011 08:24:08 -0700 (PDT) Received: (qmail 29270 invoked from network); 27 Apr 2011 15:24:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 27 Apr 2011 15:24:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 27 Apr 2011 08:23:54 -0700 From: Eran Hammer-Lahav To: Paul Madsen , "oauth@ietf.org" Date: Wed, 27 Apr 2011 08:23:33 -0700 Thread-Topic: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about OAuth Thread-Index: AcwE7kiWvRg61Nn5T/axWXXF1YeXAgAAJQlw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447537EA4B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> <4DB83397.4080800@gmail.com> In-Reply-To: <4DB83397.4080800@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about 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: Wed, 27 Apr 2011 15:24:09 -0000 It's a relic from the formation of the working group. I did find it amusing that the paper defines bearer token as a 'cryptograph= ic approach'. I guess no crypto is in its way an approach :-). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Paul Madsen > Sent: Wednesday, April 27, 2011 8:18 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser > Workshop about OAuth >=20 > 'Open Web Authentication protocol'? authentication? >=20 > On 4/27/11 11:06 AM, Hannes Tschofenig wrote: > > Hi guys, > > > > Barry, Blaine and I compiled a short position paper for the upcoming W3= C > identity in the browser workshop. > > Here is the call for participation: http://www.tschofenig.priv.at/svn/w= 3c- > browser-identity/ > > > > Here is the position paper: > > http://www.tschofenig.priv.at/svn/w3c-browser-identity/oauth.pdf > > > > Let us know if you have some comments. We are happy to incorporate > them. The submission deadline is unfortunately today. This is yet anothe= r > one of these last minute things, I know. > > > > Ciao > > Hannes > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Wed Apr 27 08:36:04 2011 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 260E3E0734 for ; Wed, 27 Apr 2011 08:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 3uxJGkaRwBL4 for ; Wed, 27 Apr 2011 08:36:03 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2CA49E06B2 for ; Wed, 27 Apr 2011 08:36:03 -0700 (PDT) Received: (qmail invoked by alias); 27 Apr 2011 15:36:01 -0000 Received: from 173-15-128-153-BusName-Philadelphia.hfc.comcastbusiness.net (EHLO [10.77.87.102]) [173.15.128.153] by mail.gmx.net (mp007) with SMTP; 27 Apr 2011 17:36:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18pqMEX9OUprKUBE1akeg2XWtHpuHDkC9ptFqGZu6 0EeUsxdyvq2rgL Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4DB83397.4080800@gmail.com> Date: Wed, 27 Apr 2011 18:35:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0D9A6C34-3CBD-40B2-BAFA-6310557565E5@gmx.net> References: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> <4DB83397.4080800@gmail.com> To: Paul Madsen X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about 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: Wed, 27 Apr 2011 15:36:04 -0000 In some sense you are right. The problem is just that this is the name = of the group :-) http://datatracker.ietf.org/wg/oauth/charter/ Maybe we should adjust the name with the rechartering process.=20 On Apr 27, 2011, at 6:17 PM, Paul Madsen wrote: > 'Open Web Authentication protocol'? authentication? >=20 > On 4/27/11 11:06 AM, Hannes Tschofenig wrote: >> Hi guys, >>=20 >> Barry, Blaine and I compiled a short position paper for the upcoming = W3C identity in the browser workshop. >> Here is the call for participation: = http://www.tschofenig.priv.at/svn/w3c-browser-identity/ >>=20 >> Here is the position paper: >> http://www.tschofenig.priv.at/svn/w3c-browser-identity/oauth.pdf >>=20 >> Let us know if you have some comments. We are happy to incorporate = them. The submission deadline is unfortunately today. This is yet = another one of these last minute things, I know. >>=20 >> Ciao >> Hannes >>=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 torsten@lodderstedt.net Wed Apr 27 08:38:58 2011 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 749FAE070E for ; Wed, 27 Apr 2011 08:38:58 -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 xACmU9qiZY1p for ; Wed, 27 Apr 2011 08:38:58 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by ietfa.amsl.com (Postfix) with ESMTP id C8CD7E070B for ; Wed, 27 Apr 2011 08:38:56 -0700 (PDT) Received: from [79.39.129.33] (helo=[192.168.1.133]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QF6pK-0003Hp-6I; Wed, 27 Apr 2011 17:38:54 +0200 Message-ID: <4DB8388F.70906@lodderstedt.net> Date: Wed, 27 Apr 2011 17:38:55 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hannes Tschofenig References: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> <4DB83397.4080800@gmail.com> <0D9A6C34-3CBD-40B2-BAFA-6310557565E5@gmx.net> In-Reply-To: <0D9A6C34-3CBD-40B2-BAFA-6310557565E5@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about 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: Wed, 27 Apr 2011 15:38:58 -0000 Am 27.04.2011 17:35, schrieb Hannes Tschofenig: > In some sense you are right. The problem is just that this is the name of the group :-) > http://datatracker.ietf.org/wg/oauth/charter/ > > Maybe we should adjust the name with the rechartering process. I think we should. regards, Torsten. > On Apr 27, 2011, at 6:17 PM, Paul Madsen wrote: > >> 'Open Web Authentication protocol'? authentication? >> >> On 4/27/11 11:06 AM, Hannes Tschofenig wrote: >>> Hi guys, >>> >>> Barry, Blaine and I compiled a short position paper for the upcoming W3C identity in the browser workshop. >>> Here is the call for participation: http://www.tschofenig.priv.at/svn/w3c-browser-identity/ >>> >>> Here is the position paper: >>> http://www.tschofenig.priv.at/svn/w3c-browser-identity/oauth.pdf >>> >>> Let us know if you have some comments. We are happy to incorporate them. The submission deadline is unfortunately today. This is yet another one of these last minute things, I know. >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From paul.madsen@gmail.com Wed Apr 27 08:40:35 2011 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 D5D94E0759 for ; Wed, 27 Apr 2011 08:40:35 -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 SlQxT8aXjWZ9 for ; Wed, 27 Apr 2011 08:40:34 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2957E06F7 for ; Wed, 27 Apr 2011 08:40:34 -0700 (PDT) Received: by yxk30 with SMTP id 30so579903yxk.31 for ; Wed, 27 Apr 2011 08:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dbjlDVZ+gCcbBdo7aRyGJ+G5cGN8Ft0aQ8Zio9Tz8zA=; b=IwZ4FMbQXKgoNzdx/CONJubConT9ZZDAtZ/F5wqf8BoL1iOxWYNDlBvO78Jwn2YKx6 30eeIbhAhAzdHUNVANVgP8ax2o1UZ94fxyIjGC8r1R9zpIXKWm7Eg+ThyRNUi+C2jxcR 06TGraHj91YFSTo62BvHrjqilEvTPfU5AyMTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=DkA5ferHY432tVAX0P/yzXeb+LvjdeMkeKmy1PnNyrN3p15B7kUatVIxqEv6ogCGNK 582/i1Wy7tdGU66zNd2lAh2qxXZeoBHVm+gmYVPJQISoOEhyPw7tAp9F5wmEZFZbw7Y0 BukOjjqWE/Y80t/yClKhdsJxmeDc0bZA7nJ9g= Received: by 10.100.105.14 with SMTP id d14mr402779anc.26.1303918834132; Wed, 27 Apr 2011 08:40:34 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id w6sm887077anf.6.2011.04.27.08.40.32 (version=SSLv3 cipher=OTHER); Wed, 27 Apr 2011 08:40:32 -0700 (PDT) Message-ID: <4DB838EE.9050202@gmail.com> Date: Wed, 27 Apr 2011 11:40:30 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hannes Tschofenig References: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> <4DB83397.4080800@gmail.com> <0D9A6C34-3CBD-40B2-BAFA-6310557565E5@gmx.net> In-Reply-To: <0D9A6C34-3CBD-40B2-BAFA-6310557565E5@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about 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: Wed, 27 Apr 2011 15:40:36 -0000 but you are describing the protocol in the paper, not the group A reference like 'The Open Web Authentication (OAuth) protocol [1]' to [1] E. Hammer-Lahav, D. Recordon, and D. Hardt, “The OAuth 2.0 Authorization Protocol,” is going to confuse On 4/27/11 11:35 AM, Hannes Tschofenig wrote: > In some sense you are right. The problem is just that this is the name of the group :-) > http://datatracker.ietf.org/wg/oauth/charter/ > > Maybe we should adjust the name with the rechartering process. > > On Apr 27, 2011, at 6:17 PM, Paul Madsen wrote: > >> 'Open Web Authentication protocol'? authentication? >> >> On 4/27/11 11:06 AM, Hannes Tschofenig wrote: >>> Hi guys, >>> >>> Barry, Blaine and I compiled a short position paper for the upcoming W3C identity in the browser workshop. >>> Here is the call for participation: http://www.tschofenig.priv.at/svn/w3c-browser-identity/ >>> >>> Here is the position paper: >>> http://www.tschofenig.priv.at/svn/w3c-browser-identity/oauth.pdf >>> >>> Let us know if you have some comments. We are happy to incorporate them. The submission deadline is unfortunately today. This is yet another one of these last minute things, I know. >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Apr 27 08:49:14 2011 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 9B5F9E07C4 for ; Wed, 27 Apr 2011 08:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBJ2ECihT2ES for ; Wed, 27 Apr 2011 08:49:13 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 62CD3E07D3 for ; Wed, 27 Apr 2011 08:48:56 -0700 (PDT) Received: (qmail 32158 invoked from network); 27 Apr 2011 15:48:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 27 Apr 2011 15:48:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 27 Apr 2011 08:48:45 -0700 From: Eran Hammer-Lahav To: Paul Madsen , Hannes Tschofenig Date: Wed, 27 Apr 2011 08:48:25 -0700 Thread-Topic: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about OAuth Thread-Index: AcwE8Xn4pizHXZ3IT/GvfshdZk6b4wAAQgUQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447537EA4DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> <4DB83397.4080800@gmail.com> <0D9A6C34-3CBD-40B2-BAFA-6310557565E5@gmx.net> <4DB838EE.9050202@gmail.com> In-Reply-To: <4DB838EE.9050202@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about 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: Wed, 27 Apr 2011 15:49:14 -0000 This is true. There is no Open Web Authentication protocol. Only a WG. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Paul Madsen > Sent: Wednesday, April 27, 2011 8:41 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser > Workshop about OAuth >=20 > but you are describing the protocol in the paper, not the group >=20 > A reference like 'The Open Web Authentication (OAuth) protocol [1]' >=20 > to >=20 > [1] E. Hammer-Lahav, D. Recordon, and D. Hardt, "The OAuth 2.0 > Authorization Protocol," >=20 > is going to confuse >=20 >=20 > On 4/27/11 11:35 AM, Hannes Tschofenig wrote: > > In some sense you are right. The problem is just that this is the name > > of the group :-) http://datatracker.ietf.org/wg/oauth/charter/ > > > > Maybe we should adjust the name with the rechartering process. > > > > On Apr 27, 2011, at 6:17 PM, Paul Madsen wrote: > > > >> 'Open Web Authentication protocol'? authentication? > >> > >> On 4/27/11 11:06 AM, Hannes Tschofenig wrote: > >>> Hi guys, > >>> > >>> Barry, Blaine and I compiled a short position paper for the upcoming = W3C > identity in the browser workshop. > >>> Here is the call for participation: > >>> http://www.tschofenig.priv.at/svn/w3c-browser-identity/ > >>> > >>> Here is the position paper: > >>> http://www.tschofenig.priv.at/svn/w3c-browser-identity/oauth.pdf > >>> > >>> Let us know if you have some comments. We are happy to incorporate > them. The submission deadline is unfortunately today. This is yet anothe= r > one of these last minute things, I know. > >>> > >>> Ciao > >>> Hannes > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Wed Apr 27 08:50:31 2011 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 6F16EE07DD for ; Wed, 27 Apr 2011 08:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 RRWirsD2j6Z7 for ; Wed, 27 Apr 2011 08:50:30 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A62C1E0839 for ; Wed, 27 Apr 2011 08:50:30 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p3RFoPUT011495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2011 10:50:25 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3RFoPAj015126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Apr 2011 10:50:25 -0500 Received: from [135.244.33.207] (faynberg.lra.lucent.com [135.244.33.207]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p3RFoOJb014640; Wed, 27 Apr 2011 10:50:24 -0500 (CDT) Message-ID: <4DB83B40.4070706@alcatel-lucent.com> Date: Wed, 27 Apr 2011 11:50:24 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Paul Madsen References: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> <4DB83397.4080800@gmail.com> <0D9A6C34-3CBD-40B2-BAFA-6310557565E5@gmx.net> <4DB838EE.9050202@gmail.com> In-Reply-To: <4DB838EE.9050202@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about OAuth 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, 27 Apr 2011 15:50:31 -0000 Good eye! (And an excellent point.) Igor Paul Madsen wrote: > but you are describing the protocol in the paper, not the group > > A reference like 'The Open Web Authentication (OAuth) protocol [1]' > > to > > [1] E. Hammer-Lahav, D. Recordon, and D. Hardt, “The OAuth 2.0 > Authorization Protocol,” > > is going to confuse > > > On 4/27/11 11:35 AM, Hannes Tschofenig wrote: >> In some sense you are right. The problem is just that this is the >> name of the group :-) >> http://datatracker.ietf.org/wg/oauth/charter/ >> >> Maybe we should adjust the name with the rechartering process. >> >> On Apr 27, 2011, at 6:17 PM, Paul Madsen wrote: >> >>> 'Open Web Authentication protocol'? authentication? >>> >>> On 4/27/11 11:06 AM, Hannes Tschofenig wrote: >>>> Hi guys, >>>> >>>> Barry, Blaine and I compiled a short position paper for the >>>> upcoming W3C identity in the browser workshop. >>>> Here is the call for participation: >>>> http://www.tschofenig.priv.at/svn/w3c-browser-identity/ >>>> >>>> Here is the position paper: >>>> http://www.tschofenig.priv.at/svn/w3c-browser-identity/oauth.pdf >>>> >>>> Let us know if you have some comments. We are happy to incorporate >>>> them. The submission deadline is unfortunately today. This is yet >>>> another one of these last minute things, I know. >>>> >>>> Ciao >>>> Hannes >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Wed Apr 27 09:09:07 2011 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 D692DE07E9 for ; Wed, 27 Apr 2011 09:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 p-Pb-TPBUkso for ; Wed, 27 Apr 2011 09:09:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B00CCE07CC for ; Wed, 27 Apr 2011 09:09:06 -0700 (PDT) Received: (qmail invoked by alias); 27 Apr 2011 16:09:05 -0000 Received: from 173-15-128-153-BusName-Philadelphia.hfc.comcastbusiness.net (EHLO [10.77.87.102]) [173.15.128.153] by mail.gmx.net (mp040) with SMTP; 27 Apr 2011 18:09:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+gXsIltGCgevD3es+icOZenFjodkpGB48I4OJ8OO GL3Qe7WymNl8aG Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: <4DB83B40.4070706@alcatel-lucent.com> Date: Wed, 27 Apr 2011 19:09:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <00839DC5-7AC5-4C88-8C16-8395355E0B5B@gmx.net> References: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> <4DB83397.4080800@gmail.com> <0D9A6C34-3CBD-40B2-BAFA-6310557565E5@gmx.net> <4DB838EE.9050202@gmail.com> <4DB83B40.4070706@alcatel-lucent.com> To: igor.faynberg@alcatel-lucent.com X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about 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: Wed, 27 Apr 2011 16:09:07 -0000 Fixed it.=20 Thanks for pointing this out.=20 Ciao Hannes Ps: Did we miss any technical points that would be useful to bring = forward to the Web browser community to improve the security of OAuth? On Apr 27, 2011, at 6:50 PM, Igor Faynberg wrote: > Good eye! (And an excellent point.) >=20 > Igor >=20 > Paul Madsen wrote: >> but you are describing the protocol in the paper, not the group >>=20 >> A reference like 'The Open Web Authentication (OAuth) protocol [1]' >>=20 >> to >>=20 >> [1] E. Hammer-Lahav, D. Recordon, and D. Hardt, =93The OAuth 2.0 = Authorization Protocol,=94 >>=20 >> is going to confuse >>=20 >>=20 >> On 4/27/11 11:35 AM, Hannes Tschofenig wrote: >>> In some sense you are right. The problem is just that this is the = name of the group :-) >>> http://datatracker.ietf.org/wg/oauth/charter/ >>>=20 >>> Maybe we should adjust the name with the rechartering process. >>>=20 >>> On Apr 27, 2011, at 6:17 PM, Paul Madsen wrote: >>>=20 >>>> 'Open Web Authentication protocol'? authentication? >>>>=20 >>>> On 4/27/11 11:06 AM, Hannes Tschofenig wrote: >>>>> Hi guys, >>>>>=20 >>>>> Barry, Blaine and I compiled a short position paper for the = upcoming W3C identity in the browser workshop. >>>>> Here is the call for participation: = http://www.tschofenig.priv.at/svn/w3c-browser-identity/ >>>>>=20 >>>>> Here is the position paper: >>>>> http://www.tschofenig.priv.at/svn/w3c-browser-identity/oauth.pdf >>>>>=20 >>>>> Let us know if you have some comments. We are happy to incorporate = them. The submission deadline is unfortunately today. This is yet = another one of these last minute things, I know. >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=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 Axel.Nennker@telekom.de Wed Apr 27 09:09:21 2011 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 CE8A0E07CC for ; Wed, 27 Apr 2011 09:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VUcga+rILyY for ; Wed, 27 Apr 2011 09:09:21 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id A35F7E06EC for ; Wed, 27 Apr 2011 09:09:20 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 27 Apr 2011 18:09:02 +0200 Received: from S4DE9JSAAMU.ost.t-com.de ([10.125.177.112]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 18:09:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Apr 2011 18:09:01 +0200 Message-ID: In-Reply-To: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop aboutOAuth Thread-Index: AcwE7McbhQqfYnUYQIyAzZk9n0kN1gABd7hg References: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> From: To: , X-OriginalArrivalTime: 27 Apr 2011 16:09:02.0610 (UTC) FILETIME=[6CD1F720:01CC04F5] Cc: david@ddahl.com, mhanson@mozilla.com, anders.rundgren@telia.com Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop aboutOAuth 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, 27 Apr 2011 16:09:21 -0000 Hi Hannes, A) Authentication Mechanisms Anders Rundgren is a caller in the desert for this for years: http://webpki.org/ B) Authorization Interface I think this is the point closest to oauth and that needs the most work. C) Standardized JavaScript Crypto Library Support This was discussed e.g. in the NSS group for years https://www.mozilla.org/projects/security/pki/nss/ If I recollect the most common argument right it was: "Developers will implement bad security if we give them the basic crypto building blocks. Combining good crypto A with good crypto B will likely yield bad crypto C" D) Moving Crypto Into the Browser Same comment as for item C. I think your paper should be more specific to oauth's needs and propose what is needed for oauth and the (preferrably) ONE way to use the parts. http://daviddahl.blogspot.com/2011/03/in-which-author-explains-domcrypt- in.html I know of one javascript implementation of signed json web tokens in Firefox. But I think that crypto in javascript is not secure (enough? Besides speed).=20 -Axel > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Wednesday, April 27, 2011 5:06 PM > To: OAuth WG > Subject: [OAUTH-WG] Paper for the W3C Identity in the Browser=20 > Workshop aboutOAuth >=20 > Hi guys,=20 >=20 > Barry, Blaine and I compiled a short position paper for the=20 > upcoming W3C identity in the browser workshop.=20 > Here is the call for participation:=20 > http://www.tschofenig.priv.at/svn/w3c-browser-identity/ >=20 > Here is the position paper:=20 > http://www.tschofenig.priv.at/svn/w3c-browser-identity/oauth.pdf >=20 > Let us know if you have some comments. We are happy to=20 > incorporate them. The submission deadline is unfortunately=20 > today. This is yet another one of these last minute things, I know.=20 >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From hannes.tschofenig@gmx.net Wed Apr 27 09:30:39 2011 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 687DAE076D for ; Wed, 27 Apr 2011 09:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Bkb3a4F7gSBV for ; Wed, 27 Apr 2011 09:30:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 238E4E06C9 for ; Wed, 27 Apr 2011 09:30:37 -0700 (PDT) Received: (qmail invoked by alias); 27 Apr 2011 16:30:36 -0000 Received: from 173-15-128-153-BusName-Philadelphia.hfc.comcastbusiness.net (EHLO [10.77.87.102]) [173.15.128.153] by mail.gmx.net (mp003) with SMTP; 27 Apr 2011 18:30:36 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+3XJpWewW3dMBKO7oYyFcJAGTadQ/ACEYMEmaQQP InPZpT0ZTubSBO Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447537EA4B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 27 Apr 2011 19:30:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3931AD9E-5E3C-4B9F-82B6-9492339EFA2F@gmx.net> References: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> <4DB83397.4080800@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723447537EA4B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop about 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: Wed, 27 Apr 2011 16:30:39 -0000 > I did find it amusing that the paper defines bearer token as a = 'cryptographic approach'. I guess no crypto is in its way an approach = :-). Well. It uses TLS as the underlying primitive. As such, it is a = cryptographic mechanism.=20 I know that we have different views about the pros & cons of the = different approaches.=20 Hence the past writeup about this aspect:=20 http://tools.ietf.org/html/draft-tschofenig-oauth-signature-thoughts-00 From anders.rundgren@telia.com Wed Apr 27 12:51:11 2011 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 27783E06ED for ; Wed, 27 Apr 2011 12:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 KqfaKey5XJqA for ; Wed, 27 Apr 2011 12:51:09 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 683BAE064A for ; Wed, 27 Apr 2011 12:51:09 -0700 (PDT) Received: from [192.168.0.203] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6517A10188A6AC; Wed, 27 Apr 2011 21:50:58 +0200 Message-ID: <4DB873B0.60907@telia.com> Date: Wed, 27 Apr 2011 21:51:12 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Axel.Nennker@telekom.de References: <3D5EC4EE-74DB-47DC-8154-5B5ECA089E5C@gmx.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 27 Apr 2011 12:53:04 -0700 Cc: david@ddahl.com, mhanson@mozilla.com, oauth@ietf.org Subject: Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop aboutOAuth 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, 27 Apr 2011 19:51:11 -0000 Hi Axel et al. Thanx for mentioning my WebPKI.org work :-) I have personally not taken the JS / DOM route because in the case you have a process that needs to be secured beyond a single request/response-pair you tend to run into difficulties combining trusted and untrusted code. I.e. all my current work-items are similar to HTTPS URLs, where the browser transfer the URL to trusted code browser and the rest is performed from there. I must though confess that I haven't done an extensive research if for example end-to-end secured provisioning (which is the by far the most complex project in the collection), actually is feasible by exposing a bunch of JS APIs. I did the *assumption* that it isn't :-| Microsoft will replace their "APIish" CertEnroll scheme something "protocolish" based on WS. In addition to running in trusted layers you also get XML validation. My next step is creating an engine for such schemes so that it becomes easier creating XML browser protocols. However, David Dahl's DomCrypto looks cool so please don't be put-off by my non-JS ideas! Cheers, Anders On 2011-04-27 18:09, Axel.Nennker@telekom.de wrote: > > Hi Hannes, > > A) Authentication Mechanisms > Anders Rundgren is a caller in the desert for this for years: > http://webpki.org/ > B) Authorization Interface > I think this is the point closest to oauth and that needs the most work. > C) Standardized JavaScript Crypto Library Support > This was discussed e.g. in the NSS group for years > https://www.mozilla.org/projects/security/pki/nss/ > If I recollect the most common argument right it was: > "Developers will implement bad security if we give them the basic crypto > building blocks. Combining good crypto A with good crypto B will likely > yield bad crypto C" > D) Moving Crypto Into the Browser > Same comment as for item C. I think your paper should be more specific > to oauth's needs and propose what is needed for oauth and the > (preferrably) ONE way to use the parts. > http://daviddahl.blogspot.com/2011/03/in-which-author-explains-domcrypt- > in.html > > I know of one javascript implementation of signed json web tokens in > Firefox. But I think that crypto in javascript is not secure (enough? > Besides speed). > > -Axel > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >> On Behalf Of Hannes Tschofenig >> Sent: Wednesday, April 27, 2011 5:06 PM >> To: OAuth WG >> Subject: [OAUTH-WG] Paper for the W3C Identity in the Browser >> Workshop aboutOAuth >> >> Hi guys, >> >> Barry, Blaine and I compiled a short position paper for the >> upcoming W3C identity in the browser workshop. >> Here is the call for participation: >> http://www.tschofenig.priv.at/svn/w3c-browser-identity/ >> >> Here is the position paper: >> http://www.tschofenig.priv.at/svn/w3c-browser-identity/oauth.pdf >> >> Let us know if you have some comments. We are happy to >> incorporate them. The submission deadline is unfortunately >> today. This is yet another one of these last minute things, I know. >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From romeda@gmail.com Wed Apr 27 14:37:01 2011 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 ABD84E0848 for ; Wed, 27 Apr 2011 14:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ZdKvhFt8-gY9 for ; Wed, 27 Apr 2011 14:37:01 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D8C3CE081D for ; Wed, 27 Apr 2011 14:37:00 -0700 (PDT) Received: by qwc23 with SMTP id 23so1284895qwc.31 for ; Wed, 27 Apr 2011 14:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=qtpaNkWfFL70cOXrr6m06/K183oM+vqeTttSLZB5vh0=; b=kX8kkQt1mcqccAyKnImIuYuzbMADKJ3aaK8wMn0Mx4jIrGqCMSZD2BJ87ViE6Rp34l KWPlu6WYmr+Jj89UrGqheFW9EQCvtRXkrfaUJDlrpp63z5h+w13GkNcybT/WG5WG2JLm IRiIdr3h6d0EHnXEzWktCF+weTWoebFOc/LHc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=jD80loF2cKjxhHER7b3LDcmkaPMtjamhddcWDLelye0UWSyBIjq4igQwvSJPCcbKsQ 4PfcvjeOhMUz2R1429sXVXr8cujAMsAcsdq+2kh2lfVNRV5Mg8TCgVQY+whWMXLbQEDX PT28+KB/MaG/BCmdDtSRbmoETlwyPoSQhb+UM= Received: by 10.229.43.232 with SMTP id x40mr1821389qce.32.1303940220122; Wed, 27 Apr 2011 14:37:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.11.76 with HTTP; Wed, 27 Apr 2011 14:36:40 -0700 (PDT) From: Blaine Cook Date: Wed, 27 Apr 2011 22:36:40 +0100 Message-ID: To: oauth@ietf.org, oauth-ads@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [OAUTH-WG] Revised Charter 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, 27 Apr 2011 21:37:01 -0000 Hi all, Now that the Easter holiday is over, please review the following revised OAuth charter and provide feedback by May 5th (one week from today). Thanks! Description of Working Group The Open Web Authentication (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account. OAuth consists of * a mechanism for a user to authorize issuance of credentials that a third party can use to access resources on the user's behalf and * a mechanism for using the issued credentials to authenticate HTTP requests. In April 2010 the OAuth 1.0 specifcation, documenting pre-IETF work, was published as an informational document (RFC 5849). The working group has since been developing OAuth 2.0, a standards-track version that will reflect IETF consensus. Version 2.0 will consider the implementation experience with version 1.0, and will * improve the terminology used, * consider broader use cases, * embody good security practices, * improve interoperability, and * provide guidelines for extensibility. The working group will develop authentication schemes for peers/servers taking part in OAuth (accessing protected resources). This includes * an HMAC-based authentication mechanism [to the extent that the OAuth wg produces specifications that could be used more generally for HTTP authentication, the WG will work with the security and applications area directors to ensure that this work gets appropriate review, e.g. via additional last calls in other relevant working groups such as httpbis], * a specification for access protected by Transport Layer Security (bearer tokens), * an extension to OAuth 2.0 to allow access tokens to be requested when a client is in possession of a SAML assertion. A separate informational description will be produced to provide additional security analysis for audiences beyond the community protocol implementers. Milestones will be added for the later items after the near-term work has been completed. Goals and Milestones May 2011 Submit 'HTTP Authentication: MAC Authentication' as a working group item May 2011 Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Jul 2011 Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard Jul 2011 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard Aug 2011 Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Oct 2011 Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0' to the IESG for consideration as a Proposed Standard Nov 2011 Prepare re-chartering From stephen.farrell@cs.tcd.ie Wed Apr 27 15:43:01 2011 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 BA494E078D for ; Wed, 27 Apr 2011 15:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 Ek0-wd6mJ3Gh for ; Wed, 27 Apr 2011 15:43:00 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 60023E0787 for ; Wed, 27 Apr 2011 15:43:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1D825171C1E; Wed, 27 Apr 2011 23:42:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1303944178; bh=pDG11XbMd55DdK AkKr/PbHFb0oyQeHsaWoKFBf3k0lQ=; b=4kgrSrBVIk34j9u2JhQsIwOiNFptWc yxLwpCN7uzEmfLJFDYHIgWbYH5T5z7D8/2+j8Ypp4R6vLBazYpfhth1XXp/+9loi CY5hVm74uMsWQ6x55geA0XJdljv9NYKPrcHKQlpwb/xYhJvpnStmxQTMNcLeBMYT iAWd+AvTPHBI3kueEIWMXR1uvA+WTVxon088/le8ADda6/PDPcyFAttzPkez+BI5 Vr3AeuzI3YC1C36TVEqUuFoSlB2QZPa1qw3wfoL+DViO9bpFaBYxzKPfFgzCNS4c xNo06Shsm7iSTZGRL3KJ9ok7a+WG3S5ggdbdeiYwDZv9TNnRMqYJ7kJQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id LfYPRuJN7unA; Wed, 27 Apr 2011 23:42:58 +0100 (IST) Received: from [10.87.48.3] (unknown [86.41.9.214]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4FA0C171C1D; Wed, 27 Apr 2011 23:42:58 +0100 (IST) Message-ID: <4DB89BF1.2080507@cs.tcd.ie> Date: Wed, 27 Apr 2011 23:42:57 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Blaine Cook References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org, oauth-ads@tools.ietf.org Subject: Re: [OAUTH-WG] Revised Charter 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, 27 Apr 2011 22:43:01 -0000 FWIW, I'd have no problem proposing a re-charter along these lines to the IESG, if that's what the WG want. Thanks to the chairs for putting it together. S. On 27/04/11 22:36, Blaine Cook wrote: > Hi all, > > Now that the Easter holiday is over, please review the following > revised OAuth charter and provide feedback by May 5th (one week from > today). Thanks! > > > Description of Working Group > > The Open Web Authentication (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term > credentials, or even their identity. For example, a photo-sharing > site that supports OAuth could allow its users to use a third-party > printing Web site to print their private pictures, without allowing > the printing site to gain full control of the user's account. > > OAuth consists of * a mechanism for a user to authorize issuance of > credentials that a third party can use to access resources on the > user's behalf and * a mechanism for using the issued credentials to > authenticate HTTP requests. > > In April 2010 the OAuth 1.0 specifcation, documenting pre-IETF work, > was published as an informational document (RFC 5849). The working > group has since been developing OAuth 2.0, a standards-track version > that will reflect IETF consensus. Version 2.0 will consider the > implementation experience with version 1.0, and will * improve the > terminology used, * consider broader use cases, * embody good > security practices, * improve interoperability, and * provide > guidelines for extensibility. > > The working group will develop authentication schemes for > peers/servers taking part in OAuth (accessing protected resources). > This includes > > * an HMAC-based authentication mechanism [to the extent that the > OAuth wg produces specifications that could be used more generally > for HTTP authentication, the WG will work with the security and > applications area directors to ensure that this work gets > appropriate review, e.g. via additional last calls in other relevant > working groups such as httpbis], > > * a specification for access protected by Transport Layer Security > (bearer tokens), > > * an extension to OAuth 2.0 to allow access tokens to be requested > when a client is in possession of a SAML assertion. > > A separate informational description will be produced to provide > additional security analysis for audiences beyond the community > protocol implementers. > > Milestones will be added for the later items after the near-term > work has been completed. > > Goals and Milestones May 2011 Submit 'HTTP Authentication: MAC > Authentication' as a working group item > > May 2011 Submit 'OAuth 2.0 Threat Model and Security > Considerations' as a working group item > > Jul 2011 Submit 'The OAuth 2.0 Authorization Protocol' to the IESG > for consideration as a Proposed Standard > > Jul 2011 Submit 'HTTP Authentication: MAC Authentication' to the > IESG for consideration as a Proposed Standard > > Aug 2011 Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the > IESG for consideration as a Proposed Standard > > Oct 2011 Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for > OAuth 2.0' to the IESG for consideration as a Proposed Standard > > Nov 2011 Prepare re-chartering > _______________________________________________ OAuth mailing list > OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth > e From eran@hueniverse.com Wed Apr 27 18:02:05 2011 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 ED63BE0785 for ; Wed, 27 Apr 2011 18:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY35gC7fFOlv for ; Wed, 27 Apr 2011 18:02:05 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 0C4ABE066F for ; Wed, 27 Apr 2011 18:02:04 -0700 (PDT) Received: (qmail 4859 invoked from network); 28 Apr 2011 01:02:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 Apr 2011 01:02:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 27 Apr 2011 18:01:57 -0700 From: Eran Hammer-Lahav To: Blaine Cook , "oauth@ietf.org" , "oauth-ads@tools.ietf.org" Date: Wed, 27 Apr 2011 18:01:37 -0700 Thread-Topic: [OAUTH-WG] Revised Charter Thread-Index: AcwFI0EvbF1tjsjQQfSjvZPzqK+giwAGkXAQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447537EA69E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Revised Charter 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, 28 Apr 2011 01:02:06 -0000 Thanks for getting this started. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Blaine Cook > Sent: Wednesday, April 27, 2011 2:37 PM > Description of Working Group >=20 > The Open Web Authentication (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected resour= ces, > without necessarily revealing their long-term credentials, or even their > identity. For example, a photo-sharing site that supports OAuth could all= ow > its users to use a third-party printing Web site to print their private p= ictures, > without allowing the printing site to gain full control of the user's acc= ount. Please just call it OAuth and drop the silly 'Open Web Authentication' name= . If you must, replace is with 'Web Authorization Protocol', and in no way = keep the word 'Open'. =20 > OAuth consists of > * a mechanism for a user to authorize issuance of credentials that > a third party can use to access resources on the user's behalf and > * a mechanism for using the issued credentials to authenticate > HTTP requests. >=20 > In April 2010 the OAuth 1.0 specifcation, documenting pre-IETF work, was > published as an informational document (RFC 5849). The working group has > since been developing OAuth 2.0, a standards-track version that will refl= ect > IETF consensus. Version 2.0 will consider the implementation experience > with version 1.0, and will This should include a reference to WRAP given that 2.0 is a direct result o= f the combination of 1.0 and WRAP. I would also like this charter to limit = the scope of the 2.0 protocol to that of the combined 1.0 RFC and WRAP. I'm= pretty sure we're set to deliver exactly that. > * improve the terminology used, > * consider broader use cases, I think we're done considering. Please drop this. > * embody good security practices, > * improve interoperability, and > * provide guidelines for extensibility. >=20 > The working group will develop authentication schemes for peers/servers > taking part in OAuth (accessing protected resources). > This includes >=20 > * an HMAC-based authentication mechanism [to the extent that the OAuth > wg produces specifications that could be used more generally for HTTP > authentication, the WG will work with the security and applications area > directors to ensure that this work gets appropriate review, e.g. via addi= tional > last calls in other relevant working groups such as httpbis], I might have an issue with placing this work primarily within this WG. It b= elongs equally between HTTPbis, HTTP-State, and OAuth. The upcoming revisio= n of this draft moves the OAuth bits into a smaller section, and is mostly = focused on a general purpose MAC authentication scheme. The new draft inclu= des two bindings: HTTP Cookies and OAuth 2.0. So far this WG has proved pretty irrelevant in helping move this work forwa= rd. This is especially true for the audience needed for the new bits. > * a specification for access protected by Transport Layer Security (beare= r > tokens), >=20 > * an extension to OAuth 2.0 to allow access tokens to be > requested when a client is in possession of a SAML assertion. >=20 > A separate informational description will be produced to provide addition= al > security analysis for audiences beyond the community protocol > implementers. >=20 > Milestones will be added for the later items after the near-term work has > been completed. >=20 > Goals and Milestones > May 2011 Submit 'HTTP Authentication: MAC Authentication' as a > working group item See above. > May 2011 Submit 'OAuth 2.0 Threat Model and Security Considerations' > as a working group item >=20 > Jul 2011 Submit 'The OAuth 2.0 Authorization Protocol' to the > IESG for consideration as a Proposed Standard >=20 > Jul 2011 Submit 'HTTP Authentication: MAC Authentication' to the > IESG for consideration as a Proposed Standard >=20 > Aug 2011 Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the > IESG for consideration as a Proposed Standard >=20 > Oct 2011 Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for > OAuth 2.0' to the IESG for consideration as a Proposed Standard >=20 > Nov 2011 Prepare re-chartering I would like this removed. I would like to see this WG closed when this list is complete and if there = is further work with enough interest, a new working group can be created. EHL From hardjono@mit.edu Thu Apr 28 07:20:06 2011 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 6BAD9E06E0 for ; Thu, 28 Apr 2011 07:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 0aTSqEOg2k6k for ; Thu, 28 Apr 2011 07:20:05 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37FE06A6 for ; Thu, 28 Apr 2011 07:20:05 -0700 (PDT) X-AuditID: 12074423-b7b8eae000003d4f-70-4db977995917 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id AD.9D.15695.99779BD4; Thu, 28 Apr 2011 10:20:09 -0400 (EDT) Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p3SEK0UE010876; Thu, 28 Apr 2011 10:20:00 -0400 Received: from w92exedge3.EXCHANGE.MIT.EDU (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id p3SEJx9L020776; Thu, 28 Apr 2011 10:19:59 -0400 Received: from oc11exhub6.exchange.mit.edu (18.9.3.16) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 28 Apr 2011 10:18:50 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub6.exchange.mit.edu ([18.9.3.16]) with mapi; Thu, 28 Apr 2011 10:19:58 -0400 From: Thomas Hardjono To: Blaine Cook , "oauth@ietf.org" , "oauth-ads@tools.ietf.org" Date: Thu, 28 Apr 2011 10:19:56 -0400 Thread-Topic: [OAUTH-WG] Revised Charter Thread-Index: AcwFI0DJFV6aoEaMQ72NfLIkw5oBtgAh/yaQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01Se0gTcRzntztvp3h5rtl+WoKcLHs4KzExSDOREEoSKiJB63K/3Gqb426u rASLohSDlZC4aKZIQQbRVNDZc4WxhdKbWGovEXP5yjDLB93tmvrf58vn9fvy+5KYYi4khtSb LIgzsQaGCMMV8owETd3xjtyN7/1M2rPmLWmekWEirbNnSJ6J5XTY++Q5TU1/ZDm/3kwSeVh+ 2FYtMuitiNuQcShMd/WVgzC7Ek80D7hkFcAfXwVCSUinwJYZB5DwCviy/y5RBcJIBf0QwGuu WlwaHgN4y9uLScNbAHvHxoE0tAE402qXS4MNwB/THwkxjKDXwJ6ZBwFCSZ8H8IXzTaAFo1fD Ft/FEBHjtBrank8F8HI6Ab7u7pSLWCmYnTXVhIST4ciTeVzEFJ0HGyseBHIUdCb87nQHvKH0 djjqGA1gIGzx23tHJnWpoG+gXiZtFwkbr93HgpvOu74Qkj4K9l64+/9tifBG509CwuvhzQY/ JvVGQk/dAG4D0fYlsfYlFvsSi32J5QbAb4NYrfGkxsjqDTwq0vBFrMmEOE1qklFvSULaUicI /Gx2fDuYfcK4AU0CJpz6tqM9VxHCWvkyoxtEkzImihq1dOQqlh0u0ZbpWF53kCs1IN4NIIkx SqqrQOAoLVt2EnElQWoliTMq6np0Qq6CLmYt6BhCZsQF2VUkyUDKZhWMkRwqRieO6A2WRVpG horh4UJ4m6iheDNr5PXFEu8FGnKw0/sIKHBTiQnFqCiHKKJFka7UtJATvNphoBLWWk6Vi6pw 4aYXkoaFEplQ8okLlFjYRSqmAtz7a/N9jnuuqnyZetsf0awezIrv2tWUkj9X2bpnr7p472DL 0/HCydi+6euumq7Nnuqjp98VpX892z2TNdHveThkm0g/cyUk9JLS3Fi/X12bWn7Z8WHtud09 PkecmVdmpe3zJ4/xzgNjUwWFI6dqGmZ3RuRYjdvQvAHVT7+IyV7dy+C8jt20DuN49h9sXRMJ kAMAAA== Subject: Re: [OAUTH-WG] Revised Charter 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, 28 Apr 2011 14:20:06 -0000 Thanks Blaine, This is a good start. I have two suggestions and one request for an additi= onal paragraph/bullet: (a) Openness to future items:=20 I would like to see language that is more open (ready) to accept future ite= ms (ie. those on the horizon and those unforeseen). For example, the Kerberos WG has just completed its re-charter recently and= had to address this same notion of limit/openness to future items. The la= nguage that was finally chosen reflects this openness, I think. Here are t= wo examples: "Prepare and advance one or more standards-track specifications which..= .." (does XYZ). "Prepare, review, and advance standards-track and informational specifi= cations that..." (that does XYZ) (b) Date for re-charter completion: Should you perhaps add a date for the completion of the re-chartering. Say = March 2012 (to coincide with the March IETF). Otherwise re-chartering may d= rag on for sometime -- which is known to happen in the IETF :-) (c) Profiles of OAUTH2.0: I know that some folks want to use OAUTH2.0 as is (just the one spec), but = other folks (including myself) see the need to build additional features on= top the single OAUTH2.0 spec to make OAUTH2.0 work in other scenarios. For= lack of a better term, I use the term "profile" (to mean clearly defined a= dditions and narrowings of aspects listed in the main OAUTH2.0 spec). As such, I would like request the addition of the following paragraph to th= e new charter: Prepare, review, and advance standards-track and informational specif= ications that define profiles of OAUTH2.0 for usage within certain well-def= ined environments. These profiles are adjunct to the OAUTH2.0 specification= , and add optional capabilities to those already defined in the OAUTH2.0 ma= in specification. I will add more comments as we go along. Thanks. /thomas/ __________________________________________ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Blaine Cook > Sent: Wednesday, April 27, 2011 5:37 PM > To: oauth@ietf.org; oauth-ads@tools.ietf.org > Subject: [OAUTH-WG] Revised Charter >=20 > Hi all, >=20 > Now that the Easter holiday is over, please review the following > revised OAuth charter and provide feedback by May 5th (one week from > today). Thanks! >=20 >=20 > Description of Working Group >=20 > The Open Web Authentication (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that supports > OAuth could allow its users to use a third-party printing Web site to > print their private pictures, without allowing the printing site to > gain full control of the user's account. >=20 > OAuth consists of > * a mechanism for a user to authorize issuance of credentials that > a third party can use to access resources on the user's behalf and > * a mechanism for using the issued credentials to authenticate > HTTP requests. >=20 > In April 2010 the OAuth 1.0 specifcation, documenting pre-IETF work, > was published as an informational document (RFC 5849). The working > group has since been developing OAuth 2.0, a standards-track version > that will reflect IETF consensus. Version 2.0 will consider the > implementation experience with version 1.0, and will > * improve the terminology used, > * consider broader use cases, > * embody good security practices, > * improve interoperability, and > * provide guidelines for extensibility. >=20 > The working group will develop authentication schemes for peers/servers > taking part in OAuth (accessing protected resources). > This includes >=20 > * an HMAC-based authentication mechanism [to the extent that the OAuth > wg produces specifications that could be used more generally for HTTP > authentication, the WG will work with the security and applications > area directors to ensure that this work gets appropriate review, e.g. > via additional last calls in other relevant working groups such as > httpbis], >=20 > * a specification for access protected by Transport Layer Security > (bearer tokens), >=20 > * an extension to OAuth 2.0 to allow access tokens to be > requested when a client is in possession of a SAML assertion. >=20 > A separate informational description will be produced to provide > additional security analysis for audiences beyond the community > protocol implementers. >=20 > Milestones will be added for the later items after the near-term work > has been completed. >=20 > Goals and Milestones > May 2011 Submit 'HTTP Authentication: MAC Authentication' as a > working group item >=20 > May 2011 Submit 'OAuth 2.0 Threat Model and Security Considerations' > as a working group item >=20 > Jul 2011 Submit 'The OAuth 2.0 Authorization Protocol' to the > IESG for consideration as a Proposed Standard >=20 > Jul 2011 Submit 'HTTP Authentication: MAC Authentication' to the > IESG for consideration as a Proposed Standard >=20 > Aug 2011 Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the > IESG for consideration as a Proposed Standard >=20 > Oct 2011 Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for > OAuth 2.0' to the IESG for consideration as a Proposed Standard >=20 > Nov 2011 Prepare re-chartering > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Thu Apr 28 09:02:08 2011 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 16B9FE0707 for ; Thu, 28 Apr 2011 09:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, 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 pWZFQexS7Pix for ; Thu, 28 Apr 2011 09:02:07 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id AF09DE06F0 for ; Thu, 28 Apr 2011 09:02:06 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3SG24Eu020062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Apr 2011 11:02:04 -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 p3SG23G8006346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Apr 2011 11:02:04 -0500 Received: from [135.244.35.91] (faynberg.lra.lucent.com [135.244.35.91]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p3SG23p7005292; Thu, 28 Apr 2011 11:02:03 -0500 (CDT) Message-ID: <4DB98F7C.30408@alcatel-lucent.com> Date: Thu, 28 Apr 2011 12:02:04 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Blaine Cook References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: oauth@ietf.org, oauth-ads@tools.ietf.org Subject: Re: [OAUTH-WG] Revised Charter 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, 28 Apr 2011 16:02:08 -0000 Blaine, Looks very good to me. A small editorial suggestion: Rather then say that "OAuth consists of" mechanisms, I would suggest saying "OAuth supports" these mechanisms. I alsonote the omission of the use cases. I suggest adding an item, "Submit OAuth Use Cases." George, Torsten, and Zachary should provide the date they are comfortable with, but from the comments of the two reviewers that I had seen, it appears that the document is pretty much ready. Igor Blaine Cook wrote: > Hi all, > > Now that the Easter holiday is over, please review the following > revised OAuth charter and provide feedback by May 5th (one week from > today). Thanks! > > > Description of Working Group > > The Open Web Authentication (OAuth) protocol allows a user to grant > a third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that supports > OAuth could allow its users to use a third-party printing Web site to > print their private pictures, without allowing the printing site to > gain full control of the user's account. > > OAuth consists of > * a mechanism for a user to authorize issuance of credentials that > a third party can use to access resources on the user's behalf and > * a mechanism for using the issued credentials to authenticate > HTTP requests. > > In April 2010 the OAuth 1.0 specifcation, documenting pre-IETF work, > was published as an informational document (RFC 5849). The working > group has since been developing OAuth 2.0, a standards-track version > that will reflect IETF consensus. Version 2.0 will consider the > implementation experience with version 1.0, and will > * improve the terminology used, > * consider broader use cases, > * embody good security practices, > * improve interoperability, and > * provide guidelines for extensibility. > > The working group will develop authentication schemes for > peers/servers taking part in OAuth (accessing protected resources). > This includes > > * an HMAC-based authentication mechanism [to the extent that the > OAuth wg produces specifications that could be used more generally > for HTTP authentication, the WG will work with the security and > applications area directors to ensure that this work gets appropriate > review, e.g. via additional last calls in other relevant working groups > such as httpbis], > > * a specification for access protected by Transport Layer Security > (bearer tokens), > > * an extension to OAuth 2.0 to allow access tokens to be > requested when a client is in possession of a SAML assertion. > > A separate informational description will be produced to provide > additional security analysis for audiences beyond the community > protocol implementers. > > Milestones will be added for the later items after the near-term work > has been completed. > > Goals and Milestones > May 2011 Submit 'HTTP Authentication: MAC Authentication' as a > working group item > > May 2011 Submit 'OAuth 2.0 Threat Model and Security Considerations' > as a working group item > > Jul 2011 Submit 'The OAuth 2.0 Authorization Protocol' to the > IESG for consideration as a Proposed Standard > > Jul 2011 Submit 'HTTP Authentication: MAC Authentication' to the > IESG for consideration as a Proposed Standard > > Aug 2011 Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the > IESG for consideration as a Proposed Standard > > Oct 2011 Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for > OAuth 2.0' to the IESG for consideration as a Proposed Standard > > Nov 2011 Prepare re-chartering > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Thu Apr 28 09:49:04 2011 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 B76D8E0698 for ; Thu, 28 Apr 2011 09:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBRttuadeWdY for ; Thu, 28 Apr 2011 09:48:58 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id B3552E0670 for ; Thu, 28 Apr 2011 09:48:58 -0700 (PDT) Received: (qmail 28500 invoked from network); 28 Apr 2011 16:48:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Apr 2011 16:48:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 28 Apr 2011 09:48:50 -0700 From: Eran Hammer-Lahav To: Thomas Hardjono , Blaine Cook , "oauth@ietf.org" , "oauth-ads@tools.ietf.org" Date: Thu, 28 Apr 2011 09:48:29 -0700 Thread-Topic: [OAUTH-WG] Revised Charter Thread-Index: AcwFI0DJFV6aoEaMQ72NfLIkw5oBtgAh/yaQAAXjxHA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72344757F91172@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Revised Charter 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, 28 Apr 2011 16:49:04 -0000 -1 on all of these. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Thomas Hardjono > Sent: Thursday, April 28, 2011 7:20 AM > To: Blaine Cook; oauth@ietf.org; oauth-ads@tools.ietf.org > Subject: Re: [OAUTH-WG] Revised Charter >=20 > Thanks Blaine, >=20 > This is a good start. I have two suggestions and one request for an addi= tional > paragraph/bullet: >=20 > (a) Openness to future items: >=20 > I would like to see language that is more open (ready) to accept future i= tems > (ie. those on the horizon and those unforeseen). >=20 > For example, the Kerberos WG has just completed its re-charter recently a= nd > had to address this same notion of limit/openness to future items. The > language that was finally chosen reflects this openness, I think. Here a= re two > examples: >=20 > "Prepare and advance one or more standards-track specifications which= ...." > (does XYZ). >=20 > "Prepare, review, and advance standards-track and informational > specifications that..." (that does XYZ) This defeats the purpose of a charter, which is meant to clearly define wha= t the working group is scoped to do. I would like to see a charter as narro= w as possible to help us focus on getting 2.0 done. >=20 > (b) Date for re-charter completion: >=20 > Should you perhaps add a date for the completion of the re-chartering. Sa= y > March 2012 (to coincide with the March IETF). Otherwise re-chartering may > drag on for sometime -- which is known to happen in the IETF :-) I have serious doubts about the need for this WG to continue. I for one am = going to push for closing this WG as soon as the list of deliverables are c= omplete. If there is new work, it belongs in a new WG. > (c) Profiles of OAUTH2.0: >=20 > I know that some folks want to use OAUTH2.0 as is (just the one spec), bu= t > other folks (including myself) see the need to build additional features = on > top the single OAUTH2.0 spec to make OAUTH2.0 work in other scenarios. > For lack of a better term, I use the term "profile" (to mean clearly defi= ned > additions and narrowings of aspects listed in the main OAUTH2.0 spec). >=20 > As such, I would like request the addition of the following paragraph to = the > new charter: >=20 > Prepare, review, and advance standards-track and informational > specifications that define profiles of OAUTH2.0 for usage within certain = well- > defined environments. These profiles are adjunct to the OAUTH2.0 > specification, and add optional capabilities to those already defined in = the > OAUTH2.0 main specification. This is just a distraction. If you can demonstrate sufficient interest, you= should have no problem creating a new WG at the conclusion of this one, or= just submit and individual submission, which is probably the only practica= l way to go with most of these extensions (given the lack or implementation= experience and small number of people interested in them). EHL From hardjono@mit.edu Thu Apr 28 10:11:36 2011 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 D9EE3E06A6 for ; Thu, 28 Apr 2011 10:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 V1DAy3td94Ny for ; Thu, 28 Apr 2011 10:11:28 -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 90871E0698 for ; Thu, 28 Apr 2011 10:11:28 -0700 (PDT) X-AuditID: 1209190d-b7c48ae000004826-51-4db99f8dfa37 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id B0.74.18470.D8F99BD4; Thu, 28 Apr 2011 13:10:37 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p3SHBQD8028474; Thu, 28 Apr 2011 13:11:26 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id p3SHBJbq023040; Thu, 28 Apr 2011 13:11:25 -0400 Received: from oc11exhub6.exchange.mit.edu (18.9.3.16) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 28 Apr 2011 13:09:38 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub6.exchange.mit.edu ([18.9.3.16]) with mapi; Thu, 28 Apr 2011 13:11:22 -0400 From: Thomas Hardjono To: Eran Hammer-Lahav , Blaine Cook , "oauth@ietf.org" , "oauth-ads@tools.ietf.org" Date: Thu, 28 Apr 2011 13:11:20 -0400 Thread-Topic: [OAUTH-WG] Revised Charter Thread-Index: AcwFI0DJFV6aoEaMQ72NfLIkw5oBtgAh/yaQAAXjxHAAAOGAkA== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72344757F91172@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72344757F91172@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNKsWRmVeSWpSXmKPExsUixG6nots7f6evwbUGG4vTCxczWhxZbWlx 8u0rNovd516wO7B47Jx1l91j+lF/jyVLfjJ5fLn8mS2AJYrLJiU1J7MstUjfLoEr48P+iWwF H+Uqrh1Yy9TAuFqii5GTQ0LAROL8k8msELaYxIV769m6GLk4hAT2MUrs3XWPBcI5wCjxa+MP RgjnOKPE+6bFrBDOVkaJj09PQvVMYJT4snIa2DA2AQ2Jc7/3soMkRAR2Mkp8bXjJBJJgEVCV WHK8iwXEFhZQl7h0djc7iC0C1LBpcg8bhO0k8bRlMVgNr0CAxIL1h6F232CUuPX3FViCUyBa 4u73T2ANjECnfz+1BmwBs4C4xK0n85kgXhKUWDR7DzPMe/92PYSqF5W4076eEaJeR2LBbog5 zALaEssWvmaGWCwocXLmExagp2YhGTsLScssJC2zkLQsYGRZxSibklulm5uYmVOcmqxbnJyY l5dapGukl5tZopeaUrqJERSvnJK8OxjfHVQ6xCjAwajEw/vTbYevEGtiWXFl7iFGSQ4mJVHe trk7fYX4kvJTKjMSizPii0pzUosPMUpwMCuJ8GZOBMrxpiRWVqUW5cOkpDlYlMR5Z0qq+woJ pCeWpGanphakFsFkZTg4lCR4t88DahQsSk1PrUjLzClBSDNxcIIM5wEafhWkhre4IDG3ODMd In+KUZfj2e5T+xmFWPLy81KlxCGKBECKMkrz4ObA0uwrRnGgt4R5b4NU8QBTNNykV0BLmICW 3C8CW1KSiJCSamBc/nCW/AF/l5pvK6J69yvtkua2c7qxoFBlmb3I6oN5xu69pgkxDbaymTxZ 0esC/39ML5N13vL8yo/dW0/fOZBzsEheeHFExO5PrGnVk3RnZkjfC/zluZJ9B8fxGb+6p26Y 3vpsQi9Xe4/ZbBu7p7cuXnn3e9fRrrZijwtJl65MD+J/a/DV6dY3JZbijERDLeai4kQAwYqK 144DAAA= Subject: Re: [OAUTH-WG] Revised Charter 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, 28 Apr 2011 17:11:37 -0000 Folks, Eran, My apologies for jumping ahead to far. I misunderstood Blaine's email. I t= ook the words "Revised Charter" to mean "Re-charter". And usually when a WG says "re-charter", it means a big overhaul (which is = why I mentioned Profiles, etc. etc.). This is not the case here. I believe what we are doing today is a just a ch= arter "clarification", "firm-up" or "clean-up". So please ignore my posting :) Thanks. /thomas/ __________________________________________ > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Thursday, April 28, 2011 12:48 PM > To: Thomas Hardjono; Blaine Cook; oauth@ietf.org; oauth- > ads@tools.ietf.org > Subject: RE: [OAUTH-WG] Revised Charter >=20 > -1 on all of these. >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > > Of Thomas Hardjono > > Sent: Thursday, April 28, 2011 7:20 AM > > To: Blaine Cook; oauth@ietf.org; oauth-ads@tools.ietf.org > > Subject: Re: [OAUTH-WG] Revised Charter > > > > Thanks Blaine, > > > > This is a good start. I have two suggestions and one request for an > > additional > > paragraph/bullet: > > > > (a) Openness to future items: > > > > I would like to see language that is more open (ready) to accept > > future items (ie. those on the horizon and those unforeseen). > > > > For example, the Kerberos WG has just completed its re-charter > > recently and had to address this same notion of limit/openness to > > future items. The language that was finally chosen reflects this > > openness, I think. Here are two > > examples: > > > > "Prepare and advance one or more standards-track specifications > which...." > > (does XYZ). > > > > "Prepare, review, and advance standards-track and informational > > specifications that..." (that does XYZ) >=20 > This defeats the purpose of a charter, which is meant to clearly define > what the working group is scoped to do. I would like to see a charter > as narrow as possible to help us focus on getting 2.0 done. >=20 > > > > (b) Date for re-charter completion: > > > > Should you perhaps add a date for the completion of the re- > chartering. > > Say March 2012 (to coincide with the March IETF). Otherwise > > re-chartering may drag on for sometime -- which is known to happen in > > the IETF :-) >=20 > I have serious doubts about the need for this WG to continue. I for one > am going to push for closing this WG as soon as the list of > deliverables are complete. If there is new work, it belongs in a new > WG. >=20 > > (c) Profiles of OAUTH2.0: > > > > I know that some folks want to use OAUTH2.0 as is (just the one > spec), > > but other folks (including myself) see the need to build additional > > features on top the single OAUTH2.0 spec to make OAUTH2.0 work in > other scenarios. > > For lack of a better term, I use the term "profile" (to mean clearly > > defined additions and narrowings of aspects listed in the main > OAUTH2.0 spec). > > > > As such, I would like request the addition of the following paragraph > > to the new charter: > > > > Prepare, review, and advance standards-track and informational > > specifications that define profiles of OAUTH2.0 for usage within > > certain well- defined environments. These profiles are adjunct to the > > OAUTH2.0 specification, and add optional capabilities to those > already > > defined in the > > OAUTH2.0 main specification. >=20 > This is just a distraction. If you can demonstrate sufficient interest, > you should have no problem creating a new WG at the conclusion of this > one, or just submit and individual submission, which is probably the > only practical way to go with most of these extensions (given the lack > or implementation experience and small number of people interested in > them). >=20 >=20 > EHL From recordond@gmail.com Thu Apr 28 12:22:27 2011 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 CA162E06C3 for ; Thu, 28 Apr 2011 12:22:27 -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 2qN37Hp8kawK for ; Thu, 28 Apr 2011 12:22:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58A8BE0670 for ; Thu, 28 Apr 2011 12:22:26 -0700 (PDT) Received: by wwa36 with SMTP id 36so2371794wwa.13 for ; Thu, 28 Apr 2011 12:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sV400rj8qngSd00BEzap10OOXvbcNxpAPYzFU/gq3zk=; b=Rd01LVYH6luHB4AW/dUuG1bpPGBd4jlKTgoAcRTYoOqHjXH7d5HtwfihVrDW3/zrJL 4ODW0fjnRULmGYkPi4j4GwLA8gpXMbmARySHx4VmK5V0wOR4KTiUNw0+5Wp2vrjQlhJm xQRiIflIh59kKAGkwFSDZ1kYtv8jHblcwUUM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dmdA8K0QcRFa8Jkrh09BL/dwoXMzQ3dhgNHrO5i4UhAUJTZe1xKQhZSt3nPIJdkywB 7OUZpnnHTZGDnCvi7X1f+U1QyaVso8zV/B8WIat6mtQHcWWVvSRGqj8RG4/V+WEiJPF0 s9pPXBdRg+DQXczYOnOZK0cubzVFfIfhxURIE= MIME-Version: 1.0 Received: by 10.217.6.202 with SMTP id y52mr7995759wes.42.1304018545300; Thu, 28 Apr 2011 12:22:25 -0700 (PDT) Received: by 10.216.20.202 with HTTP; Thu, 28 Apr 2011 12:22:25 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72344757F91172@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 28 Apr 2011 12:22:25 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav , Blaine Cook Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" , "oauth-ads@tools.ietf.org" Subject: Re: [OAUTH-WG] Revised Charter 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, 28 Apr 2011 19:22:27 -0000 I agree with Eran as well that the focus should be on finalizing 2.0 and then future work can occur in new working groups. We're so close! I keep telling people throughout the industry that the spec hasn't changed technically in months but they keep asking when it's going to be a final RFC. On Thu, Apr 28, 2011 at 10:11 AM, Thomas Hardjono wrote: > Folks, Eran, > > My apologies for jumping ahead to far. =A0I misunderstood Blaine's email.= I took the words "Revised Charter" to mean "Re-charter". > > And usually when a WG says "re-charter", it means a big overhaul (which i= s why I mentioned Profiles, etc. etc.). > > This is not the case here. I believe what we are doing today is a just a = charter "clarification", "firm-up" or "clean-up". > > So please ignore my posting :) > > Thanks. > > /thomas/ > > > __________________________________________ > >> -----Original Message----- >> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] >> Sent: Thursday, April 28, 2011 12:48 PM >> To: Thomas Hardjono; Blaine Cook; oauth@ietf.org; oauth- >> ads@tools.ietf.org >> Subject: RE: [OAUTH-WG] Revised Charter >> >> -1 on all of these. >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> Behalf >> > Of Thomas Hardjono >> > Sent: Thursday, April 28, 2011 7:20 AM >> > To: Blaine Cook; oauth@ietf.org; oauth-ads@tools.ietf.org >> > Subject: Re: [OAUTH-WG] Revised Charter >> > >> > Thanks Blaine, >> > >> > This is a good start. =A0I have two suggestions and one request for an >> > additional >> > paragraph/bullet: >> > >> > (a) Openness to future items: >> > >> > I would like to see language that is more open (ready) to accept >> > future items (ie. those on the horizon and those unforeseen). >> > >> > For example, the Kerberos WG has just completed its re-charter >> > recently and had to address this same notion of limit/openness to >> > future items. =A0The language that was finally chosen reflects this >> > openness, I think. =A0Here are two >> > examples: >> > >> > =A0 =A0 "Prepare and advance one or more standards-track specification= s >> which...." >> > (does XYZ). >> > >> > =A0 =A0 "Prepare, review, and advance standards-track and informationa= l >> > specifications that..." (that does XYZ) >> >> This defeats the purpose of a charter, which is meant to clearly define >> what the working group is scoped to do. I would like to see a charter >> as narrow as possible to help us focus on getting 2.0 done. >> >> > >> > (b) Date for re-charter completion: >> > >> > Should you perhaps add a date for the completion of the re- >> chartering. >> > Say March 2012 (to coincide with the March IETF). Otherwise >> > re-chartering may drag on for sometime -- which is known to happen in >> > the IETF :-) >> >> I have serious doubts about the need for this WG to continue. I for one >> am going to push for closing this WG as soon as the list of >> deliverables are complete. If there is new work, it belongs in a new >> WG. >> >> > (c) Profiles of OAUTH2.0: >> > >> > I know that some folks want to use OAUTH2.0 as is (just the one >> spec), >> > but other folks (including myself) see the need to build additional >> > features on top the single OAUTH2.0 spec to make OAUTH2.0 work in >> other scenarios. >> > For lack of a better term, I use the term "profile" (to mean clearly >> > defined additions and narrowings of aspects listed in the main >> OAUTH2.0 spec). >> > >> > As such, I would like request the addition of the following paragraph >> > to the new charter: >> > >> > =A0 =A0 =A0 Prepare, review, and advance standards-track and informati= onal >> > specifications that define profiles of OAUTH2.0 for usage within >> > certain well- defined environments. These profiles are adjunct to the >> > OAUTH2.0 specification, and add optional capabilities to those >> already >> > defined in the >> > OAUTH2.0 main specification. >> >> This is just a distraction. If you can demonstrate sufficient interest, >> you should have no problem creating a new WG at the conclusion of this >> one, or just submit and individual submission, which is probably the >> only practical way to go with most of these extensions (given the lack >> or implementation experience and small number of people interested in >> them). >> >> >> EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From dick.hardt@gmail.com Thu Apr 28 12:36:32 2011 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 5AD1CE06C3 for ; Thu, 28 Apr 2011 12:36:32 -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 e0-a9Ufx6ESS for ; Thu, 28 Apr 2011 12:36:31 -0700 (PDT) Received: from mail-px0-f170.google.com (mail-px0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 88801E0669 for ; Thu, 28 Apr 2011 12:36:31 -0700 (PDT) Received: by pxi19 with SMTP id 19so336125pxi.15 for ; Thu, 28 Apr 2011 12:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=IUdMg9fN1Qo+7pbq9F/m/tjXqH1ySNe+Y37v32Bk48U=; b=aNX/AnY3I5fsFhjha8d9r1EkY5vdl0Vp0K+Lv1P25xjRqR7m3MmlVJ3pLKAg+GhtjJ 5wvBPkcNVPVbrm2BUM0+VljGw5B14aDBUbf7R7fH4qGK0eAxGDueIW6n8uqDIHPZer6D FA2V0DVAsVOfv2wE222kQU5WPjNlshLPWJ90Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Hig5JalK0Ch9j80/dkMnbtUZ5WMcllmrMo/tGHcLkIY/6gbPUCXJ0QW4qKaTVY8b2s Wv8Ysrks2ObY3+TD0IcUg0uR5d0AQdxW1kfwfJcD6qW/t+PJy60F1YC6wlS+geGQIIf2 9mM/ZDZ1fb3v93i4G1U/MEo8JKg0Ji//5b3dY= Received: by 10.142.229.20 with SMTP id b20mr1293486wfh.198.1304019391310; Thu, 28 Apr 2011 12:36:31 -0700 (PDT) Received: from [192.168.1.16] (c-24-5-83-209.hsd1.ca.comcast.net [24.5.83.209]) by mx.google.com with ESMTPS id r3sm1392670pbp.78.2011.04.28.12.36.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2011 12:36:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Thu, 28 Apr 2011 12:36:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E72344757F91172@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: David Recordon X-Mailer: Apple Mail (2.1084) Cc: "oauth@ietf.org" , "oauth-ads@tools.ietf.org" Subject: Re: [OAUTH-WG] Revised Charter 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, 28 Apr 2011 19:36:32 -0000 +1 to Eran and David's comments. Let's not get distracted when we are = close to finalizing. I suggest revising the charter once we are done = with 2.0 unless there is a process reason for revising the charter to = complete 2.0. -- Dick On 2011-04-28, at 12:22 PM, David Recordon wrote: > I agree with Eran as well that the focus should be on finalizing 2.0 > and then future work can occur in new working groups. We're so close! > I keep telling people throughout the industry that the spec hasn't > changed technically in months but they keep asking when it's going to > be a final RFC. >=20 >=20 > On Thu, Apr 28, 2011 at 10:11 AM, Thomas Hardjono = wrote: >> Folks, Eran, >>=20 >> My apologies for jumping ahead to far. I misunderstood Blaine's = email. I took the words "Revised Charter" to mean "Re-charter". >>=20 >> And usually when a WG says "re-charter", it means a big overhaul = (which is why I mentioned Profiles, etc. etc.). >>=20 >> This is not the case here. I believe what we are doing today is a = just a charter "clarification", "firm-up" or "clean-up". >>=20 >> So please ignore my posting :) >>=20 >> Thanks. >>=20 >> /thomas/ >>=20 >>=20 >> __________________________________________ >>=20 >>> -----Original Message----- >>> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] >>> Sent: Thursday, April 28, 2011 12:48 PM >>> To: Thomas Hardjono; Blaine Cook; oauth@ietf.org; oauth- >>> ads@tools.ietf.org >>> Subject: RE: [OAUTH-WG] Revised Charter >>>=20 >>> -1 on all of these. >>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>> Behalf >>>> Of Thomas Hardjono >>>> Sent: Thursday, April 28, 2011 7:20 AM >>>> To: Blaine Cook; oauth@ietf.org; oauth-ads@tools.ietf.org >>>> Subject: Re: [OAUTH-WG] Revised Charter >>>>=20 >>>> Thanks Blaine, >>>>=20 >>>> This is a good start. I have two suggestions and one request for = an >>>> additional >>>> paragraph/bullet: >>>>=20 >>>> (a) Openness to future items: >>>>=20 >>>> I would like to see language that is more open (ready) to accept >>>> future items (ie. those on the horizon and those unforeseen). >>>>=20 >>>> For example, the Kerberos WG has just completed its re-charter >>>> recently and had to address this same notion of limit/openness to >>>> future items. The language that was finally chosen reflects this >>>> openness, I think. Here are two >>>> examples: >>>>=20 >>>> "Prepare and advance one or more standards-track specifications >>> which...." >>>> (does XYZ). >>>>=20 >>>> "Prepare, review, and advance standards-track and informational >>>> specifications that..." (that does XYZ) >>>=20 >>> This defeats the purpose of a charter, which is meant to clearly = define >>> what the working group is scoped to do. I would like to see a = charter >>> as narrow as possible to help us focus on getting 2.0 done. >>>=20 >>>>=20 >>>> (b) Date for re-charter completion: >>>>=20 >>>> Should you perhaps add a date for the completion of the re- >>> chartering. >>>> Say March 2012 (to coincide with the March IETF). Otherwise >>>> re-chartering may drag on for sometime -- which is known to happen = in >>>> the IETF :-) >>>=20 >>> I have serious doubts about the need for this WG to continue. I for = one >>> am going to push for closing this WG as soon as the list of >>> deliverables are complete. If there is new work, it belongs in a new >>> WG. >>>=20 >>>> (c) Profiles of OAUTH2.0: >>>>=20 >>>> I know that some folks want to use OAUTH2.0 as is (just the one >>> spec), >>>> but other folks (including myself) see the need to build additional >>>> features on top the single OAUTH2.0 spec to make OAUTH2.0 work in >>> other scenarios. >>>> For lack of a better term, I use the term "profile" (to mean = clearly >>>> defined additions and narrowings of aspects listed in the main >>> OAUTH2.0 spec). >>>>=20 >>>> As such, I would like request the addition of the following = paragraph >>>> to the new charter: >>>>=20 >>>> Prepare, review, and advance standards-track and = informational >>>> specifications that define profiles of OAUTH2.0 for usage within >>>> certain well- defined environments. These profiles are adjunct to = the >>>> OAUTH2.0 specification, and add optional capabilities to those >>> already >>>> defined in the >>>> OAUTH2.0 main specification. >>>=20 >>> This is just a distraction. If you can demonstrate sufficient = interest, >>> you should have no problem creating a new WG at the conclusion of = this >>> one, or just submit and individual submission, which is probably the >>> only practical way to go with most of these extensions (given the = lack >>> or implementation experience and small number of people interested = in >>> them). >>>=20 >>>=20 >>> EHL >>=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 barryleiba.mailing.lists@gmail.com Fri Apr 29 11:05:06 2011 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 BC659E06C0 for ; Fri, 29 Apr 2011 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.254 X-Spam-Level: X-Spam-Status: No, score=-103.254 tagged_above=-999 required=5 tests=[AWL=-0.277, 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 9uLEdQSxtm3L for ; Fri, 29 Apr 2011 11:05:06 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09DC5E069F for ; Fri, 29 Apr 2011 11:05:05 -0700 (PDT) Received: by gwb20 with SMTP id 20so1705301gwb.31 for ; Fri, 29 Apr 2011 11:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=PB2rib1y8gxhbOSu65BbvpzpwgyDDFpb/D5U8agMEag=; b=tvgen8DsRodXf7O7Gtb2eyvfIhXSRKWu0cw6sUXAhTArjcgcVD9RAxZbTBgOYn/wfM E06N+CSuX0k+Opyd6Gkd7Kgo5wAekRUPNNnuXAAgfyHXJ9XXIA28Gd4b/HGZQ8vt2q4O QIcQZKebwYoR9bWWaEn4qqvsp7nisyzfVAhds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=MypLJ9MJlBjHsirul1GbntkslxmLyjwPGJ0zcbpOPfBWehEqF/iaGCeW1jm3baSnXY ZJYrNylvQ1Fe2vMqN2rpxQQEVhQlz5mpggEtrf4iMXPi7pvpXTUMgP8G1X7SRTnbECk6 jK9ssjjFrP2jYmR+IN8BJqV3E/T9VdY1dbjPU= MIME-Version: 1.0 Received: by 10.236.182.229 with SMTP id o65mr634107yhm.216.1304100305343; Fri, 29 Apr 2011 11:05:05 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Fri, 29 Apr 2011 11:05:05 -0700 (PDT) Date: Fri, 29 Apr 2011 14:05:05 -0400 X-Google-Sender-Auth: yKTzdBnp1GPh0Tu0ic80cmJSEDM Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Closing a few issues 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, 29 Apr 2011 18:05:06 -0000 There are three issues in the tracker that are just looking for consensus on text that's in the document -- Eran had flagged them as "pending consensus" in the -15 version. Let's look at closing those issues now. The issues are #8 4.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code http://trac.tools.ietf.org/wg/oauth/trac/ticket/8 #9 5.2, text for non-400 & 401 error conditions http://trac.tools.ietf.org/wg/oauth/trac/ticket/9 #10 8.4. Defining Additional Error Codes http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 I think these are non-controversial. I'm aware of some conversation about perhaps tweaking the text to make sure it's clear what layer the status codes go into (for the redirects, it should be clear, but a slight text change might help). Everyone, please review these. They are short, and should be easy to confirm consensus on. Please post any objection you have to closing these issues. If you do have an objection, it would help if you could post alternative text that you'd be happy with. Please post also if you think they're OK and ready to close. I will close these issues next Friday, 6 May, if there are no unresolved objections. Barry, as chair From d.tangren@gmail.com Fri Apr 29 11:21:44 2011 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 2B35EE067F for ; Fri, 29 Apr 2011 11:21:44 -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=[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 nhyH-hdQCUd7 for ; Fri, 29 Apr 2011 11:21:42 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5C0E0675 for ; Fri, 29 Apr 2011 11:21:42 -0700 (PDT) Received: by gwb20 with SMTP id 20so1711672gwb.31 for ; Fri, 29 Apr 2011 11:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=Cyz0IAEdLn5B9+jwveVz8PjP2nvt5Uo0XDhqrkPdtw4=; b=IWafdSe+YsCG3CoetfT+Xp5zXCayQDaCRNfQdpdx1ifXbQ/S0z7xujb20oJKn4WqOV xfFMBiuJ0PuOyTqFZA4p6rmNi/f8KsKYXG2qV816KMeUYkXYpxa8aGwP3UgIIg7u4F0C buSVuu9PzHM4hjku6jSeGqvi99I1V5IM3tCqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=WNJYsm0BxDwhg973wmi6OX3kGqaNsp7plwIHChpd+qpptnBiF3JfLyOtuYskJ4Z9OB g6bv3qEdqTaXfoZQKXlIXnuzOfGQWzGo0awf+lc1R/73alyk6wJZfbTX6/l4Qs4tcH1l q5I2Nv3hou7SBX0ThAHfl/ut4jW4y4B1jLDSg= Received: by 10.91.4.19 with SMTP id g19mr4498094agi.193.1304101300159; Fri, 29 Apr 2011 11:21:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.57.33 with HTTP; Fri, 29 Apr 2011 11:21:20 -0700 (PDT) From: Doug Tangren Date: Fri, 29 Apr 2011 14:21:20 -0400 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=0016363b880ebf468804a212be8c Subject: [OAUTH-WG] requirement of redirect_uri in access token requests 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, 29 Apr 2011 18:21:44 -0000 --0016363b880ebf468804a212be8c Content-Type: text/plain; charset=UTF-8 Is this required or not? In the example http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-3.1 it's listed in the example but not itemized as optional or required. It's not in the example for refreshing tokens http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-6 though that section links back to section 3.1 which does use a redirect_uri in the example. Should the redirect_uri be a requirement for client authentication or is it optional? -Doug Tangren http://lessis.me --0016363b880ebf468804a212be8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is this required or not? In the example http://tools.ietf.org/html/draft-iet= f-oauth-v2-15#section-3.1 it's listed in the example but not itemiz= ed as optional or required. It's not in the example for refreshing toke= ns = http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-6 though that= section links back to section 3.1 which does use a redirect_uri in the exa= mple.

Should the redirect_uri be a requirement for client authentication or i= s it optional?

-Doug Tangren
http://lessis.me
--0016363b880ebf468804a212be8c-- From mscurtescu@google.com Fri Apr 29 15:03:25 2011 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 0BF07E072D for ; Fri, 29 Apr 2011 15:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIZJ76T0+SCp for ; Fri, 29 Apr 2011 15:03:24 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id AED1CE0670 for ; Fri, 29 Apr 2011 15:03:23 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p3TM3MXs031614 for ; Fri, 29 Apr 2011 15:03:22 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304114602; bh=EjRedDhKds/H1ZHNoucScJf37zU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ZGeHnTs5nHoyIgxyHTgFarfi8ndQKDiJRsnQTz6cRhGIVM43dSKdF3JGUlnsN2Hn/ kNJ+/9NBH9zyXXrW7U5Uw== Received: from yib2 (yib2.prod.google.com [10.243.65.66]) by kpbe19.cbf.corp.google.com with ESMTP id p3TM3KNq003245 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 29 Apr 2011 15:03:20 -0700 Received: by yib2 with SMTP id 2so1458527yib.10 for ; Fri, 29 Apr 2011 15:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=3bH/68paGepJZAw6yHs2vyR23oQZ1OJpvEPB0vnsMCI=; b=yhC0TX6BimEy5fT6l5i/Tzg/65Sgi9YagGRisMVFVKPbsO2oSVZI/Nq0eO31COIQEs 4NBPXQG4E0Qc1NBTTz7Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=mXydOyb23YpHjg0JWxtjETAs6DbJ942tIkyuX2je0kdjq+/bvXwp6FQAlidX7Rcod/ EuFschgGDBdfClrMj2nw== Received: by 10.91.199.3 with SMTP id b3mr4629714agq.168.1304114600290; Fri, 29 Apr 2011 15:03:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.9 with HTTP; Fri, 29 Apr 2011 15:03:00 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Fri, 29 Apr 2011 15:03:00 -0700 Message-ID: To: Andrew Arnott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] client authentication for implicit grant type 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, 29 Apr 2011 22:03:25 -0000 On Tue, Apr 12, 2011 at 7:27 AM, Andrew Arnott wro= te: > I brought this concern up about a year ago. =A0Now reviewing the latest > drafts, I still have a concern with it. =A0It is regarding the use of > client_id without a password. =A0I agree with section 3, as included belo= w: > Section=A03. Client Authentication > >> The client identifier is not a secret, it is exposed to the resource >> owner, and MUST NOT be used alone for client authentication. Client >> authentication is accomplished via additional means such as a >> matching client password. > > The above tells me (rightly so IMO) that considering the client_id alone > (without real authentication) is dangerous. =A0Yet the Implicit Grant typ= e > accepts a client_id, but no authentication: > Section 4.2 Implicit Grant >> >> client_id >> >> REQUIRED. The client identifier as described in Section 3. > > Now here me: I am not=A0advocating for a client_secret in this case. =A0I= fully > understand that some clients, particularly javascript widget clients that > are embedded in others' web pages, can't keep secrets. =A0What I am advoc= ating > is that =A0clients that can't keep secrets shouldn't have IDs either. =A0= This is > a wide-open door for clients to obtain access to protected user data by > lying about their identity to authorization servers. =A0They can achieve = this > in either of two ways, given some popular client_id we'll arbitrarily cal= l > 'facebook' that users are accustomed to authorizing access to: > > 1. An evil client can redirect the user to the authorization endpoint, > requesting an implicit grant, and including client_id=3Dfacebook in the U= RL. > =A0The authorization server may ask the user "Do you want to give Faceboo= k > access?" along with (perhaps) a warning that most users won't know what t= o > do about (honestly, most technical users wouldn't know how to verify eith= er. > =A0The user, who trusts Facebook, will click Accept, and offer whatever r= ogue > client was running on the page they were visiting the access that they > requested. > 2. In scenario 2, which is far worse,=A0an evil client can redirect the u= ser to > the authorization endpoint, requesting an implicit grant, and including > client_id=3Dfacebook in the URL. =A0Same so far, but in this case, the > authorization server sees that access has already been authorized by the > resource owner to this client in the past and immediately redirects back > with the requested access token, no user involvement whatsoever. =A0Again= , the > client obtains access. Maybe this is obvious, but none of these scenarios are that easy to exploit in practice. If evil client presents "facebook" as a client ID then it can only use a redirect URI that matches the one registered by the real Facebook. Unless an open redirector on Facebook can be exploited (if matching rules are too lax), evil client cannot grab the response. Marius From zachary.zeltsan@alcatel-lucent.com Fri Apr 29 15:09:12 2011 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 D1C7BE0746 for ; Fri, 29 Apr 2011 15:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 ODfLP3TFMPZX for ; Fri, 29 Apr 2011 15:09:11 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9E110E0742 for ; Fri, 29 Apr 2011 15:09:11 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3TM976j006918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Apr 2011 17:09:08 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3TM97XY025567 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Apr 2011 17:09:07 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 29 Apr 2011 17:09:07 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Melinda Shore'" , "oauth@ietf.org" Date: Fri, 29 Apr 2011 17:09:07 -0500 Thread-Topic: [OAUTH-WG] Use cases document review Thread-Index: Acv+6aNPi6fwnJzETYiioX/74mwdMgHru/Kg Message-ID: <5710F82C0E73B04FA559560098BF95B12507584ECC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B12507584ECCUSNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [OAUTH-WG] Use cases document review 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, 29 Apr 2011 22:09:13 -0000 --_000_5710F82C0E73B04FA559560098BF95B12507584ECCUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Melinda, My comments are inline. With thanks, Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= elinda Shore Sent: Tuesday, April 19, 2011 7:29 PM To: oauth@ietf.org Subject: [OAUTH-WG] Use cases document review At the oauth session at IETF 80, I volunteered to review the use cases docu= ment (draft-zeltsan-oauth-use-cases). Overall I liked the document a lot and thought the structure (pre- conditio= ns, post-conditions, requirements) was excellent. I do wonder if the post-conditions aren't somewhat overly focused on proces= s rather than state in many cases ("Alice's browser downloads a script [ ..= . ]"), [z.z] I understand your observation regarding the post-conditions. In all u= se cases (if everything went right) a client receives an access token at th= e end. The intention was to provide in post-conditions the additional use-c= ase-specific details. ...but that may be a terminological question around "post-conditions" rathe= r than much to do with actual content. [z.z] I agree. I also think that it may help to identify which requirements are in-scope f= or the working group and which are not. For example, in 3.11 "The server a= t www.social.example.com must be able to redirect Alice's browser to www.si= pservice.example.com" is clearly out-of-scope for oauth, but "The application running at www.sipservice.example.com must be capable = of authenticating Alice and obtaining her authorization of a request from w= ww.social.example.com" is not, or at least both the authn and authz steps may not be, and that wou= ld benefit from clarification. [z.z] www.social.example.com plays a role of OAuth client implemented on a= web server in this use case. If such a client cannot redirect the user's b= rowser, it cannot participate in the OAuth procedure as intended in this us= e case. The requirement is necessary for the described case. And come to think of it, that's a pretty good example of a case where the d= istinction between "pre-condition" and requirement isn't all that clear. [z.z] I agree that this particular requirement could be re-formulated as a = pre-condition (e.g., "The server at www.social.example.com is able to redir= ect Alice's browser to www.sipservice.example.com " ). But, I think, that the requirement is more relevant to the p= rocess than to the situation existed before the start of the process. I am open to the proposals for clarification. Individual sections: 3.1 I thought the discussion of token lifetime was a bit muddled. I think it's probably sufficient to say that expired tokens may be reissued= and that it is possible, when appropriate, to issue relatively long-lived = tokens. [z.z] The word "reissued" could be misunderstood. After an access token exp= ired it is not reissued. A new token can be obtained as a result of a (repe= ated) OAuth procedure. Also, it was important to emphasize that a long-lived token (i.e., refresh = token) is not used for access to the user resource, but for exchange for a = new access token. 3.2 I didn't understand the second bullet item under "pre-conditions." I tried substituting both "not" and "now" for "no" and neither of them work= ed all that well. [z.z] This item is intended to provide justification for the use case: the = gaming application itself has to update information on the user's social si= te, because there is no a web server that supports this application, suppor= ts oauth, and so, it can make the update. Would the following modification clarify? "There is no a web site supporting this application and capable of handling= the OAuth flow "--> "The gaming application does not have a supporting web= site that is capable of accessing Alice's database at www.fun.example.com<= http://www.fun.example.com>" 3.11 I think "The application at www.social.example.com must be able to tra= nslate the messages of the Alice's VoIP applet into SIP and RTP messages" i= s almost certainly irrelevant. [z.z] I agree that it is not relevant to OAuth, but the requirement is nece= ssary for the use case. 3.12 I'm insufficiently familiar with XRD to know if it protects private pa= tient data sufficiently to satisfy HIPPA and other legal requirements. The discovery component of this seems dicey and can probably be addressed i= n a less touchy scenario. [z.z] XRD (mentioned as an example) is a mechanism used for discovering Ali= ce's personal health data store. It does not handle the user data stored at= ww.pcp.example.com . Perhaps George, who has c= ontributed this use case, may have additional comments. If this document is to provide guidance during the development of protocol = documents, I'm not sure it's worth the effort to sort out pre- conditions a= nd requirements, although I do think I'd try to put some effort into identi= fying what's going to be done by the working group and what's not. [z.z] The draft documents the use cases that have been discussed on the lis= t (at least some of them). I believe it helps to understand the specificati= on. The requirements, in my opinion, are useful for determining whether a u= se case is supported. Overall I think it's an extremely useful document. Melinda _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_5710F82C0E73B04FA559560098BF95B12507584ECCUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melinda,

My comments are inline.

With thanks,

Zachary
-----Original Message-----
From: oauth-bounces@ietf.= org=20 [mailto:oauth-bounces@ietf.org] On Behalf= Of=20 Melinda Shore
Sent: Tuesday, April 19, 2011 7:29 PM
To:=20 oauth@ietf.org
Subject: [OAUTH-WG] Use cases document review

At t= he=20 oauth session at IETF 80, I volunteered to review the use cases document=20 (draft-zeltsan-oauth-use-cases).

Overall I liked the document a lot = and=20 thought the structure (pre- conditions, post-conditions, requirements) was= =20 excellent. 
 
I do wonder if the post-conditions aren't somewhat over= ly=20 focused on process rather than state in many cases ("Alice's browser downlo= ads a=20 script [ ... ]"),
[z.z] I understand y= our=20 observation regarding the post-conditions. In all use cases (if everything = went=20 right) a client receives an access token at the end. The intention was to=20 provide in post-conditions the additional use-case-specific=20 details.
 
...but that may be a terminological question around=20 "post-conditions" rather than much to do with actual content.
[z.= z] I=20 agree.
 
<= /FONT>
I also think that it may help to identify which require= ments=20 are in-scope for the working group and which are not.  For example, in= 3.11=20 "The server at www.social.example.com must be able to redirect Alice's brow= ser=20 to www.sipservice.example.com" is clearly out-of-scope for oauth,
but "The application running at www.sipservice.example.= com=20 must be capable of authenticating Alice and obtaining her authorization of = a=20 request from www.social.example.com"
is not, or at least both the authn = and=20 authz steps may not be, and that would benefit from clarification. =20
[z.z] =20 www.social.example.com plays a role of OAuth client implemented on a web se= rver=20 in this use case. If such a client cannot redirect the user's browser, it c= annot=20 participate in the OAuth procedure as intended in this use case. The=20 requirement is necessary for the described case.=20
And come to think of it, that's a pretty good example o= f a=20 case where the distinction between "pre-condition" and requirement isn't al= l=20 that clear.
[z.z] I agree t= hat=20 this particular requirement could be re-formulated as a pre-condition= =20 (e.g., "The server a= t=20 www.social.example.com is able to redirect Alice's browser to <= A=20 href=3D"http://www.sipservice.example.com">www.sipservice.example.com " ). But, I think, that the requirement = is more=20 relevant to the process than to the situation existed before=20 the start of the proc= ess.=20
I am open to the pro= posals for=20 clarification.
Individual sections:

3.1  I thoug= ht the=20 discussion of token lifetime was a bit muddled.
I think it's probably=20 sufficient to say that expired tokens may be reissued and that it is possib= le,=20 when appropriate, to issue relatively long-lived tokens.
[z.z] The word=20 "reissued" could be misunderstood. After an access token expired it is= not=20 reissued. A new token can be obtained as a result of a (repeated) OAut= h=20 procedure.
Also, it was importa= nt to=20 emphasize that a long-lived token (i.e., refresh token) is not used for acc= ess=20 to the user resource, but for exchange for a new access token.=20

3.2  I didn't understand the second bullet item under=20 "pre-conditions."
I tried substituting both "not" and "now" for "no" and= =20 neither of them worked all that well.
[z.z] This item is=20 intended to provide justification for the use case: the gaming applica= tion=20 itself has to update information on the user's social site, because there i= s no=20 a web server that supports this application, supports oauth, and so, it can= make=20 the update.
Would the following modifi= cation=20 clarify?
"There is = no a web site=20 supporting this application and capable of handling the OAuth flow "-->= =20 "The gaming application does not have a supporting web site that is=20 capable of accessing Alice's database at www.fun.example.com" 
 
3.11 I think "The application at www.social.example.com= must=20 be able to translate the messages of the Alice's VoIP applet into SIP and R= TP=20 messages" is almost certainly irrelevant.
[z.z] I agree that i= t is not=20 relevant to OAuth, but the requirement is necessary for the use=20 case.

3.12 I'm insufficiently familiar with XRD to know if it= =20 protects private patient data sufficiently to satisfy HIPPA and other legal= =20 requirements.
The discovery component of this seems dicey and can probab= ly be=20 addressed in a less touchy scenario.
[z.z] XRD (mentioned= as an=20 example) is a mechanism used for discovering Alice's personal health data store. It does not handle the user data stor= ed at=20 ww.pcp.example.com . Pe= rhaps=20 George, who has contributed this use case, may have additional=20 comments.
 
If this document is to provide guidance during the deve= lopment=20 of protocol documents, I'm not sure it's worth the effort to sort out pre-= =20 conditions and requirements, although I do think I'd try to put some effort= into=20 identifying what's going to be done by the working group and what's=20 not.
 
[z.z] The draft docu= ments the=20 use cases that have been discussed on the list (at least some of them). I=20 believe it helps to understand the specification. The requirements, in my=20 opinion, are useful for determining whether a use case is supported.=20


Overall I think it's an extremely useful=20 document.

Melinda
_______________________________________________=
OAuth=20 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--_000_5710F82C0E73B04FA559560098BF95B12507584ECCUSNAVSXCHMBSA_-- From mscurtescu@google.com Fri Apr 29 15:18:48 2011 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 3C60CE072D for ; Fri, 29 Apr 2011 15:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbPY16Cy8zF3 for ; Fri, 29 Apr 2011 15:18:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4050CE06DA for ; Fri, 29 Apr 2011 15:18:46 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p3TMIiVn006634 for ; Fri, 29 Apr 2011 15:18:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304115525; bh=0xIG6FunDIordrs5WX1SIVW0004=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=w/W79tQakevIcj6mxq1WuCdzxvmfV6Q8XCQZBnvPhcdNmHRAe/Y5DtVQOlvUi07f2 iuK0UuSlSvqzmvRWa/atw== Received: from yxe42 (yxe42.prod.google.com [10.190.2.42]) by kpbe13.cbf.corp.google.com with ESMTP id p3TMIGUc019281 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 29 Apr 2011 15:18:43 -0700 Received: by yxe42 with SMTP id 42so1437371yxe.30 for ; Fri, 29 Apr 2011 15:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZpBBXnAJfYpZPETGbpOHHTTLXO15aJg0drp9qZbVj2w=; b=ignov6ncu6PkydkWUs8MTGq00s2iuAHQqAZoBAU1/dZZmcTswUzdf0E8Sw9NTU/QbY ESEqyqshAYVndu6zbdjA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=ONdRM2DhCZ9k9DrkT6hMA0SFCAGeA4g2LqzV6l8zI/vSBxBWACnroOqrsXjFfUx104 L9KzFvBkChhM6SbwAj2w== Received: by 10.101.19.8 with SMTP id w8mr3489028ani.57.1304115523175; Fri, 29 Apr 2011 15:18:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.9 with HTTP; Fri, 29 Apr 2011 15:18:23 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Fri, 29 Apr 2011 15:18:23 -0700 Message-ID: To: Doug Tangren Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] implicit clients and refresh tokens 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, 29 Apr 2011 22:18:48 -0000 On Thu, Apr 21, 2011 at 9:26 AM, Doug Tangren wrote: > According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.2.2 > it doesn't look like clients of the implicit oauth2 flow should receive a > refreshing token although it looks like the access token can optionally have > an expires_in time set. Does this mean there is no step for an implicit > client to refresh their access token without involving the user again? > > According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-6 it > looks like a client needs to send in the client credentials, including the > client secret, to refresh an access token. This is a no-go for clients that > can't securely secure a client secret like a web browser. > > Is providing no way for an implicit client to refresh an access token > without involving the resource owner intended? This is a real issue and the only solution I am aware of is to support an immediate mode and auto-approvals. When the access token expires the client can try an immediate mode request in an invisible iframe. If it works, then it has a new access token, if not then it must involve the user. For immediate mode an extra parameter is needed, no defined in the core spec, that tells the authorization server that no UI should be shown and an auto-approval should be attempted. Google currently supports this, the immediate mode parameter is immediate=true. Auto-approval will happen if the same client/user/scopes/redirect_uri have been approved before. Hope this helps, Marius From jricher@mitre.org Sat Apr 30 12:24:37 2011 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 EAA14E06A3 for ; Sat, 30 Apr 2011 12:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIgWg2EubPw7 for ; Sat, 30 Apr 2011 12:24:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4F23FE0697 for ; Sat, 30 Apr 2011 12:24:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EB44B41A076D; Sat, 30 Apr 2011 15:14:31 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E439341A076C; Sat, 30 Apr 2011 15:14:31 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Sat, 30 Apr 2011 15:14:31 -0400 From: "Richer, Justin P." To: Marius Scurtescu Date: Sat, 30 Apr 2011 15:13:44 -0400 Thread-Topic: [OAUTH-WG] implicit clients and refresh tokens Thread-Index: AcwGu2scDfBbcUoNTweu3UVpNwkYpQAr05yj Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] implicit clients and refresh tokens 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, 30 Apr 2011 19:24:38 -0000 Seems like immediate mode should be added into the UX spec to me, maybe eve= n as "display=3Dnone". Is there any interest in that? -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Marius S= curtescu [mscurtescu@google.com] Sent: Friday, April 29, 2011 6:18 PM To: Doug Tangren Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] implicit clients and refresh tokens On Thu, Apr 21, 2011 at 9:26 AM, Doug Tangren wrote: > According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.= 2.2 > it doesn't look like clients of the implicit oauth2 flow should receive a > refreshing token although it looks like the access token can optionally h= ave > an expires_in time set. Does this mean there is no step for an implicit > client to refresh their access token without involving the user again? > > According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-6 = it > looks like a client needs to send in the client credentials, including th= e > client secret, to refresh an access token. This is a no-go for clients th= at > can't securely secure a client secret like a web browser. > > Is providing no way for an implicit client to refresh an access token > without involving the resource owner intended? This is a real issue and the only solution I am aware of is to support an immediate mode and auto-approvals. When the access token expires the client can try an immediate mode request in an invisible iframe. If it works, then it has a new access token, if not then it must involve the user. For immediate mode an extra parameter is needed, no defined in the core spec, that tells the authorization server that no UI should be shown and an auto-approval should be attempted. Google currently supports this, the immediate mode parameter is immediate=3Dtrue. Auto-approval will happen if the same client/user/scopes/redirect_uri have been approved before. Hope this helps, Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Sat Apr 30 14:29:35 2011 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 10B07E06E6 for ; Sat, 30 Apr 2011 14:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vh0lPUfqMWp for ; Sat, 30 Apr 2011 14:29:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 508B3E0694 for ; Sat, 30 Apr 2011 14:29:34 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p3ULTXsi015428 for ; Sat, 30 Apr 2011 14:29:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304198973; bh=woFMEnpXf9/s27jsp37AWi1EpdE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=bgESEvWD1oeuh52zCXW9oDIAQ261kr5iEOuSVO8mY98jO6O6JwQ/s5xdgpXhIutC+ pwDeKYyX0UF7qS0T9s6Ww== Received: from pvc30 (pvc30.prod.google.com [10.241.209.158]) by kpbe18.cbf.corp.google.com with ESMTP id p3ULTVXc026371 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 30 Apr 2011 14:29:32 -0700 Received: by pvc30 with SMTP id 30so3137308pvc.20 for ; Sat, 30 Apr 2011 14:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZYcumefw/7S/tXP9tNAOuSqPa9mXwjZC8R7p2ttxHKA=; b=kkKksefqnCTXfU3LOTKqR3HpqTg2GFhfA1wBfhbgkS7GCkJCaorcChn1ov8iDfXj7i x3ok4Y3hn14Kg1gWUwUw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=B7meJWGM8QaCdal/TvtXyJEZ1bgRAXBBxTZyHtP/BOVSMYCBJd/h1rFJy/Sa5cg/pL /50MJOUfuLJEoGV8t6QQ== MIME-Version: 1.0 Received: by 10.142.128.21 with SMTP id a21mr2549096wfd.38.1304198969644; Sat, 30 Apr 2011 14:29:29 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Sat, 30 Apr 2011 14:29:29 -0700 (PDT) In-Reply-To: References: Date: Sat, 30 Apr 2011 14:29:29 -0700 Message-ID: From: Brian Eaton To: Doug Tangren Content-Type: multipart/alternative; boundary=000e0cd331d44d589a04a2297c68 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] requirement of redirect_uri in access token requests 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, 30 Apr 2011 21:29:35 -0000 --000e0cd331d44d589a04a2297c68 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 29, 2011 at 11:21 AM, Doug Tangren wrote: > Is this required or not? In the example > http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-3.1 it's listed > in the example but not itemized as optional or required. It's not in the > example for refreshing tokens > http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-6 though that > section links back to section 3.1 which does use a redirect_uri in the > example. > > Should the redirect_uri be a requirement for client authentication or is it > optional? > It should be required when exchanging an authorization code for a refresh token. This provides a defense against authorization codes which have leaked due to open redirectors. It should not be present under other circumstances. --000e0cd331d44d589a04a2297c68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Apr 29, 2011 at 11:21 AM, Doug Tangren <d.tangren@gmail.com> wrote:<= br>
Is this required or not? In the example http://tools.ietf.= org/html/draft-ietf-oauth-v2-15#section-3.1 it's listed in the exam= ple but not itemized as optional or required. It's not in the example f= or refreshing tokens http://tools.ietf.org/html/draft-ietf-o= auth-v2-15#section-6 though that section links back to section 3.1 whic= h does use a redirect_uri in the example.

Should the redirect_uri be a requirement for client authentication or i= s it optional?

It should be required wh= en exchanging an authorization code for a refresh token. =A0This provides a= defense against authorization codes which have leaked due to open redirect= ors.

It should not be present under other circumstances.
--000e0cd331d44d589a04a2297c68-- From andrewarnott@gmail.com Sat Apr 30 20:50:49 2011 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 4E73CE0709 for ; Sat, 30 Apr 2011 20:50:49 -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=[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 KYBlNDJfW-wh for ; Sat, 30 Apr 2011 20:50:48 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF52E0691 for ; Sat, 30 Apr 2011 20:50:48 -0700 (PDT) Received: by qwc23 with SMTP id 23so2960356qwc.31 for ; Sat, 30 Apr 2011 20:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=OIGyl2V37Xqf0jWVYq2czOdca7x8zich0/ZGnEMTbxg=; b=kwKEdWgXC7l50zNgl/M2WdwJDQ2W9j3bi7k9VCABD4xWAuXUKPhLNvFPP042JCmNwW eWiYs8Uc1U50AQwJFjvbYUaaODfqn518TBiYCJvN9tdkrMwfMDX3FCaRCy3DrgETHP0G LBUc9rpkBq1TT6KhQMloDldrIPTUxQbUDvuOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=DjWGJ/jcwXxq40aA39SjJnEsjpB1rAZrAEU6sWTK2cm9pghLxrXCuhe5AknU2Un42f waqdOjDQFt+bwK+TY7fijEBEHkHuYGGetycTZEspsT+ewMNP/XqUXTybVbt/JTRu1sSn qEW7SxzOKQl9JTyB/Tps/Qn526KY/KUWGtVEM= Received: by 10.229.9.195 with SMTP id m3mr5073506qcm.137.1304221847341; Sat, 30 Apr 2011 20:50:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.82.83 with HTTP; Sat, 30 Apr 2011 20:50:27 -0700 (PDT) From: Andrew Arnott Date: Sat, 30 Apr 2011 20:50:27 -0700 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=0016360e3f5ceb4a8d04a22ecfb8 Subject: [OAUTH-WG] OAuth 1.0 2-legged scenario 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, 01 May 2011 03:50:49 -0000 --0016360e3f5ceb4a8d04a22ecfb8 Content-Type: text/plain; charset=ISO-8859-1 Does this docaccurately describe what the community generally refers to as "two-legged OAuth"? If so, I have a couple questions... What about this is "*two* legged"? I count zero legs. The consumer already has a key and secret, and uses them to access resources. Not a single one of the 3 legs in standard OAuth's "unauthorized request token, authorize, exchange for access token" flow are present in the above linked spec by my reading of it. I expected two-legged OAuth to be more like this: 1. The client presumably already has a consumer key, but perhaps no secret since these clients can rarely keep secrets. I'm imagining clients that are desktop sidebar gadgets, perhaps. 2. Upon first run, this app performs these two legs: 1. Obtains a request token using the standard OAuth 1.0 flow. This would traditionally be an unauthorized request token. But in 2-legged OAuth this request token is implicitly auto-authorized, for access to a new, empty account on the service provider. 2. Exchanges the request token for an access token, again using the standard OAuth 1.0 flow for that step. 3. At this point, the client has a consumer key, perhaps a consumer secret, and an access token and token secret. The token represents an empty account, but may be filled and later queried by that client. The fact that the client has no consumer secret is of little consequence because the access token secret is unique for this particularly installation of the client and therefore the data is protected. So... which one is right? And does the "wrong" one have any validity? Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --0016360e3f5ceb4a8d04a22ecfb8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Does this doc accurately describe what the commu= nity generally refers to as "two-legged OAuth"?=A0 If so, I have = a couple questions...
=A0
What about this is "two legged"?=A0 I= count=A0zero legs.=A0=A0The consumer already has a key and secret, and use= s them to access resources.=A0 Not a single one of the 3 legs in standard O= Auth's "unauthorized request token, authorize, exchange for access= token" flow are present in the above linked spec by my reading of it.=
=A0
I expected two-legged OAuth to be more like this:
<= ol>
  • The client presumably already has a consumer key, but perhaps no sec= ret since these clients can rarely keep secrets.=A0 I'm imagining clien= ts that are desktop sidebar gadgets, perhaps.
  • Upon first run, this app performs these two legs:
    1. Obtains a= request token using the standard OAuth 1.0 flow.=A0 This would traditional= ly be an unauthorized request token.=A0 But in 2-legged OAuth this request = token is implicitly auto-authorized, for access to a new, empty account on = the service provider.
    2. Exchanges the request token for an access token, again using the standa= rd OAuth 1.0 flow for that step.=A0
  • At this point, the client= has a consumer key, perhaps a consumer secret, and an access token and tok= en secret.=A0 The token represents an empty account, but may be filled and = later queried by that client.=A0 The fact that the client has no consumer s= ecret is of little consequence because the access token secret is unique fo= r this particularly installation of the client and therefore the data is pr= otected.
    • So... which one is right?=A0 And does the "wrong" one h= ave any validity?
    =A0
    Thanks.
    --
    An= drew Arnott
    "I [may] not agree with what you have to say, bu= t I'll defend to the death your right to say it." - S. G. Tallenty= re
    =A0
    --0016360e3f5ceb4a8d04a22ecfb8-- From eran@hueniverse.com Sat Apr 30 22:40:01 2011 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 4257EE0689 for ; Sat, 30 Apr 2011 22:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 4d7huXDUAwJY for ; Sat, 30 Apr 2011 22:39:59 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 883AAE0651 for ; Sat, 30 Apr 2011 22:39:57 -0700 (PDT) Received: (qmail 21986 invoked from network); 1 May 2011 05:39:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 May 2011 05:39:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 30 Apr 2011 22:38:32 -0700 From: Eran Hammer-Lahav To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Sat, 30 Apr 2011 22:38:08 -0700 Thread-Topic: [OAUTH-WG] OAuth 1.0 2-legged scenario Thread-Index: AcwHsvpUWmoPB2+fSq+78MkWSMfRHAADpnWA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72344757F914D6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72344757F914D6P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth 1.0 2-legged scenario 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, 01 May 2011 05:40:01 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72344757F914D6P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The term 'two-legged' really means traditional client-server communication,= where the OAuth 1.0 signature flow is used for authenticating the client. = There are a few flavors of this, some using just the client credentials and= others using an access token as well. The original idea was that if the client already has a set of credentials e= stablished with the server, using OAuth is better than HTTP Basic, even if = no resource owner is involved. OAuth 2.0 does not cover this use case, as all token authentication is defi= ned elsewhere. The MAC draft is specifically designed to address it. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Saturday, April 30, 2011 8:50 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] OAuth 1.0 2-legged scenario Does this doc accurately describe what the community generally refer= s to as "two-legged OAuth"? If so, I have a couple questions... What about this is "two legged"? I count zero legs. The consumer already = has a key and secret, and uses them to access resources. Not a single one = of the 3 legs in standard OAuth's "unauthorized request token, authorize, e= xchange for access token" flow are present in the above linked spec by my r= eading of it. I expected two-legged OAuth to be more like this: 1. The client presumably already has a consumer key, but perhaps no secre= t since these clients can rarely keep secrets. I'm imagining clients that = are desktop sidebar gadgets, perhaps. 2. Upon first run, this app performs these two legs: * Obtains a request token using the standard OAuth 1.0 flow. This wo= uld traditionally be an unauthorized request token. But in 2-legged OAuth = this request token is implicitly auto-authorized, for access to a new, empt= y account on the service provider. * Exchanges the request token for an access token, again using the st= andard OAuth 1.0 flow for that step. 1. At this point, the client has a consumer key, perhaps a consumer secre= t, and an access token and token secret. The token represents an empty acc= ount, but may be filled and later queried by that client. The fact that th= e client has no consumer secret is of little consequence because the access= token secret is unique for this particularly installation of the client an= d therefore the data is protected. So... which one is right? And does the "wrong" one have any validity? Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre --_000_90C41DD21FB7C64BB94121FBBC2E72344757F914D6P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    The term = ‘two-legged’ really means traditional client-server communicati= on, where the OAuth 1.0 signature flow is used for authenticating the clien= t. There are a few flavors of this, some using just the client credentials = and others using an access token as well.

     

    The= original idea was that if the client already has a set of credentials esta= blished with the server, using OAuth is better than HTTP Basic, even if no = resource owner is involved.

     

    OAuth 2.0 does no= t cover this use case, as all token authentication is defined elsewhere. Th= e MAC draft is specifically designed to address it.

     

    = EHL

     

    From: oauth-bounces@ie= tf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew ArnottSent: Saturday, April 30, 2011 8:50 PM
    To: OAuth WG (oaut= h@ietf.org)
    Subject: [OAUTH-WG] OAuth 1.0 2-legged scenario<= /o:p>

     

    =

    Does this doc accurately describ= e what the community generally refers to as "two-legged OAuth"?&n= bsp; If so, I have a couple questions...

     

    What abou= t this is "two legged"?  I count zero legs.&nb= sp; The consumer already has a key and secret, and uses them to access= resources.  Not a single one of the 3 legs in standard OAuth's "= unauthorized request token, authorize, exchange for access token" flow= are present in the above linked spec by my reading of it.

     

    I expected two-legged OAuth to be more like this:

    1. The client presum= ably already has a consumer key, but perhaps no secret since these clients = can rarely keep secrets.  I'm imagining clients that are desktop sideb= ar gadgets, perhaps.
    2. Upon fi= rst run, this app performs these two legs:
      1. Obtains a= request token using the standard OAuth 1.0 flow.  This would traditio= nally be an unauthorized request token.  But in 2-legged OAuth this re= quest token is implicitly auto-authorized, for access to a new, empty accou= nt on the service provider.
      2. = Exchanges the request token for an access token, again using the standard O= Auth 1.0 flow for that step. 
    1. At this point, the client has a co= nsumer key, perhaps a consumer secret, and an access token and token secret= .  The token represents an empty account, but may be filled and later = queried by that client.  The fact that the client has no consumer secr= et is of little consequence because the access token secret is unique for t= his particularly installation of the client and therefore the data is prote= cted.

    So... which one is righ= t?  And does the "wrong" one have any validity?

     

    Thanks.

    --<= /o:p>

    Andrew Arnott

    =

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

     

    = --_000_90C41DD21FB7C64BB94121FBBC2E72344757F914D6P3PW5EX1MB01E_--