Re: [OAUTH-WG] Fwd: I-D Action:draft-hardt-oauth-01.txt

I am trying to get a better understanding of Oauth an= d need answers to the following questions:

* Why is there a need= for a token secret given that there is a client secret?

* How is the token se= cret protected when is transmitted from Server to Client as part of the tem= porary credentials?

* Why is there a need= for temporary credentials?

Could you please help with the answers?

With thanks and best wishes for the New Year,<= /div>

Zachary Zeltsan

--_000_5710F82C0E73B04FA559560098BF95B124EED7E257USNAVSXCHMBSA_-- From stpeter@stpeter.im Thu Jan 7 13:01:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A2E28C163; Thu, 7 Jan 2010 13:01:32 -0800 (PST) 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 LIgBgpQE4P-u; Thu, 7 Jan 2010 13:01:31 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 10F1328C120; Thu, 7 Jan 2010 13:01:31 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0E23040D10; Thu, 7 Jan 2010 14:01:28 -0700 (MST) Message-ID: <4B464BA7.7040308@stpeter.im> Date: Thu, 07 Jan 2010 14:01:27 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080302060109040709020501" Cc: IESG Secretary Subject: [OAUTH-WG] OAuth interim meeting, 2010-01-21 X-BeenThere: oauth@ietf.org X-Mailman-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 Jan 2010 21:01:32 -0000 This is a cryptographically signed message in MIME format. --------------ms080302060109040709020501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit The OAuth WG will hold an interim meeting on January 21, 2010, at 19:00 UTC for 60 minutes, via conference call (WebEx) and the WG's chatroom. This is the first of what we expect will be a series of meetings leading up to IETF 77, but at this time we are scheduling only the first session so that we can work out various logistical issues. Call-in details to follow from the Secretariat, and agenda to follow from the Chairs. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms080302060109040709020501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDEwNzIxMDEyN1owIwYJKoZIhvcNAQkEMRYEFI79RhJwdpEYU8/qyOkY S1RUPTM9MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAWMQNXObxQmKbCU4fL/WX+5JBT9o0ubl7WAQR3VOO oII0IUm5qF1vJ7oEWJojYTaoYnZHAlYklL8UYxwEUWfKz+ozigURC7aqCKhoSK3rvnXvvMpJ EKb7wgZhtYAEXrXshD9Yvx/Ya2fdRJQKzcYyNzR/cL07ezzJgSVrX0aFX7dmUyJv0NEvrZGA 08urZTFp55vcSs3md5cN0jasK2hGZ+FpI2J79jnlWRJbQE6n8wc1lkvxMvKwn5di52Vjaf4J Tlq86WbUhaxI+rHF5ZfpW4uH3ok5BitSAcE7ZUuIvNInsGaAJf7AZAmmra1amZoZytYUhiCf cJ9oP2+5jrcs2gAAAAAAAA== --------------ms080302060109040709020501-- From root@core3.amsl.com Thu Jan 7 14:00:02 2010 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 262FF3A689F; Thu, 7 Jan 2010 14:00:01 -0800 (PST) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100107220002.262FF3A689F@core3.amsl.com> Date: Thu, 7 Jan 2010 14:00:02 -0800 (PST) Cc: oauth@ietf.org Subject: [OAUTH-WG] OAuth WG Virtual Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-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 Jan 2010 22:00:02 -0000 The OAuth WG will hold a virtual interim meeting on January 21, 2010, at 19:00 UTC for 60 minutes, via conference call (WebEx) and the WG's chatroom. This is the first of what we expect will be a series of meetings leading up to IETF 77, but at this time we are scheduling only the first session so that we can work out various logistical issues. Call-in details and agenda to follow on the OAuth mailing list (http://www.ietf.org/mail-archive/web/oauth/current/maillist.html). From recordond@gmail.com Fri Jan 8 15:44:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E643A6407 for ; Fri, 8 Jan 2010 15:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiB-XFMnWAJm for ; Fri, 8 Jan 2010 15:44:45 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 9359E3A6405 for ; Fri, 8 Jan 2010 15:44:45 -0800 (PST) Received: by iwn33 with SMTP id 33so5960025iwn.29 for ; Fri, 08 Jan 2010 15:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=8rX7TVL3feR5PyOW/UgjCR+98jV2qt5RxX6B1PoNbjQ=; b=h7r5ikoCtGH9wBDgOg8uSIQ/6kD+01q5T0Lhdw1jK6Hq/bLjqf9LoaZaP9h88j5tzT CGfas2uoJwCC3NIOiR8HlgZXc5C3Rzj0jJnadJ1w9snP+Tigi5ixUD1pPimnXEUe/7wF LrCRjINStUkRQLSg/Kq2DcM5tkOmmjlaHijw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=d80Bkl6eUN5QbojjVuEooTQ+cmaQ4/s4q27JGIhwFm4KWdzYTv/X/kj9qsU5E5jYlM y+WsyGKDkBIcIyXOXDvYplvUF/J1nT6nEUU7PtZdwryEeSuG8A5Ih2i3KZQXNJ0kLOt7 3Np7p6M6rgl3gUKqOuk19QRWNnJeC60HQjZ7I= MIME-Version: 1.0 Received: by 10.231.40.216 with SMTP id l24mr2088178ibe.40.1262994280968; Fri, 08 Jan 2010 15:44:40 -0800 (PST) Date: Fri, 8 Jan 2010 15:44:40 -0800 Message-ID: From: David Recordon To: oauth@googlegroups.com, OAuth WG , oauth-wrap-wg@googlegroups.com Content-Type: multipart/alternative; boundary=001517741146787210047cafc5fa Subject: [OAUTH-WG] Talking about what's up with 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 Jan 2010 23:44:46 -0000 --001517741146787210047cafc5fa Content-Type: text/plain; charset=ISO-8859-1 Sorry for emailing across a few lists, but this morning Chris Messina, Dick Hardt, and I wrote a post on O'Reilly Radar talking about the successes of OAuth 1.0a, the introduction of WRAP, and where we think there is consensus to build OAuth 2.0. I might be biased, but it's worth a read. ;) http://radar.oreilly.com/2010/01/whats-going-on-with-oauth.html --David --001517741146787210047cafc5fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry for emailing=A0across=A0a few lists, but this morning Chris Messina, = Dick Hardt, and I wrote a post on O'Reilly Radar talking about the succ= esses of OAuth 1.0a, the introduction of WRAP, and where we think there is = consensus to build OAuth 2.0. =A0I might be biased, but it's worth a re= ad. ;)

http://radar.oreilly.com/2010/01/whats-going-on-with-oauth.= html

--David

--001517741146787210047cafc5fa-- From recordond@gmail.com Fri Jan 8 16:35:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E344C3A68C9 for ; Fri, 8 Jan 2010 16:35:19 -0800 (PST) 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 mgPIxDTHRYPK for ; Fri, 8 Jan 2010 16:35:19 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 1B0283A68C5 for ; Fri, 8 Jan 2010 16:35:19 -0800 (PST) Received: by pxi16 with SMTP id 16so5435632pxi.29 for ; Fri, 08 Jan 2010 16:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=uWWrWQfkQGLr0/xANdDRkWcY0I9inJ5xkdekITMRgHE=; b=oCZ2Z2MbLBJEosVXbWfhAkUcaaIqpV71yHnIQFkZ9ckg7B/BpSeiVcC/l/KDsLZ/LH 3RFQElVBpU64FguXhlkKG9lI2kXDP64zH3e4bul0QyqYB1njfUzHK+vkTcH0tAZuSCgp VTrin6dOxYwI1DFRr92Z3nt4S6Ffy/iMlGQVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=qj0cdMqGXx6YBhzOPsg/Nj2tmZhiBowruDfoaasYBvmJIt7cCJVW+z/8swNwSIPftd otHD3QqykmZ9BQYMIFsXlyGuwELcBzyjvXNLS/+JEYgRgYuo2dPu73R5f3hb9jxH22nj kkT8oB0tZyrJ5UyoM9dzZcQZQISg0EFAoP7AI= Received: by 10.143.26.40 with SMTP id d40mr2190413wfj.232.1262997309107; Fri, 08 Jan 2010 16:35:09 -0800 (PST) Received: from ?10.44.133.87? ([166.205.138.111]) by mx.google.com with ESMTPS id 21sm19064169pzk.11.2010.01.08.16.35.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 Jan 2010 16:35:08 -0800 (PST) References: Message-Id: From: David Recordon To: David Recordon In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2--925218611 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 8 Jan 2010 16:35:04 -0800 Cc: "oauth@googlegroups.com" , OAuth WG , "oauth-wrap-wg@googlegroups.com" Subject: Re: [OAUTH-WG] Talking about what's up with 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: Sat, 09 Jan 2010 00:35:20 -0000 --Apple-Mail-2--925218611 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I forgot to mention Eran as well, he helped to write it as well! :) -- Sent from my iPhone On Jan 8, 2010, at 3:44 PM, David Recordon wrote: > Sorry for emailing across a few lists, but this morning Chris > Messina, Dick Hardt, and I wrote a post on O'Reilly Radar talking > about the successes of OAuth 1.0a, the introduction of WRAP, and > where we think there is consensus to build OAuth 2.0. I might be > biased, but it's worth a read. ;) > > http://radar.oreilly.com/2010/01/whats-going-on-with-oauth.html > > --David --Apple-Mail-2--925218611 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I forgot to mention Eran as well, he helped to write it as well! :)

Sent from my iPhone

On Jan 8, 2010, at 3:44 PM, David Recordon <recordond@gmail.com> wrote:

Sorry for emailing across a few lists, but this morning Chris Messina, Dick Hardt, and I wrote a post on O'Reilly Radar talking about the successes of OAuth 1.0a, the introduction of WRAP, and where we think there is consensus to build OAuth 2.0. I might be biased, but it's worth a read. ;)

http://radar.oreilly.com/2010/01/whats-going-on-with-oauth.html

--David

--Apple-Mail-2--925218611-- From eran@hueniverse.com Fri Jan 8 18:15:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3F23A6830 for ; Fri, 8 Jan 2010 18:15:13 -0800 (PST) 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 m3K3HkeYAm2n for ; Fri, 8 Jan 2010 18:15:12 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id BC31C3A659C for ; Fri, 8 Jan 2010 18:15:12 -0800 (PST) Received: (qmail 16345 invoked from network); 9 Jan 2010 02:15:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Jan 2010 02:15:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 8 Jan 2010 19:15:07 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" , "oauth@googlegroups.com" Date: Fri, 8 Jan 2010 19:15:21 -0700 Thread-Topic: OAuth 1.0 PLAINTEXT without SSL/TLS Thread-Index: AcqQ0Zhc5Ipm+e5/S5Sab0hJ0rIhkg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343787F3416B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AQk1 AYkq AtlO B0no HXCm Java KGWU LQ5r LsFb NnxH NqJI O9A5 PSUj QCmE R0w9 XLdi; 2; bwBhAHUAdABoAEAAZwBvAG8AZwBsAGUAZwByAG8AdQBwAHMALgBjAG8AbQA7AG8AYQB1AHQAaABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {72DC72FE-6FAF-48AF-A9AB-C99F1E6591F9}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Sat, 09 Jan 2010 02:15:21 GMT; TwBBAHUAdABoACAAMQAuADAAIABQAEwAQQBJAE4AVABFAFgAVAAgAHcAaQB0AGgAbwB1AHQAIABTAFMATAAvAFQATABTAA== x-cr-puzzleid: {72DC72FE-6FAF-48AF-A9AB-C99F1E6591F9} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 1.0 PLAINTEXT without SSL/TLS X-BeenThere: oauth@ietf.org X-Mailman-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 Jan 2010 02:15:13 -0000 I no longer think there is a valid reason why the OAuth 1.0 specification d= oes not mandate using a secure channel with PLAINTEXT, and I would like to = make this change from SHOULD to MUST in the RFC draft [1]. Is there anyone using OAuth PLAINTEXT *not* over TLS/SSL? Is there a *good*= reason why the 1.0 specification should not mandate using a secure channel= for PLAINTEXT? If someone really wants to use it without, it's a free coun= try but I can't think of any reason. The only reason not to make the change is if there are existing deployed us= e cases where PLAINTEXT is used in such a way. If there are none after two = years, we should not allow it moving forward. EHL [1] http://tools.ietf.org/html/draft-hammer-oauth From faynberg@alcatel-lucent.com Fri Jan 8 18:44:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5E228C0E4 for ; Fri, 8 Jan 2010 18:44:47 -0800 (PST) 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 2J3LuDh70Afi for ; Fri, 8 Jan 2010 18:44:47 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 08DF928C0EB for ; Fri, 8 Jan 2010 18:44:43 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o092iaXx012641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 20:44:36 -0600 (CST) Received: from [135.244.37.103] (faynberg.lra.lucent.com [135.244.37.103]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o092iZ4F027891; Fri, 8 Jan 2010 20:44:35 -0600 (CST) Message-ID: <4B47ED93.1080801@alcatel-lucent.com> Date: Fri, 08 Jan 2010 21:44:35 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343787F3416B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343787F3416B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "oauth@googlegroups.com" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 1.0 PLAINTEXT without SSL/TLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 02:44:47 -0000 I fully support this. I think Zachary has been questioning that "should," too, in his recent post. Furthermore, even if there are implementations that are not using TLS (or SSL), I would look at it as an implementation--not specification--problem. The specification must not have known security holes. Igor Eran Hammer-Lahav wrote: > I no longer think there is a valid reason why the OAuth 1.0 specification does not mandate using a secure channel with PLAINTEXT, and I would like to make this change from SHOULD to MUST in the RFC draft [1]. > > Is there anyone using OAuth PLAINTEXT *not* over TLS/SSL? Is there a *good* reason why the 1.0 specification should not mandate using a secure channel for PLAINTEXT? If someone really wants to use it without, it's a free country but I can't think of any reason. > > The only reason not to make the change is if there are existing deployed use cases where PLAINTEXT is used in such a way. If there are none after two years, we should not allow it moving forward. > > EHL > > [1] http://tools.ietf.org/html/draft-hammer-oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From john@jkemp.net Sat Jan 9 04:43:02 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A9C3A6808 for ; Sat, 9 Jan 2010 04:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czV11rvvjC9z for ; Sat, 9 Jan 2010 04:43:01 -0800 (PST) Received: from outbound-mail-105.bluehost.com (outbound-mail-105.bluehost.com [69.89.18.5]) by core3.amsl.com (Postfix) with SMTP id 0384B3A67EB for ; Sat, 9 Jan 2010 04:43:00 -0800 (PST) Received: (qmail 22641 invoked by uid 0); 9 Jan 2010 12:42:58 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy3.bluehost.com with SMTP; 9 Jan 2010 12:42:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=oY/N+T/r68pU9ZR4XO2uXnw0BCaTypz2sbsxEDAT1jmaHHMV2rs6N7qI/E+Swigv0bHQnCy4RCOvhtKs2IZgPY16v7bFv0zLXgonDhwMJn9WM3Lw23y8FDHjlfWW17Ou; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.103]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NTaeg-0002tI-9E; Sat, 09 Jan 2010 05:42:58 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343787F3416B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 9 Jan 2010 07:42:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E72343787F3416B@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: oauth@googlegroups.com X-Mailer: Apple Mail (2.1077) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] [oauth] OAuth 1.0 PLAINTEXT without SSL/TLS X-BeenThere: oauth@ietf.org X-Mailman-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 Jan 2010 12:43:02 -0000 On Jan 8, 2010, at 9:15 PM, Eran Hammer-Lahav wrote: [...] > Is there a *good* reason why the 1.0 specification should not mandate = using a secure channel for PLAINTEXT?=20 I guess the question is whether you want implementations using other = methods to ensure confidentiality and which don't need other security = properties (servers on an intranet, for example, firewalled/VPN'd from = the general Internet) to become non-conforming? > The only reason not to make the change is if there are existing = deployed use cases where PLAINTEXT is used in such a way. I would imagine that there are deployments of OAuth in environments = where they simply want to use PLAINTEXT for authorization, and have = existing methods of dealing with other security properties.=20 What is the actual reasoning behind this change? I don't understand why = we would suddenly now decide to make some whole class of implementations = non-conforming, even if there were only few deployments? Regards, - johnk= From romeda@gmail.com Sat Jan 9 05:17:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75BB43A67E9 for ; Sat, 9 Jan 2010 05:17:38 -0800 (PST) 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 g9aZ3x0kv3hC for ; Sat, 9 Jan 2010 05:17:37 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 79BA73A67B1 for ; Sat, 9 Jan 2010 05:17:37 -0800 (PST) Received: by fxm7 with SMTP id 7so18451566fxm.29 for ; Sat, 09 Jan 2010 05:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=tZ6vbcnTP7vGA9yRxQ8QcDzWoDLfnFXkGX0gs7WrGvg=; b=xePKjlpT10SXcLWPXYUZJ5Gqgg3P8EwpdN4U4sWDKcDz2Vz5c065ByRCyy7Fngd9Zs UW1kp+R1K/F1Xt06gV/K5ABKGthC1+YWoO9OjEtZHPx7ebotduS2DcrIWgj94XJYbil4 2Q3N0aKnOZR8yxzaeQppKcgaFEEZeUlTTwaWM= 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=A6P7pahPS0v4u1lAsfQuXv1ouGr9GKBM8Dw4HFRiwVZQYzbcey0I1vAFt1ifb2sQCp qAqJ9Hsa8Gw6o5acAF6bNBLEP63BtKUbz/sNzRiVLGScczDAXyqPM2HIP7/9FwVG6Guf 7FCW53BY+Mfl8OHcyGMaFccVDtaM0+XElb4rY= MIME-Version: 1.0 Received: by 10.103.84.27 with SMTP id m27mr6451377mul.19.1263043052102; Sat, 09 Jan 2010 05:17:32 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343787F3416B@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Blaine Cook Date: Sat, 9 Jan 2010 13:17:12 +0000 Message-ID: To: oauth@googlegroups.com Content-Type: text/plain; charset=UTF-8 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] [oauth] OAuth 1.0 PLAINTEXT without SSL/TLS X-BeenThere: oauth@ietf.org X-Mailman-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 Jan 2010 13:17:38 -0000 2010/1/9 John Kemp : > On Jan 8, 2010, at 9:15 PM, Eran Hammer-Lahav wrote: > > What is the actual reasoning behind this change? I don't understand why we would suddenly now decide to make some whole class of implementations non-conforming, even if there were only few deployments? Eran did ask if anyone was using OAuth PLAINTEXT without SSL; that said, I don't think that it matters if anyone is using PLAINTEXT with SSL; the spec should outline the basis for interop, and implementations that want to be interoperable and secure MUST check to see that SSL is being used for PLAINTEXT (especially server implementations). Implementations are always free (as in free country) to have special flags that disable the security checks and put their OAuth implementation into non-spec-compliant mode. The same sort of principle applies to TLS client implementations; the certificate chain MUST be checked as per the specification, but many clients allow developers just issue warnings or provide flags to turn off the warnings that the certificate chain checks are not being performed. Even though silenced warnings that your TLS connections are insecure is bad, it's better than the authors of TLS libraries not having to consider those warnings at all. b. From eran@hueniverse.com Sat Jan 9 09:12:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693ED3A6858 for ; Sat, 9 Jan 2010 09:12:06 -0800 (PST) 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 zTYpYIskbCMk for ; Sat, 9 Jan 2010 09:12:05 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0BF993A67FE for ; Sat, 9 Jan 2010 09:12:04 -0800 (PST) Received: (qmail 14624 invoked from network); 9 Jan 2010 17:12:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Jan 2010 17:12:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 9 Jan 2010 10:12:02 -0700 From: Eran Hammer-Lahav To: John Kemp , "oauth@googlegroups.com" Date: Sat, 9 Jan 2010 10:12:22 -0700 Thread-Topic: [OAUTH-WG] [oauth] OAuth 1.0 PLAINTEXT without SSL/TLS Thread-Index: AcqRKUjeS8oWaD0yQ7yb53I9oukqXgAI6MVw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343787F341B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343787F3416B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] [oauth] OAuth 1.0 PLAINTEXT without SSL/TLS X-BeenThere: oauth@ietf.org X-Mailman-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 Jan 2010 17:12:06 -0000 Hi John, > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of John Kemp > Sent: Saturday, January 09, 2010 4:43 AM > What is the actual reasoning behind this change? I don't understand why w= e > would suddenly now decide to make some whole class of implementations > non-conforming, even if there were only few deployments? I have come to the conclusion that arguments against requiring a secure cha= nnel during some portions of the protocols are irrelevant. We have been mak= ing the case that some environments will not be able to deploy OAuth if SSL= /TLS is requires, but we should put that claim under the same practical scr= utiny as other requirements we consider. I did a quick survey of existing i= mplementations and every single one uses HTTPS for obtaining tokens and for= PLAINTEXT requests. If someone if going to write internal implementations, they are free to cha= nge the protocol as they see fit. In such cases interop is more influenced = by the internal nature of the system than the specification. But I can't co= me up with a single reason why we should allow, by making it a SHOULD, to i= mplement OAuth in such an obviously insecure way (in an IETF RFC). My argument is that there is little practical difference between sending to= ken secrets in the clear to not validating signatures. Once you open the do= or for someone to steal secrets, nothing else matters. My proposed language would be along the lines of "MUST use a secure channel= such as TLS/SSL or another mechanism providing the same protections". This= allows not using TLS/SSL when the environment provides the same protection= s some other way. EHL From jpanzer@google.com Sat Jan 9 10:31:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BBCC3A67FE for ; Sat, 9 Jan 2010 10:31:04 -0800 (PST) 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 6c+GqSLk+Dst for ; Sat, 9 Jan 2010 10:31:03 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id ECB623A677C for ; Sat, 9 Jan 2010 10:31:02 -0800 (PST) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o09IUwQG025607 for ; Sat, 9 Jan 2010 18:30:59 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1263061859; bh=UPOV+uq1dz2ePjAfI/4BGnNJPjY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=RCBpxsuLFpqeMOKBxeHxfQt2wQWUqzPbhQjjIJVGmRVBbupJR5n9qDD9RBVK9/VO8 jq3SwkO7lFhhlJa6hkQDQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=kLID7ML3BJn/lsa7kq5p6csymcG0KLNOvBl0/5REZne2EZnQsC4M4mnf4k9CCXRqg PDBKW/zvISnObNZju6tag== Received: from pwj2 (pwj2.prod.google.com [10.241.219.66]) by kpbe17.cbf.corp.google.com with ESMTP id o09IUvV2027435 for ; Sat, 9 Jan 2010 10:30:57 -0800 Received: by pwj2 with SMTP id 2so643463pwj.34 for ; Sat, 09 Jan 2010 10:30:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.54.12 with SMTP id c12mr3932368waa.81.1263061856670; Sat, 09 Jan 2010 10:30:56 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343787F341B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343787F3416B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343787F341B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 9 Jan 2010 10:30:56 -0800 Message-ID: From: John Panzer To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@googlegroups.com" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 1.0 PLAINTEXT without SSL/TLS X-BeenThere: oauth@ietf.org X-Mailman-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 Jan 2010 18:31:04 -0000 On Saturday, January 9, 2010, Eran Hammer-Lahav wrote= : > Hi John, > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of John Kemp >> Sent: Saturday, January 09, 2010 4:43 AM > >> What is the actual reasoning behind this change? I don't understand why = we >> would suddenly now decide to make some whole class of implementations >> non-conforming, even if there were only few deployments? > > I have come to the conclusion that arguments against requiring a secure c= hannel during some portions of the protocols are irrelevant. We have been m= aking the case that some environments will not be able to deploy OAuth if S= SL/TLS is requires, but we should put that claim under the same practical s= crutiny as other requirements we consider. I did a quick survey of existing= implementations and every single one uses HTTPS for obtaining tokens and f= or PLAINTEXT requests. > > If someone if going to write internal implementations, they are free to c= hange the protocol as they see fit. In such cases interop is more influence= d by the internal nature of the system than the specification. But I can't = come up with a single reason why we should allow, by making it a SHOULD, to= implement OAuth in such an obviously insecure way (in an IETF RFC). > > My argument is that there is little practical difference between sending = token secrets in the clear to not validating signatures. Once you open the = door for someone to steal secrets, nothing else matters. > > My proposed language would be along the lines of "MUST use a secure chann= el such as TLS/SSL or another mechanism providing the same protections". Th= is allows not using TLS/SSL when the environment provides the same protecti= ons some other way. > (Such as a vpn for example.) +1. > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From john@jkemp.net Sat Jan 9 17:46:53 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E6F3A67FA for ; Sat, 9 Jan 2010 17:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06rHgu-CdaJz for ; Sat, 9 Jan 2010 17:46:52 -0800 (PST) Received: from outbound-mail-08.bluehost.com (outbound-mail-08.bluehost.com [69.89.17.208]) by core3.amsl.com (Postfix) with SMTP id 7FF573A6407 for ; Sat, 9 Jan 2010 17:46:52 -0800 (PST) Received: (qmail 26996 invoked by uid 0); 10 Jan 2010 01:46:50 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy1.bluehost.com with SMTP; 10 Jan 2010 01:46:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=JWnPhPvDUE+Gt4N/PWCdrszcqGorIs/gatZDRACtfpX3MGDl/OGxCxy95G2ALQyNniz+PjH1IKH88bEseSl+cSHUpjK7EG97xTDPwtjOt+ubDx1rJElL5Pu/EmvYJ0BS; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.103]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NTmtF-0001Lw-PX; Sat, 09 Jan 2010 18:46:50 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343787F341B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 9 Jan 2010 20:46:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <965D3864-CA25-4097-9383-C839897378F9@jkemp.net> References: <90C41DD21FB7C64BB94121FBBC2E72343787F3416B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343787F341B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: oauth@googlegroups.com X-Mailer: Apple Mail (2.1077) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] [oauth] OAuth 1.0 PLAINTEXT without SSL/TLS X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jan 2010 01:46:53 -0000 Hey Eran! On Jan 9, 2010, at 12:12 PM, Eran Hammer-Lahav wrote: [...] (sure, agreed) > My proposed language would be along the lines of "MUST use a secure = channel such as TLS/SSL or another mechanism providing the same = protections". This allows not using TLS/SSL when the environment = provides the same protections some other way. Your wording looks good to me. Cheers, - johnk >=20 > EHL >=20 > --=20 > You received this message because you are subscribed to the Google = Groups "OAuth" group. > To post to this group, send email to oauth@googlegroups.com. > To unsubscribe from this group, send email to = oauth+unsubscribe@googlegroups.com. > For more options, visit this group at = http://groups.google.com/group/oauth?hl=3Den. >=20 >=20 From john@johnpanzer.com Fri Jan 8 18:07:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91BBE3A691A for ; Fri, 8 Jan 2010 18:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EJuWw+2H9LQ for ; Fri, 8 Jan 2010 18:07:26 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id A20E13A6830 for ; Fri, 8 Jan 2010 18:07:23 -0800 (PST) Received: by yxe4 with SMTP id 4so18521862yxe.32 for ; Fri, 08 Jan 2010 18:07:18 -0800 (PST) Received: by 10.150.164.18 with SMTP id m18mr30269ybe.87.1263002838274; Fri, 08 Jan 2010 18:07:18 -0800 (PST) Received: from ?192.168.1.100? (adsl-70-231-245-29.dsl.snfc21.sbcglobal.net [70.231.245.29]) by mx.google.com with ESMTPS id 9sm8193177ywe.41.2010.01.08.18.07.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 Jan 2010 18:07:16 -0800 (PST) Sender: John Panzer Message-ID: <4B47E4D4.1020501@acm.org> Date: Fri, 08 Jan 2010 18:07:16 -0800 From: John Panzer User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: oauth@googlegroups.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070100010804060509000702" X-Mailman-Approved-At: Sun, 10 Jan 2010 18:18:00 -0800 Cc: OAuth WG , oauth-wrap-wg@googlegroups.com Subject: Re: [OAUTH-WG] [oauth] Talking about what's up with OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jpanzer@acm.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 02:07:27 -0000 This is a multi-part message in MIME format. --------------070100010804060509000702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is a great summary from Chris, Eran, Dick, and David. Thanks guys! David Recordon wrote: > Sorry for emailing across a few lists, but this morning Chris Messina, > Dick Hardt, and I wrote a post on O'Reilly Radar talking about the > successes of OAuth 1.0a, the introduction of WRAP, and where we think > there is consensus to build OAuth 2.0. I might be biased, but it's > worth a read. ;) > > http://radar.oreilly.com/2010/01/whats-going-on-with-oauth.html > > --David > > ------------------------------------------------------------------------ > > -- > You received this message because you are subscribed to the Google > Groups "OAuth" group. > To post to this group, send email to oauth@googlegroups.com. > To unsubscribe from this group, send email to > oauth+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/oauth?hl=en. --------------070100010804060509000702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is a great summary from Chris, Eran, Dick, and David. Thanks guys!

David Recordon wrote:

Sorry for emailing across a few lists, but this morning Chris Messina, Dick Hardt, and I wrote a post on O'Reilly Radar talking about the successes of OAuth 1.0a, the introduction of WRAP, and where we think there is consensus to build OAuth 2.0. I might be biased, but it's worth a read. ;)

http://radar.oreilly.com/2010/01/whats-going-on-with-oauth.html

--David

--
You received this message because you are subscribed to the Google Groups "OAuth" group.
To post to this group, send email to oauth@googlegroups.com.
To unsubscribe from this group, send email to oauth+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth?hl=en.

--------------070100010804060509000702-- From eran@hueniverse.com Wed Jan 13 16:53:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1123A67F5 for ; Wed, 13 Jan 2010 16:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z4X3Q1Nwhb4 for ; Wed, 13 Jan 2010 16:53:45 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 194C53A682E for ; Wed, 13 Jan 2010 16:53:45 -0800 (PST) Received: (qmail 3602 invoked from network); 14 Jan 2010 00:53:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jan 2010 00:53:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 13 Jan 2010 17:53:41 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 13 Jan 2010 17:53:39 -0700 Thread-Topic: Setting Course Thread-Index: AcqUtAJ5nis0ujudxEKkwnxDgZdO7Q== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Setting Course X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Jan 2010 00:53:46 -0000 I think the goal of the next two months is to produce two semi-stable draft= s covering the two parts of the protocol: 1. Authentication - how to make authenticated requests / signed messages using token credentials. This will be based on my token auth draft [1] as a starting point. There are a few open issues to decide based on feedback received from Panzer and Eaton which I will post about shortly. 2. Authorization - how to obtain a set of token credentials using web redirection and other flows introduced by WRAP. This will be a new draft using the web-delegation draft [2] skeleton and the flows in WRAP section 5 [3]. There are many open issues to decide, starting with which flows to keep, which to move to an extension, and if there are additional ones to add. These drafts will be locked before the WG meeting to allow review and will be discussed at the meeting. We will also discuss any charter changes required to accommodate the drafts. This approach will allow us to focus on the work and worry about the charter at the meeting. This will ensure we ground the process in actual technical consensus. Comments? EHL [1] http://tools.ietf.org/html/draft-hammer-http-token-auth [2] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation [3] http://bit.ly/oauth-wrap From stpeter@stpeter.im Wed Jan 13 18:17:51 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D869C3A6839 for ; Wed, 13 Jan 2010 18:17:51 -0800 (PST) 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 dfBa3sWfcJdb for ; Wed, 13 Jan 2010 18:17:50 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 35F723A67E9 for ; Wed, 13 Jan 2010 18:17:50 -0800 (PST) Received: from squire.local (dsl-175-253.dynamic-dsl.frii.net [216.17.175.253]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C05D940D1C for ; Wed, 13 Jan 2010 19:17:46 -0700 (MST) Message-ID: <4B4E7ECA.30803@stpeter.im> Date: Wed, 13 Jan 2010 19:17:46 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090008000001000104040501" Subject: Re: [OAUTH-WG] Setting Course X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Jan 2010 02:17:52 -0000 This is a cryptographically signed message in MIME format. --------------ms090008000001000104040501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/13/10 5:53 PM, Eran Hammer-Lahav wrote: > I think the goal of the next two months is to produce two semi-stable d= rafts > covering the two parts of the protocol: >=20 > 1. Authentication - how to make authenticated requests / signed message= s > using token credentials. This will be based on my token auth draft [1] = as a > starting point. There are a few open issues to decide based on feedback= > received from Panzer and Eaton which I will post about shortly. >=20 > 2. Authorization - how to obtain a set of token credentials using web > redirection and other flows introduced by WRAP. This will be a new draf= t > using the web-delegation draft [2] skeleton and the flows in WRAP secti= on 5 > [3]. There are many open issues to decide, starting with which flows to= > keep, which to move to an extension, and if there are additional ones t= o > add. >=20 > These drafts will be locked before the WG meeting to allow review and w= ill > be discussed at the meeting. We will also discuss any charter changes > required to accommodate the drafts. This approach will allow us to focu= s on > the work and worry about the charter at the meeting. This will ensure w= e > ground the process in actual technical consensus. That approach sounds quite reasonable. Two comments: a. In my opinion the scenarios are not limited to what has been introduced by the WRAP discussions, and I have been encouraging folks to submit I-Ds that document additional scenarios as input to our understanding of the problem space (the WRAP authors will submit their work soon, as well). b. Once we have a clear grasp of the problem space, we'll be able to make longer-lasting progress on solutions. As you have outlined, at a high level the solutions are how to make authenticated requests and how to obtain credentials for making such requests, but it seems to me that there's still quite a bit of work to be done in figuring out what's "core" to those solutions and what needs to go in various extensions. Blaine and I will send out a rough agenda tomorrow for our first conference call on the 21st. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090008000001000104040501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDExNDAyMTc0NlowIwYJKoZIhvcNAQkEMRYEFC0whJ/Nn9OuoyCKahp4 SIHcyhyqMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEACL3sT7UTBz1hL9WwCxWCZPgzNb4N8zz/BMHT2XKi hl4mhYD2cg2ooQ6ZxyLJWNBKnsZbwg2yXxlNVTJNiunO0gSgbZX/qwTiVIv95Vlahqcxmmvw rjogO7eqZohFHLfrhs1nLyLvrrtVhySujWNs6Zjxyt18anGJPop0LYQ9IqKgpS+COOmJT1xO vyKCUmvG8OkQ/UDFvDMaTN5SdTgVo2/r55CCnfwYFNK0AxFNguydMZQXetb19cV339KFMV2o xK7XKcEB9+KygwabpMWMMUcng7ZtncXoj9PGPHmvTQBzaWocjlc51PCD998GhHUAWLs061We /wgxWcs7ipo4OwAAAAAAAA== --------------ms090008000001000104040501-- From eran@hueniverse.com Wed Jan 13 21:41:02 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990343A67E3 for ; Wed, 13 Jan 2010 21:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 bZGMGc8suWjh for ; Wed, 13 Jan 2010 21:41:01 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8109F3A67A2 for ; Wed, 13 Jan 2010 21:41:01 -0800 (PST) Received: (qmail 5385 invoked from network); 14 Jan 2010 05:40:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jan 2010 05:40:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 13 Jan 2010 22:40:58 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 13 Jan 2010 22:40:55 -0700 Thread-Topic: Request Signing vs. API Signing vs. Message Signing Thread-Index: AcqU3CPuwCqeIdaGREGtBH68H2236w== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Request Signing vs. API Signing vs. Message Signing X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Jan 2010 05:41:02 -0000 Authentication Open Question #1: What to sign? OAuth Core 1.0 was designed to sign API requests made using common form-encoded formats. The main component of the 1.0 signature base string are the parameters. The host and HTTP methods are important but were never the focus on the signed content. draft-hammer-oauth does not change the process but does describe the proces= s very differently, changing the focus form signing API requests and parameters to signing HTTP requests (partially). draft-hammer-http-token-auth takes this approach a step further and focuses on signing the raw HTTP request components, completely ignoring their meaning as used by API calls. The end result is very similar but the differences are important. Brian Eaton proposed [1] an alternative approach to sign messages instead o= f API calls or HTTP request. In his proposal, the HTTP request (or API call based on your perspective) in transformed into a message (in his case using a JSON-based format) which is then signed. This additional layer of abstraction allows the use of the method with other transports or use cases in which parameters are not sent in the request URI or body. QUESTION: Do you prefer: A. Directly processing the HTTP request into a base string for signing (draft-hammer-oauth style). B. Treating the request as an API call with form-encoded parameters (OAuth 1.0 style). C. Converting the request into a normalized message and signing that (Eaton style). EHL [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00890.html From eran@hueniverse.com Wed Jan 13 21:51:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A493B3A67C0 for ; Wed, 13 Jan 2010 21:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 Y1YcIgIeqUVr for ; Wed, 13 Jan 2010 21:51:39 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D45EC3A6774 for ; Wed, 13 Jan 2010 21:51:39 -0800 (PST) Received: (qmail 14489 invoked from network); 14 Jan 2010 05:51:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jan 2010 05:51:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 13 Jan 2010 22:51:37 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 13 Jan 2010 22:51:34 -0700 Thread-Topic: Include Normalized Request with Raw Request Thread-Index: AcqU3aDNRQDuBUgzok2piVXruUYylg== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Include Normalized Request with Raw Request X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Jan 2010 05:51:40 -0000 Authentication Open Question #2: Should the normalized request be included with the request? In OAuth 1.0 the request is normalized into the signature base string by th= e client and the server. The base string itself is never sent with the request. Brian Eaton proposed [1] to include the signed string with the request, removing the need for the server to regenerate the normalized string, as well as allowing the client to use the included string to send additional (signed) information that is not part of the HTTP request. This is a significant departure from OAuth 1.0, but one that does call for an in-depth discussion. Some advantages to this approach are: - the server can easily verify what is being signed - the client can include additional parameters in the signed message - the request remains valid even if changed by proxies or other intermediaries Some disadvantages are: - the request is sent twice, once raw and once normalized - it adds another place to make mistakes and create security holes if the server uses the raw data without fully comparing it to the normalized (signed) data - since any server enforcing security will only use the data contained in the normalized portion, it will create a de-facto standard for API requests (not nearly as heavy as SOAP or WS-*) in which case the request itself is normalized before sending. QUESTIONS: How do people feel about this? What are some other advantaged an= d disadvantages of this approach? EHL [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00890.html From eran@hueniverse.com Wed Jan 13 22:05:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3413A68EB for ; Wed, 13 Jan 2010 22:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 VItJDlU464pZ for ; Wed, 13 Jan 2010 22:05:37 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C2F463A67C0 for ; Wed, 13 Jan 2010 22:05:37 -0800 (PST) Received: (qmail 16304 invoked from network); 14 Jan 2010 06:05:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Jan 2010 06:05:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 13 Jan 2010 23:05:35 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 13 Jan 2010 23:05:33 -0700 Thread-Topic: Allowing Secrets in the Clear Over Insecure Channels Thread-Index: AcqU35Tio7i1nAveE0qAPbWJT1POPA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Jan 2010 06:05:38 -0000 Authentication Open Question #3: Should require using TLS/SSL/secure channe= l for any request made without a signature? WRAP got a lot of attention (mostly negative) to how it sends requests without using signatures or a secure channel. WRAP only uses HTTPS for obtaining tokens but does not mandate (or even suggests) using HTTPS for making protected resources requests. Instead, WRAP recommends short lived tokens that must be refreshed (using HTTPS). In a recent thread [1] on this list we reach (very small) consensus that th= e OAuth 1.0 protocol should mandate HTTPS for the PLAINTEXT method. The community edition only recommends it. QUESTIONS: Are there any valid (such that will pass IETF security review scrutiny) reasons for allowing unsigned requests to be sent in the clear over an insecure channel? Are there use cases for this (regardless of their security properties)? EHL [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00951.html From eran@hueniverse.com Wed Jan 13 22:12:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67A3F3A689D for ; Wed, 13 Jan 2010 22:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 NSRrDob5MZUK for ; Wed, 13 Jan 2010 22:12:33 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id CD55D3A68F7 for ; Wed, 13 Jan 2010 22:12:32 -0800 (PST) Received: (qmail 32180 invoked from network); 14 Jan 2010 06:12:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jan 2010 06:12:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 13 Jan 2010 23:12:29 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre , OAuth WG Date: Wed, 13 Jan 2010 23:12:27 -0700 Thread-Topic: [OAUTH-WG] Setting Course Thread-Index: AcqUv8fKHeIrb0+ISPCjL5qivB7QVwAIMPdW Message-ID: In-Reply-To: <4B4E7ECA.30803@stpeter.im> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Setting Course X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Jan 2010 06:12:38 -0000 On 1/13/10 6:17 PM, "Peter Saint-Andre" wrote: >> These drafts will be locked before the WG meeting to allow review and wi= ll >> be discussed at the meeting. We will also discuss any charter changes >> required to accommodate the drafts. This approach will allow us to focus= on >> the work and worry about the charter at the meeting. This will ensure we >> ground the process in actual technical consensus. >=20 > That approach sounds quite reasonable. Two comments: >=20 > a. In my opinion the scenarios are not limited to what has been > introduced by the WRAP discussions, and I have been encouraging folks to > submit I-Ds that document additional scenarios as input to our > understanding of the problem space (the WRAP authors will submit their > work soon, as well). Exactly. That's why I asked if there are additional ones to add. But I thin= k it is important the people will read the WRAP scenarios before spending tim= e in writing new I-Ds to see if their *use-case* is already covered. If it is= , but is not solved to their satisfaction, I think that should be posted as feedback to the WRAP proposal and not as yet another I-D. > b. Once we have a clear grasp of the problem space, we'll be able to > make longer-lasting progress on solutions. As you have outlined, at a > high level the solutions are how to make authenticated requests and how > to obtain credentials for making such requests, but it seems to me that > there's still quite a bit of work to be done in figuring out what's > "core" to those solutions and what needs to go in various extensions. This is true for the authorization part, but I don't think it is true for the authentication part. On the authentication side I think we are very close to a proposal. I have followed up with a few open questions and will send more over the next few days. I think we can get the authentication part mostly done quickly, and then pu= t it aside to focus on the authorization, going back to make changes as limitations or issues are found based on the authorization experience. > Blaine and I will send out a rough agenda tomorrow for our first > conference call on the 21st. Great. I will not be able to attend but hopefully others will and report back with new ideas and feedback. EHL From jpanzer@google.com Wed Jan 13 22:30:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD843A690A for ; Wed, 13 Jan 2010 22:30:49 -0800 (PST) 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.001, 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 xRLC-M9XvDFn for ; Wed, 13 Jan 2010 22:30:48 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id A312E3A68FE for ; Wed, 13 Jan 2010 22:30:47 -0800 (PST) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o0E6Ug91020796 for ; Thu, 14 Jan 2010 06:30:43 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1263450643; bh=iLq1x2+db1a5CEn22fX2L2eWN68=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ezMMMk0gMe0poIaW5VtO5Bs7DM/14oEWtBlXhEQfh4OFKt/v6iY6Ddafo8tR2Fljj lGUpv5g4CQNDsuOl1XosA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=t+kJDzN59iJRyQxdXcR/rd+dmjTe2Eihod5bG33dyVBiKepTNvJaTlWe7hjMpAVrc D1Gfbu+bC1GSQCU/cupDw== Received: from pxi40 (pxi40.prod.google.com [10.243.27.40]) by kpbe18.cbf.corp.google.com with ESMTP id o0E6UfbB025697 for ; Wed, 13 Jan 2010 22:30:41 -0800 Received: by pxi40 with SMTP id 40so133268pxi.21 for ; Wed, 13 Jan 2010 22:30:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.243.14 with SMTP id q14mr251931wah.168.1263450641192; Wed, 13 Jan 2010 22:30:41 -0800 (PST) In-Reply-To: References: From: John Panzer Date: Wed, 13 Jan 2010 22:30:21 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64ca916a8d952047d1a06b3 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Jan 2010 06:30:49 -0000 --0016e64ca916a8d952047d1a06b3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 13, 2010 at 10:05 PM, Eran Hammer-Lahav wrote: > Authentication Open Question #3: Should require using TLS/SSL/secure > channel > for any request made without a signature? > > WRAP got a lot of attention (mostly negative) to how it sends requests > without using signatures or a secure channel. WRAP only uses HTTPS for > obtaining tokens but does not mandate (or even suggests) using HTTPS for > making protected resources requests. Instead, WRAP recommends short lived > tokens that must be refreshed (using HTTPS). > > In a recent thread [1] on this list we reach (very small) consensus that > the > OAuth 1.0 protocol should mandate HTTPS for the PLAINTEXT method. The > community edition only recommends it. > Actually, HTTPS or equivalent channel security was the consensus. > > QUESTIONS: Are there any valid (such that will pass IETF security review > scrutiny) reasons for allowing unsigned requests to be sent in the clear > over an insecure channel? Are there use cases for this (regardless of their > security properties)? There was also a discussion (initiated by Brian Eaton) regarding the combination of short lived token plus refresh, which should be dug up. > > EHL > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00951.html > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e64ca916a8d952047d1a06b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 13, 2010 at 10:05 PM, Eran Hamme= r-Lahav <eran@h= ueniverse.com> wrote:

Authentication Open Question #3: Should require using TLS/SSL/secure channe= l
for any request made without a signature?

WRAP got a lot of attention (mostly negative) to how it sends requests
without using signatures or a secure channel. WRAP only uses HTTPS for
obtaining tokens but does not mandate (or even suggests) using HTTPS for making protected resources requests. Instead, WRAP recommends short lived tokens that must be refreshed (using HTTPS).

In a recent thread [1] on this list we reach (very small) consensus that th= e
OAuth 1.0 protocol should mandate HTTPS for the PLAINTEXT method. The
community edition only recommends it.

A= ctually, HTTPS or equivalent channel security was the consensus.

= =A0

QUESTIONS: Are there any valid (such that will pass IETF security review scrutiny) reasons for allowing unsigned requests to be sent in the clear over an insecure channel? Are there use cases for this (regardless of their=
security properties)?

There was also a disc= ussion (initiated by Brian Eaton) regarding the combination of short lived = token plus refresh, which should be dug up. =A0

=A0

EHL

[1] http://www.ietf.org/mail-archive/web/oauth/current/= msg00951.html

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

--0016e64ca916a8d952047d1a06b3-- From balfanz@google.com Wed Jan 13 22:58:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FFFE3A68FE for ; Wed, 13 Jan 2010 22:58:45 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+HIBRqs-E5W for ; Wed, 13 Jan 2010 22:58:24 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 89F1F3A691C for ; Wed, 13 Jan 2010 22:58:23 -0800 (PST) Received: from spaceape24.eur.corp.google.com (spaceape24.eur.corp.google.com [172.28.16.76]) by smtp-out.google.com with ESMTP id o0E6wHuX009728 for ; Thu, 14 Jan 2010 06:58:17 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1263452299; bh=5I5Z1GrktvHJVv+7MTrmdhicfq0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ZpOlzdvm4Q1qjVdMYhYB53Hbse41wmAk/pir7ykLUdtelRV5tJryy7x1peiUfvPZV 50bWpKnXAndDzxudAGjAA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=WnjoRhxpZeYWYQGC13xSeWPKAVA9lR3vRZMK48STRenvrAYDOuXdda/SVBL7RWKXu BflsjSP3Mq3Iy9niw+Pjg== Received: from pxi34 (pxi34.prod.google.com [10.243.27.34]) by spaceape24.eur.corp.google.com with ESMTP id o0E6wDxd029387 for ; Wed, 13 Jan 2010 22:58:16 -0800 Received: by pxi34 with SMTP id 34so137417pxi.8 for ; Wed, 13 Jan 2010 22:58:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.3.4 with SMTP id f4mr307602wai.10.1263452295329; Wed, 13 Jan 2010 22:58:15 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Jan 2010 22:58:15 -0800 Message-ID: <60c552b81001132258v5745db2ck431c8f7134940878@mail.gmail.com> From: Dirk Balfanz To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64dd71a40f734047d1a6921 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Include Normalized Request with Raw Request X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Jan 2010 06:58:51 -0000 --0016e64dd71a40f734047d1a6921 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 13, 2010 at 9:51 PM, Eran Hammer-Lahav wrote: > Authentication Open Question #2: Should the normalized request be included > with the request? > > In OAuth 1.0 the request is normalized into the signature base string by > the > client and the server. The base string itself is never sent with the > request. Brian Eaton proposed [1] to include the signed string with the > request, removing the need for the server to regenerate the normalized > string, as well as allowing the client to use the included string to send > additional (signed) information that is not part of the HTTP request. > > This is a significant departure from OAuth 1.0, but one that does call for > an in-depth discussion. > > Some advantages to this approach are: > > - the server can easily verify what is being signed > - the client can include additional parameters in the signed message > - the request remains valid even if changed by proxies or other > intermediaries > This is the part I didn't get in Brian's original thread, either. Presumably, a request is valid only if the pieces in the normalized part and in the raw part somehow match. If an (untrusted) proxy changes the raw pieces, it destroys the request just like it would in normal OAuth, right? I don't buy that we need to move heaven and earth just because some people don't know how to put a signature base string together. If we believe that the "meddling proxy" use cases are important to support (i.e, we believe that a request modified by a third party should still carry the same authority as the unmodified request), then we should just drop signatures altogether and use bearer tokens. I don't see how getting rid of the signature base string helps. Dirk. Some disadvantages are: > > - the request is sent twice, once raw and once normalized > - it adds another place to make mistakes and create security holes if the > server uses the raw data without fully comparing it to the normalized > (signed) data > - since any server enforcing security will only use the data contained in > the normalized portion, it will create a de-facto standard for API requests > (not nearly as heavy as SOAP or WS-*) in which case the request itself is > normalized before sending. > > QUESTIONS: How do people feel about this? What are some other advantaged > and > disadvantages of this approach? > > > EHL > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00890.html > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e64dd71a40f734047d1a6921 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 13, 2010 at 9:51 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

Authentication Open Question #2: Should the normalized request be included<= br> with the request?

In OAuth 1.0 the request is normalized into the signature base string by th= e
client and the server. The base string itself is never sent with the
request. Brian Eaton proposed [1] to include the signed string with the
request, removing the need for the server to regenerate the normalized
string, as well as allowing the client to use the included string to send additional (signed) information that is not part of the HTTP request.

This is a significant departure from OAuth 1.0, but one that does call for<= br> an in-depth discussion.

Some advantages to this approach are:

- the server can easily verify what is being signed
- the client can include additional parameters in the signed message
- the request remains valid even if changed by proxies or other
intermediaries

This is the part I didn&= #39;t get in Brian's original thread, either. Presumably, a request is = valid=A0only=A0if the pieces in the normalized part and in the raw part som= ehow match. If an (untrusted) proxy changes the raw pieces, it destroys the= request just like it would in normal OAuth, right?

=A0

I don't buy that we need to move heaven and earth ju= st because some people don't know how to put a signature base string to= gether.=A0

If we believe that the "meddling p= roxy" use cases are important to support (i.e, we believe that a reque= st modified by a third party should still carry the same authority as the u= nmodified request), then we should just drop signatures altogether and use = bearer tokens. I don't see how getting rid of the signature base string= helps.=A0

Dirk.

Some disadvantages are:

- the request is sent twice, once raw and once normalized
- it adds another place to make mistakes and create security holes if the server uses the raw data without fully comparing it to the normalized
(signed) data
- since any server enforcing security will only use the data contained in the normalized portion, it will create a de-facto standard for API requests=
(not nearly as heavy as SOAP or WS-*) in which case the request itself is normalized before sending.

QUESTIONS: How do people feel about this? What are some other advantaged an= d
disadvantages of this approach?

EHL

[1] http://www.ietf.org/mail-archive/web/oauth/current/= msg00890.html

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

--0016e64dd71a40f734047d1a6921-- From john@jkemp.net Thu Jan 14 03:35:15 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA903A6830 for ; Thu, 14 Jan 2010 03:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aguGE1bIJMyV for ; Thu, 14 Jan 2010 03:35:14 -0800 (PST) Received: from outbound-mail-124.bluehost.com (outbound-mail-124.bluehost.com [67.222.38.24]) by core3.amsl.com (Postfix) with SMTP id 2888E3A67E1 for ; Thu, 14 Jan 2010 03:35:13 -0800 (PST) Received: (qmail 6636 invoked by uid 0); 14 Jan 2010 11:35:10 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy4.bluehost.com with SMTP; 14 Jan 2010 11:35:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=uusAqjucI1dzexpWxXND6Vvec9aoeHXNKS/6oJjEg054hGiur73VgJnx1CiuH4IkKSh9cKGUNPXXVxODkHBShHwa7LUXCDW7e4+F0vzDGGmvq1Ki4zSY2/djikSyPRSj; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.103]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NVNyo-0007sh-Cl; Thu, 14 Jan 2010 04:35:10 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: Date: Thu, 14 Jan 2010 06:35:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5EE8B4A7-B176-48C7-ADE1-E4C3D037B1A4@jkemp.net> References: To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: OAuth WG Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Jan 2010 11:35:15 -0000 On Jan 14, 2010, at 1:05 AM, Eran Hammer-Lahav wrote: [...] >=20 > QUESTIONS: Are there any valid (such that will pass IETF security = review > scrutiny) reasons for allowing unsigned requests to be sent in the = clear > over an insecure channel? Are there use cases for this (regardless of = their > security properties)? I am still wavering on this.=20 I think that using a bearer token with short lifetime and one-time use = semantics (for example) is probably sufficient security for many = use-cases. And using TLS/SSL (or even just signing and verifying a = signed request) in all cases may provide too much performance overhead = for some of those cases.=20 In other words, I think that it's not only channel security we need to = consider, but a combination of other measures that would, in some cases, = obviate the need for TLS. Regards, - johnk From romeda@gmail.com Thu Jan 14 04:10:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051233A672F for ; Thu, 14 Jan 2010 04:10:40 -0800 (PST) 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 fNZOXBdN9vjF for ; Thu, 14 Jan 2010 04:10:37 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 78C1D3A63EC for ; Thu, 14 Jan 2010 04:10:37 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e21so142457fga.13 for ; Thu, 14 Jan 2010 04:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=rZx4RgpAH49k0P9WvT/4f21IhbEOpAvKnz80sCHKOaA=; b=Zk138W4W2KFIvqSJuKC9vn2P5Q/uTVXPnAUMOpXhgzNaVL/xTJ3xXzVn33uktcS5pw m9Z7WVnBk6J7DhyO1wgPvDjksyWR1+j1WKw+Y3wrl/0aCpa0OyrAIx9Vw/j/upsOAYtj nJVs7BfstWvfGJfzubrE9aLC2aVyoP/7IoMlk= 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 :content-type:content-transfer-encoding; b=IsE/3W+tGbiNp6SdTRkzK8QiirrwnkrkOayeIjtZGytcoLOtTKH6DPD2JnlX0p+ESk nXaQqPveZJbczvhLURaxOJhVFOzsLc9EIyoODoHvzgxknMP0CqppwXzYJIKjlQi1CKVY /0IKetuSLzhdQGdyXNOGulntoYKbt+6ElKNxI= MIME-Version: 1.0 Received: by 10.103.79.28 with SMTP id g28mr320713mul.67.1263471031114; Thu, 14 Jan 2010 04:10:31 -0800 (PST) In-Reply-To: <5EE8B4A7-B176-48C7-ADE1-E4C3D037B1A4@jkemp.net> References: <5EE8B4A7-B176-48C7-ADE1-E4C3D037B1A4@jkemp.net> From: Blaine Cook Date: Thu, 14 Jan 2010 12:10:11 +0000 Message-ID: To: OAuth WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Jan 2010 12:10:40 -0000 OAuth WRAP is very similar to cookies as deployed by major vendors. Google has just switched to HTTPS-by-default for all GMail sessions[1], and my understanding (per [2]) is that access to authenticated sessions (i.e., full GMail or Google Docs access versus just displaying "bob@gmail.com" on the page) is always negotiated with a secure cookie. Thus, Google has made decisions internally to secure the equivalent of both the Refresh and the Bearer token, short-lived assurances aside. We're also entering an age where we have enough computing power to *factor* RSA-1024 in non-infinite-time; handheld devices that are realistically expected to use these protocols have sufficient computing power and battery life to encrypt HTTP requests and decrypt the responses (my phone already does this for all Twitter and email requests; yours probably does, too). As such, I can't see how *not* requiring SSL for unsigned requests could pass muster at an IETF security review. [1] http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.ht= ml [2] http://googleonlinesecurity.blogspot.com/2009/06/https-security-for-web= -applications.html 2010/1/14 John Kemp : > > On Jan 14, 2010, at 1:05 AM, Eran Hammer-Lahav wrote: > > [...] >> >> QUESTIONS: Are there any valid (such that will pass IETF security review >> scrutiny) reasons for allowing unsigned requests to be sent in the clear >> over an insecure channel? Are there use cases for this (regardless of th= eir >> security properties)? > > I am still wavering on this. > > I think that using a bearer token with short lifetime and one-time use se= mantics (for example) is probably sufficient security for many use-cases. A= nd using TLS/SSL (or even just signing and verifying a signed request) in a= ll cases may provide too much performance overhead for some of those cases. > > In other words, I think that it's not only channel security we need to co= nsider, but a combination of other measures that would, in some cases, obvi= ate the need for TLS. > > Regards, > > - johnk > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From romeda@gmail.com Thu Jan 14 04:45:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BF803A68F9 for ; Thu, 14 Jan 2010 04:45:25 -0800 (PST) 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 jI-qnKMpCO1M for ; Thu, 14 Jan 2010 04:45:24 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 3BAA63A687B for ; Thu, 14 Jan 2010 04:45:23 -0800 (PST) Received: by fxm7 with SMTP id 7so2847702fxm.28 for ; Thu, 14 Jan 2010 04:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=smRTMsnAfmOldZ6BIh9JLty7BUDJMXY7kbDU5yNoGKo=; b=dmlW5jQ6WQ/h48Csy4ZJVpJxzZQ3mKPHCGFRImhwzDVlTpmwb6Syh5HdaDvM/VpsRd s0YFXWYVEmM7S9H97EeSPBlwsQvgSTHr93M82vfM86+KR/9qqIDSGoCpV96+LfNu4UcT nNtno0OyMPHqmiLGZVzeWTtpPaQ2NQtki5z8k= 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=Ar6cqV1ZIPWyCdVPcTPvFFC2t6CDtofStQpkUOVcfCGYMPOS2SqNEfrIbLenJSFuUK G/a9g3TWQbQO/uH+9fSz5Xt2bVZPCmAyew9vsMvFjlH5x8OWMw574tq+ggCYLCQUEMW8 0Yh8Ms2j1qrVD8YBoCDOWBhj6Fn2R11lx9RA0= MIME-Version: 1.0 Received: by 10.103.76.37 with SMTP id d37mr345148mul.105.1263473118122; Thu, 14 Jan 2010 04:45:18 -0800 (PST) In-Reply-To: References: From: Blaine Cook Date: Thu, 14 Jan 2010 12:44:58 +0000 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Cc: OAuth WG Subject: Re: [OAUTH-WG] Request Signing vs. API Signing vs. Message Signing X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Jan 2010 12:45:25 -0000 2010/1/14 Eran Hammer-Lahav : > QUESTION: Do you prefer: > > A. Directly processing the HTTP request into a base string for signing > (draft-hammer-oauth style). > B. Treating the request as an API call with form-encoded parameters (OAuth > 1.0 style). > C. Converting the request into a normalized message and signing that (Eaton > style). For protocol independence of presenting a token + signed message, (C). I wonder if John Panzer's recent proposal for Salmon [1] could be adapted to use (C) elegantly? I think Salmon/PSHB is an interesting use-case for delegated authorization and subsequent authentication, and as such might be a good place to think about approaches like Brian's. b. [1] http://www.abstractioneer.org/2010/01/magic-signatures-for-salmon.html From romeda@gmail.com Thu Jan 14 04:57:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2CA13A659A for ; Thu, 14 Jan 2010 04:57:13 -0800 (PST) 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 Zlc7coXfKxVv for ; Thu, 14 Jan 2010 04:57:12 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 9E4F93A6873 for ; Thu, 14 Jan 2010 04:57:12 -0800 (PST) Received: by fxm5 with SMTP id 5so2873126fxm.29 for ; Thu, 14 Jan 2010 04:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=DonXV8vOJghKuuAxgmqmTF2G5UOQpZhVYWAWkUtaSEY=; b=WP9KEqImMLXrJ6TTaDreopTxzR+JVaYNPvnjr010sasX7eyW6A1iuWxx9iQMkQ5J7g kAS6zoNQHcpwsjQQZ+Hv5dOsQH6ARFLWyd5PKN0XtT9WhlV9K6Ae1DU0IY+zwDkpTkmL /4tiz8NRtQaLjsVn3fgXRjAPxa7FGv8bKB1Xk= 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 :content-type; b=jE8F0ZjzShhVtKQVs+Uob2n6Wh108Jwlmq2uDc1nsobR9E7uRMSoSpXced8iM+UlLl +e6h8nMhEvSbelnaWPpaNSml0INPcO6cu47Ruet6zm4OYm+kJ6zOmpHm06XbvkAWHfzi j+VBmU5oHr+jFE/Ky+irvYFK6t6XrhvdTwFBI= MIME-Version: 1.0 Received: by 10.103.79.28 with SMTP id g28mr342018mul.67.1263473826169; Thu, 14 Jan 2010 04:57:06 -0800 (PST) In-Reply-To:

--000e0cd72252db7513047d38e8c2-- From rbarnes@bbn.com Fri Jan 15 11:58:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7315A3A685F for ; Fri, 15 Jan 2010 11:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktb16Csuinl0 for ; Fri, 15 Jan 2010 11:58:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6ADBB3A67AB for ; Fri, 15 Jan 2010 11:58:30 -0800 (PST) Received: from ros-dhcp192-1-51-107.bbn.com ([192.1.51.107]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NVsJO-0005XV-C0; Fri, 15 Jan 2010 14:58:26 -0500 Message-Id: <8E6EDCB3-3EDE-4A2E-B29E-70FACF40BF0A@bbn.com> From: "Richard L. Barnes" To: John Panzer In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-17--337018778 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 15 Jan 2010 14:58:26 -0500 References: <5EE8B4A7-B176-48C7-ADE1-E4C3D037B1A4@jkemp.net> <4CD0B1FE-83DC-4C4F-9671-1A588F211A17@bbn.com> <5D0FB108-587F-485D-8FF1-6D256193C12C@xmlgrrl.com> <62BFE5680C037E4DA0B0A08946C0933DC486ED19@rrsmsx506.amr.corp.intel.com> <32D388A4-C38A-4A1B-9F2D-1EE183E1227C@bbn.com> X-Mailer: Apple Mail (2.936) Cc: OAuth WG Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Jan 2010 19:58:32 -0000 --Apple-Mail-17--337018778 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit If the issue is that the client doesn't *want* to do PLAINTEXT-NOTLS, then there is no interop issue -- the client and the server have different requirements, at a policy level. You can have a requirement for compliant implementations to implement the mode, but you can't force people to use it. This remains true even if you do have a algorithm negotiation mechanism. Two analogies: 1. HTTP: If I enter an HTTPS URI and and the server returns a 301 sending me to an HTTP URI, then I don't follow it to the insecure site in order to comply with HTTP (even though my browser usually does so automatically). 2. IPsec: If two IKE peers are trying to set up an IPsec security association, first one peer advertises the list of algorithms it's willing to use, then the second peer responds with the subset of those that it's willing to use. If the second peer doesn't like any of the advertised algorithms, then it says so, and the negotiation fails. --Richard On Jan 15, 2010, at 2:21 PM, John Panzer wrote: > On Fri, Jan 15, 2010 at 10:41 AM, Richard L. Barnes > wrote: > I would think not; it's a matter of the client's policy what > signatures it will issue, and the server's policy which it will > accept. > > That doesn't answer the interop question, though, which is the > interesting one from the standpoint of the spec. If there is no > requirement for a common minimal-subset then there is no guarantee > of interop between a random client and a random server that both > speak the same data protocol. Most use cases of OAuth have a custom > client for every data API so this isn't an issue, but that's not > necessarily the case, especially as new protocols start to depend on > OAuth for their security needs. > > > And in any case, OAuth doesn't have any in-band security > negotiation, so there's no way for the server to ask for a given set > of features (e.g., bearer tokens and no TLS) within the protocol. > > > See however https://groups.google.com/group/oauth-key-discovery for > a very needed extension that does add key discovery and rotation. > Even without that, the question is just punted to the out of band > documentation: Is a server allowed to support only bearer tokens > and no TLS for some use case? > > > > --Richard > > > > > On Jan 15, 2010, at 1:29 PM, John Panzer wrote: > >> I think the question at hand is: If a server says it wants to do >> bearer tokens and no TLS, is a client obligated to interop in order >> to claim spec compliance? >> >> -- >> John Panzer / Google >> jpanzer@google.com / abstractioneer.org / @jpanzer >> >> >> >> On Fri, Jan 15, 2010 at 10:01 AM, Hurliman, John > > wrote: >> +1 to this as well. Any implementation is free to deviate from the >> spec, at the risk of breaking interoperability. >> >> John >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> Behalf Of John Panzer >> Sent: Friday, January 15, 2010 8:43 AM >> To: Eve Maler >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure >> Channels >> >> +1 to MUST implement TLS on both sides. >> >> I thought we were only discussing whether the server could decide to >> skip TLS for a particular use case. No? >> >> On Friday, January 15, 2010, Eve Maler wrote: >> > The points about matching security to use case are excellent. >> This is why I think we're maybe misinterpreting Eran's argument for >> MUST. It's not an argument from security alone ("we must always >> have highest security all the time"); it's an argument from >> interoperability of security features at Internet scale ("in the >> general/at-scale case, we should not accept deployed instances that >> do not support this important security feature"). >> > >> > On this basis, it's reasonable to argue for MUST for implementing >> TLS (with no weasel words about "or equivalent", since this isn't a >> testable protocol clause), for the broad ecosystem benefits. >> > >> > Eve >> > >> > On 15 Jan 2010, at 8:06 AM, John Kemp wrote: >> > >> >> On Jan 14, 2010, at 7:39 PM, Richard L. Barnes wrote: >> >> >> >>>> As such, I can't see how *not* requiring SSL for unsigned >> requests >> >>>> could pass muster at an IETF security review. >> >>> >> >>> Speaking as someone who does IETF security reviews ... :) >> >>> >> >>> If I were reviewing a document that defines an optional >> insecure mode of operation (in this case, operating without TLS), I >> would be looking for basically two things: (1) A discussion of the >> risks if the insecure mode is used, and (2) a motivation for why >> these risks might be acceptable in certain cases. This is in the >> spirit of "MUST=SHOULD+exception" -- if it's a SHOULD, you need to >> explain the exception. In this case, the risks (1) are pretty >> obvious: A passive observer can steal your password and use it to >> authenticate as you. The motivations (2) are what this thread is >> about. >> >>> >> >>> I would also observe that "MUST use TLS or equivalent" is >> actually the same as "SHOULD use TLS", since the "or equivalent" >> isn't really specified. >> >> >> >> Right. Which is why I'm currently OK with Eran's text either way >> as I think it allows bearer tokens with *any* other security >> protections, unless we specify exactly which security properties >> should be provided by the channel, vs. via other mechanisms. >> >> >> >> SAML's "confirmation method" is sort of the equivalent idea to >> what we've been talking about here (where the method could be >> "holder-of-key+a signature algorithm", "bearer" or something else) >> but we also haven't separated out security properties such as >> integrity or confidentiality for the purposes of this discussion. >> >> >> >>> (This is really obvious when you think about it from the >> perspective of an implementor: If you're going to cover the "or >> equivalent" cases, then you have to have be able to operate in non- >> TLS mode.) The "or equivalent" cases are the ones where not using >> TLS might be acceptable, i.e., the ones that should be cited as >> motivations (2) for allowing the non-secure mode. >> >>> >> >>> Taking the SECDIR hat off, it seems to me that there are some >> motivations appearing in this thread: >> >>> -- Appropriate key management (frequent key refresh) >> >>> -- Private trusted networks >> >>> -- John's observation that "URL+token" == "private URL" >> >>> So ISTM that "SHOULD use TLS" could be motivated here. >> >>> >> >>> (Now, all that said, it probably wouldn't hurt to have TLS as a >> "MUST implement" so that it's there if people want to use it.) >> >> >> >> +1 >> >> >> >> - johnk >> > >> > >> > Eve Maler >> > eve@xmlgrrl.com >> > http://www.xmlgrrl.com/blog >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> >> -- >> -- >> John Panzer / Google >> jpanzer@google.com / abstractioneer.org / @jpanzer >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > --Apple-Mail-17--337018778 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

If the issue is that the = client doesn't *want* to do PLAINTEXT-NOTLS, then there is no interop = issue -- the client and the server have different requirements, at a = policy level. You can have a requirement for compliant implementations = to implement the mode, but you can't force people to use it. This = remains true even if you do have a algorithm negotiation = mechanism.

Two analogies: =

1. HTTP: If I enter an HTTPS URI and and = the server returns a 301 sending me to an HTTP URI, then I don't = follow it to the insecure site in order to comply with HTTP (even though = my browser usually does so automatically).

2. = IPsec: If two IKE peers are trying to set up an IPsec security = association, first one peer advertises the list of algorithms it's = willing to use, then the second peer responds with the subset of those = that it's willing to use. If the second peer doesn't like any of = the advertised algorithms, then it says so, and the negotiation = fails.

--Richard

On Jan 15, 2010, at 2:21 PM, John Panzer = wrote:

On Fri, Jan 15, 2010 at 10:41 = AM, Richard L. Barnes <rbarnes@bbn.com> = wrote:

I would think not; it's a matter of the = client's policy what signatures it will issue, and the server's policy = which it will accept.

That doesn't = answer the interop question, though, which is the interesting one from = the standpoint of the spec. If there is no requirement for a = common minimal-subset then there is no guarantee of interop between a = random client and a random server that both speak the same data = protocol. Most use cases of OAuth have a custom client for every = data API so this isn't an issue, but that's not necessarily the case, = especially as new protocols start to depend on OAuth for their security = needs.

And in any case, = OAuth doesn't have any in-band security negotiation, so there's no way = for the server to ask for a given set of features (e.g., bearer tokens = and no TLS) within the protocol.
=

See = however https://group= s.google.com/group/oauth-key-discovery for a very needed extension = that does add key discovery and rotation. Even without that, the = question is just punted to the out of band documentation: Is a = server allowed to support only bearer tokens and no TLS for some use = case?

--Richard

On Jan = 15, 2010, at 1:29 PM, John Panzer wrote:

I think the question at hand is: If a server says it = wants to do bearer tokens and no TLS, is a client obligated to interop = in order to claim spec compliance?

--
John Panzer = / Google
jpanzer@google.com / abstractioneer.org / @jpanzer

=
On Fri, Jan 15, 2010 at 10:01 AM, = Hurliman, John <john.hurliman@intel.com> = wrote:
+1 to this as well. = Any implementation is free to deviate from the spec, at the risk of = breaking interoperability.

John
=

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John = Panzer
Sent: Friday, January 15, 2010 8:43 AM
To: Eve Maler
= Cc: OAuth WG
Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear = Over Insecure Channels

+1 to MUST implement TLS on both = sides.

I thought we were only discussing whether the server = could decide to
skip TLS for a particular use case. No?
=
On Friday, January 15, 2010, Eve Maler <eve@xmlgrrl.com> = wrote:
> The points about matching security to use case are = excellent. This is why I think we're maybe misinterpreting Eran's = argument for MUST. It's not an argument from security alone ("we = must always have highest security all the time"); it's an argument from = interoperability of security features at Internet scale ("in the = general/at-scale case, we should not accept deployed instances that do = not support this important security feature").
>
> On = this basis, it's reasonable to argue for MUST for implementing TLS (with = no weasel words about "or equivalent", since this isn't a testable = protocol clause), for the broad ecosystem benefits.
>
> = Eve
>
> On 15 Jan 2010, = at 8:06 AM, John Kemp wrote:
>
>> On Jan 14, 2010, at = 7:39 PM, Richard L. Barnes wrote:
>>
>>>> As = such, I can't see how *not* requiring SSL for unsigned requests
= >>>> could pass muster at an IETF security review.
= >>>
>>> Speaking as someone who does IETF security = reviews ... :)
>>>
>>> If I were = reviewing a document that defines an optional insecure mode of operation = (in this case, operating without TLS), I would be looking for basically = two things: (1) A discussion of the risks if the insecure mode is used, = and (2) a motivation for why these risks might be acceptable in certain = cases. This is in the spirit of "MUST=3DSHOULD+exception" -- if = it's a SHOULD, you need to explain the exception. In this case, = the risks (1) are pretty obvious: A passive observer can steal your = password and use it to authenticate as you. The motivations (2) = are what this thread is about.
>>>
>>> I = would also observe that "MUST use TLS or equivalent" is actually the = same as "SHOULD use TLS", since the "or equivalent" isn't really = specified.
>>
>> Right. Which is why I'm currently = OK with Eran's text either way as I think it allows bearer tokens with = *any* other security protections, unless we specify exactly which = security properties should be provided by the channel, vs. via other = mechanisms.
>>
>> SAML's "confirmation method" is = sort of the equivalent idea to what we've been talking about here (where = the method could be "holder-of-key+a signature algorithm", "bearer" or = something else) but we also haven't separated out security properties = such as integrity or confidentiality for the purposes of this = discussion.
>>
>>> (This is really obvious when = you think about it from the perspective of an implementor: If you're = going to cover the "or equivalent" cases, then you have to have be able = to operate in non-TLS mode.) The "or equivalent" cases are the = ones where not using TLS might be acceptable, i.e., the ones that should = be cited as motivations (2) for allowing the non-secure mode.
= >>>
>>> Taking the SECDIR hat off, it seems to me = that there are some motivations appearing in this thread:
= >>> -- Appropriate key management (frequent key refresh)
= >>> -- Private trusted networks
>>> -- John's = observation that "URL+token" =3D=3D "private URL"
>>> So = ISTM that "SHOULD use TLS" could be motivated here.
>>>
= >>> (Now, all that said, it probably wouldn't hurt to have TLS = as a "MUST implement" so that it's there if people want to use it.)
= >>
>> +1
>>
>> - johnk
>
= >
> Eve Maler
> eve@xmlgrrl.com
> http://www.xmlgrrl.com/blog
>
> = _______________________________________________
> OAuth mailing = list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
= >

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

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

= --Apple-Mail-17--337018778-- From stpeter@stpeter.im Fri Jan 15 13:42:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67FA3A6784 for ; Fri, 15 Jan 2010 13:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 lCVCPoIkM-fu for ; Fri, 15 Jan 2010 13:42:09 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DA2CE3A69A7 for ; Fri, 15 Jan 2010 13:42:03 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2CFE140D1C; Fri, 15 Jan 2010 14:42:00 -0700 (MST) Message-ID: <4B50E126.2070303@stpeter.im> Date: Fri, 15 Jan 2010 14:41:58 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: X-Enigmail-Version: 1.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050203000806020902060509" Cc: OAuth WG Subject: Re: [OAUTH-WG] Setting Course X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Jan 2010 21:42:10 -0000 This is a cryptographically signed message in MIME format. --------------ms050203000806020902060509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/13/10 11:12 PM, Eran Hammer-Lahav wrote: >=20 > On 1/13/10 6:17 PM, "Peter Saint-Andre" wrote: >=20 >>> These drafts will be locked before the WG meeting to allow review and= will >>> be discussed at the meeting. We will also discuss any charter changes= >>> required to accommodate the drafts. This approach will allow us to fo= cus on >>> the work and worry about the charter at the meeting. This will ensure= we >>> ground the process in actual technical consensus. >> >> That approach sounds quite reasonable. Two comments: >> >> a. In my opinion the scenarios are not limited to what has been >> introduced by the WRAP discussions, and I have been encouraging folks = to >> submit I-Ds that document additional scenarios as input to our >> understanding of the problem space (the WRAP authors will submit their= >> work soon, as well). >=20 > Exactly. That's why I asked if there are additional ones to add. But I = think > it is important the people will read the WRAP scenarios before spending= time > in writing new I-Ds to see if their *use-case* is already covered. If i= t is, > but is not solved to their satisfaction, I think that should be posted = as > feedback to the WRAP proposal and not as yet another I-D. Indeed. My sense from talking with some folks one-on-one is that there are additional scenarios, and I'm encouraging those people to contribute scenarios on the list or via I-D. >> b. Once we have a clear grasp of the problem space, we'll be able to >> make longer-lasting progress on solutions. As you have outlined, at a >> high level the solutions are how to make authenticated requests and ho= w >> to obtain credentials for making such requests, but it seems to me tha= t >> there's still quite a bit of work to be done in figuring out what's >> "core" to those solutions and what needs to go in various extensions. >=20 > This is true for the authorization part, but I don't think it is true f= or > the authentication part. On the authentication side I think we are very= > close to a proposal. I have followed up with a few open questions and w= ill > send more over the next few days. >=20 > I think we can get the authentication part mostly done quickly, and the= n put > it aside to focus on the authorization, going back to make changes as > limitations or issues are found based on the authorization experience. Iterative development is good. :) That sounds quite reasonable. >> Blaine and I will send out a rough agenda tomorrow for our first >> conference call on the 21st. Sorry we haven't sent it yet -- we're working on it now... > Great. I will not be able to attend but hopefully others will and repor= t > back with new ideas and feedback. Sorry to hear that. Hopefully you'll be able to join future calls. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050203000806020902060509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDExNTIxNDE1OFowIwYJKoZIhvcNAQkEMRYEFC12eCLCUG5Wwo95vexn 8CUxyCg/MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAIx3yW4zSXRbLRfgbOhZk3FYON3gDjj9cr2xUbrnK QQoZuncOhOK9xHZX/gv+YZVJzCfY5lporSNBSCnyOFC/5DWjO2Xhqfrhl2DTfkd85n5RyA7C SGbR61ycyY3P6LtF84mj/4RPKy7ng+B+lDkjDz23gadl77m4gUyrGeokr1RrQoaayGlM9Aqz GbH0j1O5BFFmXsMSwKxGOSf8Teueyuott4Ecn6vsbeAI5CD8MA0nsQ2Olg0KK+web+B7HgGf 0oNw1sd+3ISHpLsG6nN8JhRECDyh/wvXqHXrXnYOG7zX+yOkMcVcTIZ+TQ3KU4VZ5FgLYDKu teDydEzOq7juFwAAAAAAAA== --------------ms050203000806020902060509-- From eran@hueniverse.com Fri Jan 15 13:42:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5AF83A69A0 for ; Fri, 15 Jan 2010 13:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlNnGhlDkcJO for ; Fri, 15 Jan 2010 13:42:09 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 89E4C3A6986 for ; Fri, 15 Jan 2010 13:42:04 -0800 (PST) Received: (qmail 1960 invoked from network); 15 Jan 2010 21:42:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jan 2010 21:42:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 15 Jan 2010 14:41:56 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Fri, 15 Jan 2010 14:41:52 -0700 Thread-Topic: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels Thread-Index: AcqV+5MrmGX6hyjWR6mWqUErIJtuNQAL/ltu 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Jan 2010 21:42:11 -0000 On 1/15/10 7:58 AM, "John Kemp" wrote: > When I look at what is possible in the offline world, I would ask - would= you > require that movie theatre tickets bought in advance were encrypted in > transport between the person who bought the ticket and the receptionist a= t the > cinema? What if the person drops her ticket and it's picked up by someone > else? The risk of someone dropping his ticket is low, so we don't bother = to > secure it (of course, I haven't been to a city movie theatre in years so > perhaps you need to show ID even to see a movie these days -- I hope not = ;) Of > course, the person who _does_ drop his ticket will be mad when he gets to= the > movie theatre, but probably not too mad. The system has worked quite well > without any real security. We might add more security, but it would, even > today, probably be hard to justify the cost. I don't think this is a fair comparison. Stealing a movie ticket is very hard, and punishable but fines and prison time (potentially federal is captured in transit via US Mail). On the other hand, capturing bearer token= s while sitting at a Starbucks using nothing more than a laptop with a WiFi card is trivial. =20 > Yes, those things change over time, but having a sliding scale of securit= y is > a good thing, not a bad thing - and that is already allowed by OAuth toda= y, > (TLS/SSL+PLAINTEXT, RSA-SHA1, HMAC-SHA1, PLAINTEXT) and will continue eve= n if > you remove PLAINTEXT from the list. We are creating web standards, not just generic technologies. I don't want to find *any* PLAINTEXT implementation on the web, but don't care if someon= e uses it on their own private network. But if that's what they are doing, they are free to drop TLS/SSL requirement anyway because they control the environment. Since we are talking about one word, MUST vs. SHOULD, I think we should start with MUST and continue having this discussion when we have more piece= s of the puzzle in place. EHL From eran@hueniverse.com Fri Jan 15 13:50:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12AA33A6784 for ; Fri, 15 Jan 2010 13:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 IlibTOrx0qkE for ; Fri, 15 Jan 2010 13:50:03 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 5D8F73A67AE for ; Fri, 15 Jan 2010 13:50:03 -0800 (PST) Received: (qmail 10034 invoked from network); 15 Jan 2010 21:50:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jan 2010 21:50:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 15 Jan 2010 14:50:00 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Fri, 15 Jan 2010 14:49:56 -0700 Thread-Topic: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels Thread-Index: AcqWEMw8D0UI7LdiRxOlNXf8O1OdfgAG+Dbu 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Jan 2010 21:50:04 -0000 On 1/15/10 10:29 AM, "John Panzer" wrote: > I think the question at hand is: =A0If a server says it wants to do beare= r > tokens and no TLS, is a client obligated to interop in order to claim spe= c > compliance? Its a tricky question because HTTPS is not a parameter or extension you negotiate. It is dictated by the URI of the protected resource you are trying to access, and clients should never assume that the http:// resource is the same as the https:// resource, just with more/less security. EHL From john@jkemp.net Fri Jan 15 14:02:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04C93A6880 for ; Fri, 15 Jan 2010 14:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prr7e7iB3JVc for ; Fri, 15 Jan 2010 14:02:47 -0800 (PST) Received: from outbound-mail-01.bluehost.com (outbound-mail-01.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id CC5E53A67FD for ; Fri, 15 Jan 2010 14:02:46 -0800 (PST) Received: (qmail 29754 invoked by uid 0); 15 Jan 2010 22:02:43 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy4.bluehost.com with SMTP; 15 Jan 2010 22:02:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=OoJTSc8vy6b4zCL8K03h30uot2j+Tis0Ptw/OQ3VsplzB7o75cSd/GkySaoIk8qExhbu12v+HDA+coPl3NCz2/GjRY0AolJzGXX630qEkT4zspRAMLs+c1DUUzFPBmJ9; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.103]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NVuFf-0005XD-C2; Fri, 15 Jan 2010 15:02:43 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: Date: Fri, 15 Jan 2010 17:02:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: OAuth WG Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Jan 2010 22:02:47 -0000 Hello Eran, On Jan 15, 2010, at 4:41 PM, Eran Hammer-Lahav wrote: >=20 > On 1/15/10 7:58 AM, "John Kemp" wrote: >=20 >> When I look at what is possible in the offline world, I would ask - = would you >> require that movie theatre tickets bought in advance were encrypted = in >> transport between the person who bought the ticket and the = receptionist at the >> cinema? What if the person drops her ticket and it's picked up by = someone >> else? The risk of someone dropping his ticket is low, so we don't = bother to >> secure it (of course, I haven't been to a city movie theatre in years = so >> perhaps you need to show ID even to see a movie these days -- I hope = not ;) Of >> course, the person who _does_ drop his ticket will be mad when he = gets to the >> movie theatre, but probably not too mad. The system has worked quite = well >> without any real security. We might add more security, but it would, = even >> today, probably be hard to justify the cost. >=20 > I don't think this is a fair comparison. Stealing a movie ticket is = very > hard, and punishable but fines and prison time (potentially federal is > captured in transit via US Mail). The point is that the overall system makes the cost of providing any = extra security not very worthwhile, as most thieves aren't that = interested in stealing movie tickets, and most people don't lose their = tickets! > On the other hand, capturing bearer tokens > while sitting at a Starbucks using nothing more than a laptop with a = WiFi > card is trivial. Why would someone bother to sit and capture bearer tokens - what is the = value of doing that, and what is the actual risk? In some cases, = probably not that great... Imagine that we have an online movie bearer = token - it's one-time use + replay-protected and gets delivered to the = original requester after that entity has been authenticated (and is = delivered over SSL). Now your thief has to grab that token as it is sent = over the wire and somehow send it himself before the first request (by = the lawfully-authorized viewer) is processed by the server! I think this = is hard too - not impossible, but hard enough that for low-value cases, = I simply wouldn't worry too much about encrypting that initial request = (although of course, the movie stream itself would be DRMed!).=20 >=20 >> Yes, those things change over time, but having a sliding scale of = security is >> a good thing, not a bad thing - and that is already allowed by OAuth = today, >> (TLS/SSL+PLAINTEXT, RSA-SHA1, HMAC-SHA1, PLAINTEXT) and will continue = even if >> you remove PLAINTEXT from the list. >=20 > We are creating web standards, not just generic technologies. I don't = want > to find *any* PLAINTEXT implementation on the web, but don't care if = someone > uses it on their own private network. But if that's what they are = doing, > they are free to drop TLS/SSL requirement anyway because they control = the > environment. >=20 > Since we are talking about one word, MUST vs. SHOULD, I think we = should > start with MUST and continue having this discussion when we have more = pieces > of the puzzle in place. I think you've raised a valid issue, but I don't yet hear any consensus = about this change, or whether the suggested text actually does what we = want. I hope you'll consider that (and perhaps wait a bit longer to make = such a change). Cheers, - johnk From eran@hueniverse.com Fri Jan 15 14:15:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAFF3A6880 for ; Fri, 15 Jan 2010 14:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 AJjrDQ7CnkwQ for ; Fri, 15 Jan 2010 14:15:19 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 03DF23A67E5 for ; Fri, 15 Jan 2010 14:15:18 -0800 (PST) Received: (qmail 21897 invoked from network); 15 Jan 2010 22:15:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jan 2010 22:15:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 15 Jan 2010 15:15:16 -0700 From: Eran Hammer-Lahav To: John Kemp Date: Fri, 15 Jan 2010 15:15:13 -0700 Thread-Topic: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels Thread-Index: AcqWLnerrSKN1SExTLCqFPsopiKSFAAAb2dS 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Jan 2010 22:15:20 -0000 On 1/15/10 2:02 PM, "John Kemp" wrote: > Why would someone bother to sit and capture bearer tokens - what is the v= alue > of doing that, and what is the actual risk? In some cases, probably not t= hat > great... It would be great if the WRAP authors can share with us how their employers plan to deploy their protocol. We have three major companies involved in developing WRAP and they created a solution that can create severe security risks. I am not aware of any APIs from MS, Y!, or Google that I would be happy to use if they used bearer token without channel security. > I think you've raised a valid issue, but I don't yet hear any consensus a= bout > this change, or whether the suggested text actually does what we want. I = hope > you'll consider that (and perhaps wait a bit longer to make such a change= ). I agree, which is why I didn't want to paint this as a decided issue, just that we might need more context to reach consensus and I need to put something in the spec. My proposal is to be more restrictive and loosen it later instead of the other way around. EHL From stpeter@stpeter.im Fri Jan 15 14:42:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97953A6828 for ; Fri, 15 Jan 2010 14:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 gCV+WT+15MP6 for ; Fri, 15 Jan 2010 14:42:44 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D1AD93A6827 for ; Fri, 15 Jan 2010 14:42:43 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 611C140D1C for ; Fri, 15 Jan 2010 15:42:40 -0700 (MST) Message-ID: <4B50EF5D.4020303@stpeter.im> Date: Fri, 15 Jan 2010 15:42:37 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 1.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020408000002020208030202" Subject: [OAUTH-WG] Fwd: I-D Action:draft-hardt-oauth-01.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: Fri, 15 Jan 2010 22:42:44 -0000 This is a cryptographically signed message in MIME format. --------------ms020408000002020208030202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI. Thanks to Dick for submitting this! /psa -------- Original Message -------- Subject: I-D Action:draft-hardt-oauth-01.txt Date: Fri, 15 Jan 2010 14:15:02 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OAuth Web Resource Authorization Profiles Author(s) : D. Hardt, et al. Filename : draft-hardt-oauth-01.txt Pages : 40 Date : 2010-01-15 The OAuth Web Resource Authorization Profiles (OAuth WRAP) allow a server hosting a Protected Resource to delegate authorization to one or more authorities. An application (Client) accesses the Protected Resource by presenting a short lived, opaque, bearer token (Access Token) obtained from an authority (Authorization Server). There are Profiles for how a Client may obtain an Access Token when acting autonomously or on behalf of a User. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 19, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hardt-oauth-01.txt --------------ms020408000002020208030202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDExNTIyNDIzN1owIwYJKoZIhvcNAQkEMRYEFFpmQEuNzpPh2D09G0/+ lyTuAvroMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAVKLyF6ZntS3pWnDHj9FG7SvCsG+dgxPntRjblAY6 fFcEh84PwGd3nkRXWqutkAZaAfxMmiXcDT06BXKKP+TBZQw7aDwpejGkesYsMONOlWGMSegR 5Ze1VThbFsZM8YP+/mpFW5WJBQTv0dLDPqHdnVrp1Hvc3l1IoNDaxMokIujfBlYaTpQL6ZKL GkaZrLVyo8LZY0ZyB7N3OPzC05DMbogMNTYNyJeQyW4tf9sBllAzU9pNtUqONKZzJaOf9fb2 WYiADldw4EzFEoryOC/h02SIAwCe0sWdM0zqeNvj4qTXom+hmilXYgnxrEqAq10qITXEicCP +/lh2hptkrKeXwAAAAAAAA== --------------ms020408000002020208030202-- From email@pbryan.net Fri Jan 15 14:49:55 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0843A6848 for ; Fri, 15 Jan 2010 14:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 uGwFLdJJ8ZXO for ; Fri, 15 Jan 2010 14:49:54 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id B54CD3A683C for ; Fri, 15 Jan 2010 14:49:54 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 3B116EA022 for ; Fri, 15 Jan 2010 22:49:51 +0000 (UTC) From: "Paul C. Bryan" To: OAuth WG In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Fri, 15 Jan 2010 14:49:45 -0800 Message-ID: <1263595785.551.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Jan 2010 22:49:55 -0000 On Fri, 2010-01-15 at 14:41 -0700, Eran Hammer-Lahav wrote: > > > On 1/15/10 7:58 AM, "John Kemp" wrote: > > > When I look at what is possible in the offline world, I would ask - would you > > require that movie theatre tickets bought in advance were encrypted in > > transport between the person who bought the ticket and the receptionist at the > > cinema? What if the person drops her ticket and it's picked up by someone > > else? The risk of someone dropping his ticket is low, so we don't bother to > > secure it (of course, I haven't been to a city movie theatre in years so > > perhaps you need to show ID even to see a movie these days -- I hope not ;) Of > > course, the person who _does_ drop his ticket will be mad when he gets to the > > movie theatre, but probably not too mad. The system has worked quite well > > without any real security. We might add more security, but it would, even > > today, probably be hard to justify the cost. > > I don't think this is a fair comparison. Stealing a movie ticket is very > hard, and punishable but fines and prison time (potentially federal is > captured in transit via US Mail). On the other hand, capturing bearer tokens > while sitting at a Starbucks using nothing more than a laptop with a WiFi > card is trivial. > > > Yes, those things change over time, but having a sliding scale of security is > > a good thing, not a bad thing - and that is already allowed by OAuth today, > > (TLS/SSL+PLAINTEXT, RSA-SHA1, HMAC-SHA1, PLAINTEXT) and will continue even if > > you remove PLAINTEXT from the list. > > We are creating web standards, not just generic technologies. I don't want > to find *any* PLAINTEXT implementation on the web, but don't care if someone > uses it on their own private network. But if that's what they are doing, > they are free to drop TLS/SSL requirement anyway because they control the > environment. I'm in 100% agreement on this point if the MUST is constrained to limit only non-encrypted PLAINTEXT implementations on the web. > Since we are talking about one word, MUST vs. SHOULD, I think we should > start with MUST and continue having this discussion when we have more pieces > of the puzzle in place. > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From faynberg@alcatel-lucent.com Fri Jan 15 14:57:07 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787CE3A6988 for ; Fri, 15 Jan 2010 14:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.099, 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 Bmwi2yp0ppIY for ; Fri, 15 Jan 2010 14:57:06 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 7EBF93A6982 for ; Fri, 15 Jan 2010 14:57:05 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o0FMv0Kg002179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jan 2010 16:57:00 -0600 (CST) Received: from [135.244.38.97] (faynberg.lra.lucent.com [135.244.38.97]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o0FMuxLr017563; Fri, 15 Jan 2010 16:56:59 -0600 (CST) Message-ID: <4B50F2BD.8030104@alcatel-lucent.com> Date: Fri, 15 Jan 2010 17:57:01 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav 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.33 Cc: OAuth WG Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 22:57:07 -0000 Interestingly enough, when I bought, over the Internet, a ticket to Film Forum in New York, the way it worked, it amounted to a number (token), which I had to redeem at the movie theater. I was authenticated by showing my credit card with which I bought the ticket; I guess I could have been asked for a drivers license, too. So even in the movie ticket case, there was a (sort of) strong authentication of the token bearer at the point of obtaining the resource. Interestingly enough, the same method is being used with the airline tickets, where the risks are much higher. This is why I am taking the same position as Eran. Igor Eran Hammer-Lahav wrote: > > On 1/15/10 7:58 AM, "John Kemp" wrote: > > >> When I look at what is possible in the offline world, I would ask - would you >> require that movie theatre tickets bought in advance were encrypted in >> transport between the person who bought the ticket and the receptionist at the >> cinema? What if the person drops her ticket and it's picked up by someone >> else? The risk of someone dropping his ticket is low, so we don't bother to >> secure it (of course, I haven't been to a city movie theatre in years so >> perhaps you need to show ID even to see a movie these days -- I hope not ;) Of >> course, the person who _does_ drop his ticket will be mad when he gets to the >> movie theatre, but probably not too mad. The system has worked quite well >> without any real security. We might add more security, but it would, even >> today, probably be hard to justify the cost. >> > > I don't think this is a fair comparison. Stealing a movie ticket is very > hard, and punishable but fines and prison time (potentially federal is > captured in transit via US Mail). On the other hand, capturing bearer tokens > while sitting at a Starbucks using nothing more than a laptop with a WiFi > card is trivial. > > >> Yes, those things change over time, but having a sliding scale of security is >> a good thing, not a bad thing - and that is already allowed by OAuth today, >> (TLS/SSL+PLAINTEXT, RSA-SHA1, HMAC-SHA1, PLAINTEXT) and will continue even if >> you remove PLAINTEXT from the list. >> > > We are creating web standards, not just generic technologies. I don't want > to find *any* PLAINTEXT implementation on the web, but don't care if someone > uses it on their own private network. But if that's what they are doing, > they are free to drop TLS/SSL requirement anyway because they control the > environment. > > Since we are talking about one word, MUST vs. SHOULD, I think we should > start with MUST and continue having this discussion when we have more pieces > of the puzzle in place. > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From john@jkemp.net Fri Jan 15 15:01:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11893A67FF for ; Fri, 15 Jan 2010 15:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxelVd1hUUNA for ; Fri, 15 Jan 2010 15:01:22 -0800 (PST) Received: from outbound-mail-158.bluehost.com (outbound-mail-158.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 01EF73A67E6 for ; Fri, 15 Jan 2010 15:01:21 -0800 (PST) Received: (qmail 14446 invoked by uid 0); 15 Jan 2010 23:01:19 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy5.bluehost.com with SMTP; 15 Jan 2010 23:01:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=gTy5Pnm86D9/zFyEp5I7blbfL+cMQ0UTAjeAYdJLyZIQyKpsHEpVcu8IfQ7V60oUQSfIxtzmyJ8PKF47G8pJjVFRtfQq+9CNdsVJRX7RpjVjwEwTfI0RCzfT9AkYSbtq; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.103]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NVvAM-0007pa-I7; Fri, 15 Jan 2010 16:01:19 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <4B50F2BD.8030104@alcatel-lucent.com> Date: Fri, 15 Jan 2010 18:01:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B50F2BD.8030104@alcatel-lucent.com> To: faynberg@alcatel-lucent.com X-Mailer: Apple Mail (2.1077) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: OAuth WG Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Jan 2010 23:01:23 -0000 On Jan 15, 2010, at 5:57 PM, Igor Faynberg wrote: > Interestingly enough, when I bought, over the Internet, a ticket to = Film Forum in New York, the way it worked, it amounted to a number = (token), which I had to redeem at the movie theater. I was authenticated = by showing my credit card with which I bought the ticket; I guess I = could have been asked for a drivers license, too. So even in the movie = ticket case, there was a (sort of) strong authentication of the token = bearer at the point of obtaining the resource. Interestingly enough, the = same method is being used with the airline tickets, where the risks are = much higher. Right, you were authenticated as an authorized bearer of the token, by = matching information about the bearer in the token against additional = information you provided separately. That's possible without channel = security, of course.=20 - johnk >=20 > This is why I am taking the same position as Eran. >=20 > Igor >=20 > Eran Hammer-Lahav wrote: >>=20 >> On 1/15/10 7:58 AM, "John Kemp" wrote: >>=20 >> =20 >>> When I look at what is possible in the offline world, I would ask - = would you >>> require that movie theatre tickets bought in advance were encrypted = in >>> transport between the person who bought the ticket and the = receptionist at the >>> cinema? What if the person drops her ticket and it's picked up by = someone >>> else? The risk of someone dropping his ticket is low, so we don't = bother to >>> secure it (of course, I haven't been to a city movie theatre in = years so >>> perhaps you need to show ID even to see a movie these days -- I hope = not ;) Of >>> course, the person who _does_ drop his ticket will be mad when he = gets to the >>> movie theatre, but probably not too mad. The system has worked quite = well >>> without any real security. We might add more security, but it would, = even >>> today, probably be hard to justify the cost. >>> =20 >>=20 >> I don't think this is a fair comparison. Stealing a movie ticket is = very >> hard, and punishable but fines and prison time (potentially federal = is >> captured in transit via US Mail). On the other hand, capturing bearer = tokens >> while sitting at a Starbucks using nothing more than a laptop with a = WiFi >> card is trivial. >> =20 >>> Yes, those things change over time, but having a sliding scale of = security is >>> a good thing, not a bad thing - and that is already allowed by OAuth = today, >>> (TLS/SSL+PLAINTEXT, RSA-SHA1, HMAC-SHA1, PLAINTEXT) and will = continue even if >>> you remove PLAINTEXT from the list. >>> =20 >>=20 >> We are creating web standards, not just generic technologies. I don't = want >> to find *any* PLAINTEXT implementation on the web, but don't care if = someone >> uses it on their own private network. But if that's what they are = doing, >> they are free to drop TLS/SSL requirement anyway because they control = the >> environment. >>=20 >> Since we are talking about one word, MUST vs. SHOULD, I think we = should >> start with MUST and continue having this discussion when we have more = pieces >> of the puzzle in place. >>=20 >> EHL >>=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 stpeter@stpeter.im Fri Jan 15 15:06:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA0F3A682A for ; Fri, 15 Jan 2010 15:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 3-u+uO7Bkvek for ; Fri, 15 Jan 2010 15:06:23 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id BA69F3A67FF for ; Fri, 15 Jan 2010 15:06:23 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4FBEB40D1C for ; Fri, 15 Jan 2010 16:06:20 -0700 (MST) Message-ID: <4B50F4EB.3000402@stpeter.im> Date: Fri, 15 Jan 2010 16:06:19 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 1.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000603050804000703030502" Subject: [OAUTH-WG] draft agenda for first interim meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Jan 2010 23:06:24 -0000 This is a cryptographically signed message in MIME format. --------------ms000603050804000703030502 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OAuth WG Interim Meeting Agenda Date: 2010-01-21 Time: 19:00 UTC (check for your local time) Length: 60 minutes Chairs: Blaine Cook and Peter Saint-Andre LOGISTICS Web: https://workgreen.webex.com/workgreen/j.php?ED=3D131214267&UID=3D0&PW=3DN= MTU2ODQyMWY5&RT=3DMiMyMQ%3D%3D Password: oauth Phone (USA/Canada): 1-408-792-6300 Phone (Global): https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&E= D=3D131214267&tollFree=3D0 Access code: 962 929 885 Help: https://workgreen.webex.com/workgreen/mc or ping me via xmpp:stpeter@jabber.org Chat Room: xmpp:oauth@jabber.ietf.org?join AGENDA 1. Introduction (5 minutes) a. NOTE WELL applies to interim meetings! b. Welcome from the chairs c. Volunteer to write the minutes b. Agenda bashing 2. Goals of the Interim Meetings (5 minutes) a. Accurately describe the problem space b. Gather scenarios / use cases / profiles c. For authentication, reach *rough* consensus d. For authorization and delegation, determine roughly which aspects are "core" and which are "extensions" e. Make significant progress before IETF 77 in Anaheim f. Any others? 3. Problem Space (10 minutes) a. Need a clearer definition of what we're trying to solve b. Has the problem shifted since OAuth 1.0? c. What problem are we solving now? d. Can we settle on consistent terminology, please? :) e. Architecture matters 3. Scenarios (15 minutes) a. Core scenarios, see draft-ietf-oauth-web-delegation-01 b. Scenarios from WRAP, see draft-hardt-oauth-01 c. Scenarios from User Managed Access (UMA), I-D on the way? d. How can we gather other scenarios? 6. Authentication (10 minutes) a. draft-ietf-oauth-authentication b. Open issues 7. Authorization and Delegation (10 minutes) a. What is core? b. What can we define as extensions? 8. Action Items (5 minutes) a. Gather more scenarios b. Review draft-ietf-oauth-authentication and work through remaining issues c. Input on authorization and delegation d. Time of next interim meeting END --------------ms000603050804000703030502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDExNTIzMDYxOVowIwYJKoZIhvcNAQkEMRYEFHw+n5LoBPDKdvXCs6m5 kOFH1dEYMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAD/XtsO5z9cW0475daqxmijc3HP6Nbob+/cw9GMFK QnJMOsFxbKdUi2fCg0EgVQCEl/wy2HfN1qzuZakG+gvNuQS7WOvU/DdXObS1Qu3c7VTWx3f5 +KMuuD606LdT+tFLTkOZQk3SF0qk8ocwnm5SAgWSpOJGrQ5kXLhIfNpfolGZPcOsZmJ+O3AU Pz8R5nEVF7/bdleG8WvOPbRpramUuQbV6VnWWYeq080lSpx3VsTFnhbhpkzyqBq0MtUpMaz9 IelgGmLwryHCeIf5V6HBLFgZ2K5t4OEDc7lq8vA/3UqF7N6kfW5QOBwXUZgFmUpchj33QGJg eqtVwIoe+UOVdQAAAAAAAA== --------------ms000603050804000703030502-- From faynberg@alcatel-lucent.com Fri Jan 15 15:24:52 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E533A69B3 for ; Fri, 15 Jan 2010 15:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.085, 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 Crw0Yd+c4X7w for ; Fri, 15 Jan 2010 15:24:51 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id B68AC3A69AE for ; Fri, 15 Jan 2010 15:24:51 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o0FNOkkc024981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jan 2010 17:24:46 -0600 (CST) Received: from [135.244.38.97] (faynberg.lra.lucent.com [135.244.38.97]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o0FNOjIt013860; Fri, 15 Jan 2010 17:24:45 -0600 (CST) Message-ID: <4B50F93E.3060601@alcatel-lucent.com> Date: Fri, 15 Jan 2010 18:24:46 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: John Kemp References: <4B50F2BD.8030104@alcatel-lucent.com> 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.33 Cc: OAuth WG Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 23:24:52 -0000 John Kemp wrote: > On Jan 15, 2010, at 5:57 PM, Igor Faynberg wrote: > > > > Right, you were authenticated as an authorized bearer of the token, by matching information about the bearer in the token against additional information you provided separately. That's possible without channel security, of course. > > Exactly, and I did not see in OAuth a way to enforce the token bearer authentication, which is one reason I was for channel security. The other reason is privacy. Even with movie tickets, some people might prefer that no one know what exactly they are buying. The channel security sort of takes care of the transaction privacy at the same time as doing other useful things. I think this will be a serious point in bringing SIP to use OAuth. Igor From john.hurliman@intel.com Fri Jan 15 16:55:08 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920653A6994 for ; Fri, 15 Jan 2010 16:55:08 -0800 (PST) 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 iCJ7wOhATAkU for ; Fri, 15 Jan 2010 16:55:03 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id 763D63A6405 for ; Fri, 15 Jan 2010 16:55:03 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 15 Jan 2010 16:55:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,316,1257148800"; d="scan'208,217";a="233340225" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by azsmga001.ch.intel.com with ESMTP; 15 Jan 2010 16:55:00 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Fri, 15 Jan 2010 17:55:00 -0700 From: "Hurliman, John" To: OAuth WG , "oauth-wrap-wg@googlegroups.com" Date: Fri, 15 Jan 2010 17:54:46 -0700 Thread-Topic: Virtual world use case for OAuth Thread-Index: AcqWRn+4RGLXmBEkRX2Lu93n6uJYZQ== Message-ID: <62BFE5680C037E4DA0B0A08946C0933DC4A74D2B@rrsmsx506.amr.corp.intel.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_62BFE5680C037E4DA0B0A08946C0933DC4A74D2Brrsmsx506amrcor_" MIME-Version: 1.0 Subject: [OAUTH-WG] Virtual world use case for 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: Sat, 16 Jan 2010 00:55:08 -0000 --_000_62BFE5680C037E4DA0B0A08946C0933DC4A74D2Brrsmsx506amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello OAuth lists! Let my briefly introduce myself. I'm John Hurliman, a software engineer on = Intel's Virtual World Infrastructure team. Our team focuses on everything i= n immersive connected experiences from performance and scalability to feder= ated identity and interoperability. My project over the last year has been = Cable Beach, a research project to investigate topics such as federated ide= ntity, delegated service authorization, service discovery, etc. as they app= ly to immersive connected experiences. I've also been working closely with = the VWRAP (Virtual World Region Access Protocol) IETF group and plan to mer= ge my Cable Beach work into VWRAP. I'll be presenting at VWRAP IETF77 and w= ill hopefully be able to stop by the OAuth working group as well. I recently wrote a blog post detailing the history of VWRAP and Cable Beach= , and how OAuth WRAP is currently meeting our needs (and hopefully OAuth 2.= 0). Hopefully this can serve as an example scenario for OAuth. http://www.j= hurliman.org/2010/01/merging-vwrap-and-cable-beach/ The important highlights are: 1) We need to support both web-initiated logi= ns and logins directly through a client where the user inputs a username/pa= ssword. The latter will also support automated clients where it's not feasi= ble for a human to go through a web login process every time. 2) We need to= expose web APIs for the various virtual world services, preferably using t= he same system that users login to the virtual world with. 3) We need to be= able to login to one virtual world using an account that exists on another= world (similar to an OpenID or Facebook Connect login). 4) The easier to i= mplement the better, since we will likely have implementations popping up i= n at least C++, C#, Python, PHP, and Java. Best, John Hurliman Intel Corp. --_000_62BFE5680C037E4DA0B0A08946C0933DC4A74D2Brrsmsx506amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello OAuth lists!

Let my briefly introduce myself. I’m John Hurlim= an, a software engineer on Intel’s Virtual World Infrastructure team. Our t= eam focuses on everything in immersive connected experiences from performance a= nd scalability to federated identity and interoperability. My project over the last year h= as been Cable Beach, a research project to investigate topics such as federate= d identity, delegated service authorization, service discovery, etc. as they apply to immersive connected experiences. I’ve also been working clos= ely with the VWRAP (Virtual World Region Access Protocol) IETF group and plan t= o merge my Cable Beach work into VWRAP. I’ll be presenting at VWRAP IET= F77 and will hopefully be able to stop by the OAuth working group as well.=

I recently wrote a blog post detailing the history of = VWRAP and Cable Beach, and how OAuth WRAP is currently meeting our needs (and hopefully OAuth 2.0). Hopefully this can serve as an example scenario for O= Auth. http://www.jhurliman.org/2010/01/merging-vwrap-and-cable-beach/

The important highlights are: 1) We need to support bo= th web-initiated logins and logins directly through a client where the user in= puts a username/password. The latter will also support automated clients where i= t’s not feasible for a human to go through a web login process every time. 2) W= e need to expose web APIs for the various virtual world services, preferably using the same system that users login to the virtual world with. 3) We nee= d to be able to login to one virtual world using an account that exists on anoth= er world (similar to an OpenID or Facebook Connect login). 4) The easier to implement the better, since we will likely have implementations popping up = in at least C++, C#, Python, PHP, and Java.

Best,

John Hurliman

Intel Corp.

--_000_62BFE5680C037E4DA0B0A08946C0933DC4A74D2Brrsmsx506amrcor_-- From recordond@gmail.com Fri Jan 15 20:06:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817783A6452 for ; Fri, 15 Jan 2010 20:06:11 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5ARZvg81Hiu for ; Fri, 15 Jan 2010 20:06:10 -0800 (PST) Received: from mail-iw0-f201.google.com (mail-iw0-f201.google.com [209.85.223.201]) by core3.amsl.com (Postfix) with ESMTP id 4ECD53A6804 for ; Fri, 15 Jan 2010 20:06:10 -0800 (PST) Received: by iwn39 with SMTP id 39so997375iwn.32 for ; Fri, 15 Jan 2010 20:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KAoZ6rbjnESduFw/rF/T5dnPGjDUiyliARl51UJqfTE=; b=aJWlIjd/DAsK9/10mpl0+fQL+uiudCuFGlCMt7w+vEHhwtfoUYhwugf/VF1H9REV4C tvPi+9555AdWs9EboWggyvgVnRHepnEaghyEhXW8BSaobqDPCJ02BFWTlXuHHSczYEEq 6DeTu5SM0ZGpuFS/7zX1UXSV2OafwPv8LG8AE= 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=KNHg/+v6DJA78kie1QeXtq3zJjQMimN/oKNidLeM+RIcLpVXbXs3jt826Xz+FOICIq YrXuZUAIrrCbJ7rmG9HI2EmOsFLYYdF3XRxsm8OVmHmp9ugX5ONTDcM7M8NVOFEDOpsF clNhhxK72F5TfP1pkBtsvT8TOYaxmYgNmhBFQ= MIME-Version: 1.0 Received: by 10.231.40.216 with SMTP id l24mr3281482ibe.40.1263614764505; Fri, 15 Jan 2010 20:06:04 -0800 (PST) In-Reply-To: References: Date: Fri, 15 Jan 2010 20:06:04 -0800 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Setting Course X-BeenThere: oauth@ietf.org X-Mailman-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, 16 Jan 2010 04:06:11 -0000 Yes, those two drafts make sense. From other threads it sounds like we're making progress on the Authentication draft which will both support signatures (ala OAuth 1.x) and plaintext plus SSL/TLS (ala WRAP). I'll try to start working toward consensus on the core flows we'd like to support in the Authorization draft next week. --David On Wed, Jan 13, 2010 at 4:53 PM, Eran Hammer-Lahav wrote: > I think the goal of the next two months is to produce two semi-stable drafts > covering the two parts of the protocol: > > 1. Authentication - how to make authenticated requests / signed messages > using token credentials. This will be based on my token auth draft [1] as a > starting point. There are a few open issues to decide based on feedback > received from Panzer and Eaton which I will post about shortly. > > 2. Authorization - how to obtain a set of token credentials using web > redirection and other flows introduced by WRAP. This will be a new draft > using the web-delegation draft [2] skeleton and the flows in WRAP section 5 > [3]. There are many open issues to decide, starting with which flows to > keep, which to move to an extension, and if there are additional ones to > add. > > These drafts will be locked before the WG meeting to allow review and will > be discussed at the meeting. We will also discuss any charter changes > required to accommodate the drafts. This approach will allow us to focus on > the work and worry about the charter at the meeting. This will ensure we > ground the process in actual technical consensus. > > Comments? > > EHL > > [1] http://tools.ietf.org/html/draft-hammer-http-token-auth > [2] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation > [3] http://bit.ly/oauth-wrap > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Fri Jan 15 20:07:34 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C30CA3A6778 for ; Fri, 15 Jan 2010 20:07:34 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+VV+eiXW+Ra for ; Fri, 15 Jan 2010 20:07:33 -0800 (PST) Received: from mail-iw0-f201.google.com (mail-iw0-f201.google.com [209.85.223.201]) by core3.amsl.com (Postfix) with ESMTP id 55D073A6804 for ; Fri, 15 Jan 2010 20:07:33 -0800 (PST) Received: by iwn39 with SMTP id 39so997822iwn.32 for ; Fri, 15 Jan 2010 20:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aTTgnRMebiYDoc6DaokLHPNUHhTxyHTCwgxPUhH5te8=; b=Cz+hUVhVCYQSv9ZZnCsZrJ8BS8iGsQZkBaY9bGnw7MLnU5cv4mUmsZuunvVx0Eetxp f6c6he6Ic4/8GcWwtogxRGgEWpSdVUmeYNwVq+llhIn8NQoxiPOn3oLImcAep3hy2pz6 P9xNapE/Uaz5Op9iZY8GR2KBDF0PEbvrPMocE= 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=p0TPQACNaNi6H9JWhZQS6Dd9hJ4vmJwCrrPOo5IT7CXWRFdQY0xlQoHdxJCYnUwsYS LKA5qOC1kL46wDXY5ojV//gWY2CDdc53Tc4Y+CZzzjumlWqdKjIPkX6TcBAOjFtbJugh janIpMylOwFw7tU0LTndXDDVxHryP7DEvV1kk= MIME-Version: 1.0 Received: by 10.231.170.14 with SMTP id b14mr479666ibz.26.1263614847782; Fri, 15 Jan 2010 20:07:27 -0800 (PST) In-Reply-To: <4B50EF5D.4020303@stpeter.im> References: <4B50EF5D.4020303@stpeter.im> Date: Fri, 15 Jan 2010 20:07:27 -0800 Message-ID: From: David Recordon To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: I-D Action:draft-hardt-oauth-01.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, 16 Jan 2010 04:07:35 -0000 Hey Peter, Awesome! Thanks Dick! How can we have an HTML version of it (i.e. http://www.ietf.org/id/draft-hardt-oauth-01.html) published as well? It's much easier to discuss when we can link to specific sections. Thanks, --David On Fri, Jan 15, 2010 at 2:42 PM, Peter Saint-Andre wro= te: > FYI. Thanks to Dick for submitting this! > > /psa > > -------- Original Message -------- > Subject: I-D Action:draft-hardt-oauth-01.txt > Date: Fri, 15 Jan 2010 14:15:02 -0800 (PST) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : OAuth Web Resource Authorizati= on Profiles > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : D. Hardt, et al. > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-hardt-oauth-01.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 40 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-01-15 > > The OAuth Web Resource Authorization Profiles (OAuth WRAP) allow a > server hosting a Protected Resource to delegate authorization to one > or more authorities. =A0An application (Client) accesses the Protected > Resource by presenting a short lived, opaque, bearer token (Access > Token) obtained from an authority (Authorization Server). =A0There are > Profiles for how a Client may obtain an Access Token when acting > autonomously or on behalf of a User. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. =A0Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. =A0It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on July 19, 2010. > > Copyright Notice > Copyright (c) 2010 IETF Trust and the persons identified as the > document authors. =A0All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. =A0Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. =A0Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hardt-oauth-01.txt > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From recordond@gmail.com Fri Jan 15 20:12:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5659D3A6848 for ; Fri, 15 Jan 2010 20:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.233, 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 Pooj3GGRhnfg for ; Fri, 15 Jan 2010 20:12:57 -0800 (PST) Received: from mail-iw0-f201.google.com (mail-iw0-f201.google.com [209.85.223.201]) by core3.amsl.com (Postfix) with ESMTP id 8D6D13A6778 for ; Fri, 15 Jan 2010 20:12:55 -0800 (PST) Received: by iwn39 with SMTP id 39so999533iwn.32 for ; Fri, 15 Jan 2010 20:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UMtfXhQQexWMBP71V+N8st9D7jTTR8Cz8lNw0FF7g7M=; b=XSpXZ+wJemU3Ttp+Z8O4UY3HOv4ZBpW7lEn4nGz1xuJbO1ZRn4/3o+xAFauxO0WxQC YRvzy0KEL1x2M7ddT0t8GmaIwAB7EnDRHRnuLqieHPxcKuu2q9NwQEgNhDOl+CzjTi1p RszKhFanRKutwpBWVpjzS/pDEPAqxqb+ia/yw= 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=srAmRj+LXKcZK55BsfEilzQZvIC25xr9IbhMoCs7hr7YUibB6s+0QbKWqEPdKRyCBL XidO/R4bjG1aDesEN9JJeO8xWRCUpWa7q3I1fhLzhUb7m4dPU8BEG0ceKHxBMxXX8ONk TeXYJEfJqto7H6tXBXV3kxI/U7CMaNGk/jTKs= MIME-Version: 1.0 Received: by 10.231.143.148 with SMTP id v20mr1813881ibu.14.1263615169943; Fri, 15 Jan 2010 20:12:49 -0800 (PST) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DC4A74D2B@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933DC4A74D2B@rrsmsx506.amr.corp.intel.com> Date: Fri, 15 Jan 2010 20:12:49 -0800 Message-ID: From: David Recordon To: "Hurliman, John" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG , "oauth-wrap-wg@googlegroups.com" Subject: Re: [OAUTH-WG] Virtual world use case for 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: Sat, 16 Jan 2010 04:12:59 -0000 Hey John, I think that the OAuth work under way will support your scenarios other than #3. Signing in with an arbitrary account is currently best solved via OpenID. OAuth powers Twitter's SSO but requires that each implementor know specifically that it will be a Twitter user logging in whereas OpenID has bootstrapping discovery built in. I'm with you for #4; simplicity for developers is really important in this next generation of OAuth! --David On Fri, Jan 15, 2010 at 4:54 PM, Hurliman, John w= rote: > Hello OAuth lists! > > > > Let my briefly introduce myself. I=92m John Hurliman, a software engineer= on > Intel=92s Virtual World Infrastructure team. Our team focuses on everythi= ng in > immersive connected experiences from performance and scalability to > federated identity and interoperability. My project over the last year ha= s > been Cable Beach, a research project to investigate topics such as federa= ted > identity, delegated service authorization, service discovery, etc. as the= y > apply to immersive connected experiences. I=92ve also been working closel= y > with the VWRAP (Virtual World Region Access Protocol) IETF group and plan= to > merge my Cable Beach work into VWRAP. I=92ll be presenting at VWRAP IETF7= 7 and > will hopefully be able to stop by the OAuth working group as well. > > > > I recently wrote a blog post detailing the history of VWRAP and Cable Bea= ch, > and how OAuth WRAP is currently meeting our needs (and hopefully OAuth 2.= 0). > Hopefully this can serve as an example scenario for OAuth. > http://www.jhurliman.org/2010/01/merging-vwrap-and-cable-beach/ > > > > The important highlights are: 1) We need to support both web-initiated > logins and logins directly through a client where the user inputs a > username/password. The latter will also support automated clients where i= t=92s > not feasible for a human to go through a web login process every time. 2)= We > need to expose web APIs for the various virtual world services, preferabl= y > using the same system that users login to the virtual world with. 3) We n= eed > to be able to login to one virtual world using an account that exists on > another world (similar to an OpenID or Facebook Connect login). 4) The > easier to implement the better, since we will likely have implementations > popping up in at least C++, C#, Python, PHP, and Java. > > > > Best, > > John Hurliman > > Intel Corp. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Fri Jan 15 20:13:55 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B1E3A6848 for ; Fri, 15 Jan 2010 20:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086, 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 cjiQuJkzmxM7 for ; Fri, 15 Jan 2010 20:13:54 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2035D3A6778 for ; Fri, 15 Jan 2010 20:13:54 -0800 (PST) Received: (qmail 4449 invoked from network); 16 Jan 2010 04:13:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jan 2010 04:13:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 15 Jan 2010 21:13:49 -0700 From: Eran Hammer-Lahav To: "recordond@gmail.com" Date: Fri, 15 Jan 2010 21:13:47 -0700 Thread-Topic: [OAUTH-WG] Fwd: I-D Action:draft-hardt-oauth-01.txt Thread-Index: AcqWYW9wgGWv/eBjSBOAZYY5L1ElswAAN0yc 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_C7767CFB2D1C3eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: I-D Action:draft-hardt-oauth-01.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, 16 Jan 2010 04:13:55 -0000 --_000_C7767CFB2D1C3eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-hardt-oauth is the same text document but = with HTML navigation. It will give you links for each section. EHL On 1/15/10 8:07 PM, "recordond@gmail.com" wrote: Hey Peter, Awesome! Thanks Dick! How can we have an HTML version of it (i.e. http://www.ietf.org/id/draft-hardt-oauth-01.html) published as well? It's much easier to discuss when we can link to specific sections. Thanks, --David On Fri, Jan 15, 2010 at 2:42 PM, Peter Saint-Andre wro= te: > FYI. Thanks to Dick for submitting this! > > /psa > > -------- Original Message -------- > Subject: I-D Action:draft-hardt-oauth-01.txt > Date: Fri, 15 Jan 2010 14:15:02 -0800 (PST) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : OAuth Web Resource Authorization Profiles > Author(s) : D. Hardt, et al. > Filename : draft-hardt-oauth-01.txt > Pages : 40 > Date : 2010-01-15 > > The OAuth Web Resource Authorization Profiles (OAuth WRAP) allow a > server hosting a Protected Resource to delegate authorization to one > or more authorities. An application (Client) accesses the Protected > Resource by presenting a short lived, opaque, bearer token (Access > Token) obtained from an authority (Authorization Server). There are > Profiles for how a Client may obtain an Access Token when acting > autonomously or on behalf of a User. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on July 19, 2010. > > Copyright Notice > Copyright (c) 2010 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hardt-oauth-01.txt > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C7767CFB2D1C3eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Fwd: I-D Action:draft-hardt-oauth-01.txt http://tools= .ietf.org/html/draft-hardt-oauth is the same text document but with HTM= L navigation. It will give you links for each section.

EHL

On 1/15/10 8:07 PM, "recordond@gmail.c= om" <recordond@gmail.com>= ; wrote:

Hey Peter,
Awesome! Thanks Dick!

How can we have an HTML version of it (i.e.
http://www.iet= f.org/id/draft-hardt-oauth-01.html) published as well?
It's much easier to discuss when we can link to specific sections.

Thanks,
--David

On Fri, Jan 15, 2010 at 2:42 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> FYI. Thanks to Dick for submitting this!
>
> /psa
>
> -------- Original Message --------
> Subject: I-D Action:draft-hardt-oauth-01.txt
> Date: Fri, 15 Jan 2010 14:15:02 -0800 (PST)
> From: Internet-Drafts@ietf.org
> Reply-To: internet-drafts@ietf.or= g
> To: i-d-announce@ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : OAuth Web Resource Authoriz= ation Profiles
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : D. Hardt, et al.
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-hardt-oauth-01.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 40
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-01-15
>
> The OAuth Web Resource Authorization Profiles (OAuth WRAP) allow a
> server hosting a Protected Resource to delegate authorization to one > or more authorities. =A0An application (Client) accesses the Protected=
> Resource by presenting a short lived, opaque, bearer token (Access
> Token) obtained from an authority (Authorization Server). =A0There are=
> Profiles for how a Client may obtain an Access Token when acting
> autonomously or on behalf of a User.
>
> Status of this Memo
>
> This Internet-Draft is submitted to IETF in full conformance with the<= BR> > provisions of BCP 78 and BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups. =A0Note that
> other groups may also distribute working documents as Internet-
> Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six months<= BR> > and may be updated, replaced, or obsoleted by other documents at any > time. =A0It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress." >
> The list of current Internet-Drafts can be accessed at
> http://www.ietf= .org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow= .html.
>
> This Internet-Draft will expire on July 19, 2010.
>
> Copyright Notice
> Copyright (c) 2010 IETF Trust and the persons identified as the
> document authors. =A0All rights reserved.
>
> This document is subject to BCP 78 and the IETF Trust's Legal
> Provisions Relating to IETF Documents
> (http://trustee.ietf.= org/license-info) in effect on the date of
> publication of this document. =A0Please review these documents
> carefully, as they describe your rights and restrictions with respect<= BR> > to this document. =A0Code Components extracted from this document must=
> include Simplified BSD License text as described in Section 4.e of
> the Trust Legal Provisions and are provided without warranty as
> described in the BSD License.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hardt-oauth-01.txt
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C7767CFB2D1C3eranhueniversecom_-- From eran@hueniverse.com Wed Jan 20 10:18:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9003A67A6 for ; Wed, 20 Jan 2010 10:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080, 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 xUs7PSFqvIsV for ; Wed, 20 Jan 2010 10:18:09 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 3F0193A63EB for ; Wed, 20 Jan 2010 10:18:09 -0800 (PST) Received: (qmail 23119 invoked from network); 20 Jan 2010 18:18:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Jan 2010 18:18:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 20 Jan 2010 11:18:00 -0700 From: Eran Hammer-Lahav To: HTTP Group Date: Wed, 20 Jan 2010 11:17:58 -0700 Thread-Topic: Authentication-Info Header Thread-Index: Acp1BeZ50vQJGcQeSVy/GYWbP92miwk9v4l6 Message-ID: In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529362B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C77C88D62D6C8eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Authentication-Info Header X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Jan 2010 18:18:10 -0000 --_000_C77C88D62D6C8eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Any comments? Suggestions? EHL On 12/4/09 9:19 AM, "Eran Hammer-Lahav" wrote: The Authentication-Info header should be added to draft-ietf-httpbis-p7-aut= h to provide a complete list of all the defined authentication headers. It = should generalize the definition to make it useful for new authentication s= chemes: The Authentication-Info header is used by the server to communicate some information regarding the successful authentication in the response= . The Authentication-Info header is allowed in the trailer of an HTTP message transferred via chunked transfer-coding. Authentication-Info =3D "Authentication-Info" ":" OWS Authentication-I= nfo-v Authentication-Info-v =3D 1#auth-param And should probably (finally) define Proxy-Authentication-Info which is onl= y mentioned in passing in 2617. It is also not clear if the Authentication-Info header can (or is appropria= te) together with a new WWW-Authenticate challenge. --- Also, for OAuth, we are looking for a place to provide authentication error= information. The current definition of Authentication-Info limits it use t= o successful authentications. While I can certainly argue that an error is = "some information regarding the successful authentication", (i.e. that it w= as not), it seems to violate the spirit of the text. I am not aware of other authentication schemes using this header than Diges= t, and since Digest limits the allowed values, extending this header field = to mean *any* status information (not just successful) should not break or = change any existing implementation. If the definition remains the same, we will need to decide between minting = a new header Authentication-Error (and corresponding Proxy-Authentication-E= rror), or find a way to stick the error information together with a new cha= llenge or as masked as new challenge. I am not excited about the latter opt= ion, especially given the possibility of multiple challenges in a single he= ader. EHL --_000_C77C88D62D6C8eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Authentication-Info Header
Any comments? Suggestions?

EHL

On 12/4/09 9:19 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

The Authentication-Info header should be ad= ded to draft-ietf-httpbis-p7-auth to provide a complete list of all the def= ined authentication headers. It should generalize the definition to make it= useful for new authentication schemes:

   The Authentication-Info header is used by the server to c= ommunicate
   some information regarding the successful authentication = in the response.
   The Authentication-Info header is allowed in the trailer = of an HTTP
   message transferred via chunked transfer-coding.

     Authentication-Info =3D "Authentication-= Info" ":" OWS Authentication-Info-v
     Authentication-Info-v =3D 1#auth-param

And should probably (finally) define Proxy-Authentication-Info which is onl= y mentioned in passing in 2617.

It is also not clear if the Authentication-Info header can (or is appropria= te) together with a new WWW-Authenticate challenge.

---

Also, for OAuth, we are looking for a place to provide authentication error= information. The current definition of Authentication-Info limits it use t= o successful authentications. While I can certainly argue that an error is = "some information regarding the successful authentication", (i.e.= that it was not), it seems to violate the spirit of the text.

I am not aware of other authentication schemes using this header than Diges= t, and since Digest limits the allowed values, extending this header field = to mean *any* status information (not just successful) should not break or = change any existing implementation.

If the definition remains the same, we will need to decide between minting = a new header Authentication-Error (and corresponding Proxy-Authentication-E= rror), or find a way to stick the error information together with a new cha= llenge or as masked as new challenge. I am not excited about the latter opt= ion, especially given the possibility of multiple challenges in a single he= ader.

EHL

--_000_C77C88D62D6C8eranhueniversecom_-- From Jeff.Hodges@KingsMountain.com Wed Jan 20 13:18:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0429928C0F7 for ; Wed, 20 Jan 2010 13:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2d2iNzcBE6v for ; Wed, 20 Jan 2010 13:18:11 -0800 (PST) Received: from outbound-mail-01.bluehost.com (outbound-mail-01.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id ED8A328C0D8 for ; Wed, 20 Jan 2010 13:18:10 -0800 (PST) Received: (qmail 13065 invoked by uid 0); 20 Jan 2010 21:18:06 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by outboundproxy4.bluehost.com with SMTP; 20 Jan 2010 21:18:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=oPaeVM4F23GFWQvqEHQGVaGgCbGNEJ+dq61agKNDn9XjWUV27VbqAG0aGEisHWvTVwS32M303+/u+/4mtAcF4EBoYYtv3GtrPqAn2gVGUMUKgkfzJFl0lrO3bZH8CEKO; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.58]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NXhwD-0006oG-UU for oauth@ietf.org; Wed, 20 Jan 2010 14:18:06 -0700 Message-ID: <4B57731F.40406@KingsMountain.com> Date: Wed, 20 Jan 2010 13:18:23 -0800 From: =JeffH User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: IETF OAuth WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [OAUTH-WG] fyi: RFC formatted versions of OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Jan 2010 21:18:12 -0000 Seems that a link to this thread (on the oauth-wrap-wg@ list).. RFC formatted versions of OAuth WRAP http://groups.google.com/group/oauth-wrap-wg/browse_thread/thread/700d5cf825541218# ..is appropriate to post to this list. I guess the filename for the oauth wrap i-d changed (to draft-hardt-oauth-01) between the time Dick sent the above msg to the oauth-wrap-wg@ list and the time he submitted the i-d. (I didn't think the I-D submission tool would allow an initial -01 rev, but whatever). I presume draft-hardt-oauth-01 will be discussed here on oauth@ietf.org, at least in terms of it as input to the IETF OAuth WG context. HTH, =JeffH From alexey.melnikov@isode.com Wed Jan 20 13:34:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194AF28C0F5 for ; Wed, 20 Jan 2010 13:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 H78VJTkWKN2c for ; Wed, 20 Jan 2010 13:34:28 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id F293A28C0D8 for ; Wed, 20 Jan 2010 13:34:27 -0800 (PST) Received: from [172.16.2.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 20 Jan 2010 21:34:22 +0000 Message-ID: <4B5776A9.3070301@isode.com> Date: Wed, 20 Jan 2010 21:33:29 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eran Hammer-Lahav References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HTTP Group , OAuth WG Subject: Re: [OAUTH-WG] Authentication-Info Header X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Jan 2010 21:34:29 -0000 Eran Hammer-Lahav wrote: > Any comments? Suggestions? Hi Eran, Speaking as an individual contributor: > EHL > > On 12/4/09 9:19 AM, "Eran Hammer-Lahav" wrote: > > The Authentication-Info header should be added to > draft-ietf-httpbis-p7-auth to provide a complete list of all the > defined authentication headers. > Yes. > It should generalize the definition to make it useful for new > authentication schemes: > > The Authentication-Info header is used by the server to communicate > some information regarding the successful authentication in the > response. > The Authentication-Info header is allowed in the trailer of an HTTP > message transferred via chunked transfer-coding. > As long as this is consistent with existing usage (I don't remember of the top of my head how Negotiate works and whether it is using this header field). > Authentication-Info = "Authentication-Info" ":" OWS > Authentication-Info-v > Authentication-Info-v = 1#auth-param > > And should probably (finally) define Proxy-Authentication-Info > which is only mentioned in passing in 2617. > Yes. > It is also not clear if the Authentication-Info header can (or is > appropriate) together with a new WWW-Authenticate challenge. > Sure. I am not sure I can provide an opinion on this, as I am not an implementor. > --- > > Also, for OAuth, we are looking for a place to provide > authentication error information. The current definition of > Authentication-Info limits it use to successful authentications. > While I can certainly argue that an error is "some information > regarding the successful authentication", (i.e. that it was not), > it seems to violate the spirit of the text. > > I am not aware of other authentication schemes using this header > than Digest, and since Digest limits the allowed values, extending > this header field to mean *any* status information (not just > successful) should not break or change any existing implementation. > > If the definition remains the same, we will need to decide between > minting a new header Authentication-Error (and corresponding > Proxy-Authentication-Error), or find a way to stick the error > information together with a new challenge or as masked as new > challenge. I am not excited about the latter option, especially > given the possibility of multiple challenges in a single header. > > EHL > From julian.reschke@gmx.de Thu Jan 21 01:23:03 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BDF3A68E7 for ; Thu, 21 Jan 2010 01:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[AWL=-1.012, 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 Fsv3Gkuzdzki for ; Thu, 21 Jan 2010 01:23:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1ABE33A635F for ; Thu, 21 Jan 2010 01:23:01 -0800 (PST) Received: (qmail invoked by alias); 21 Jan 2010 09:22:56 -0000 Received: from p508FFD37.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.253.55] by mail.gmx.net (mp067) with SMTP; 21 Jan 2010 10:22:56 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/AIlFvj93AwnUVgR46MNUqPDHzEmk/1mQ3pv7xCa rB9LcnuAtwyXw6 Message-ID: <4B581CEC.4030609@gmx.de> Date: Thu, 21 Jan 2010 10:22:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Cc: HTTP Group , OAuth WG Subject: Re: [OAUTH-WG] Authentication-Info Header X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jan 2010 09:23:03 -0000 Eran Hammer-Lahav wrote: > > Any comments? Suggestions? Sorry for the delay. It was on my TODO list, but that list got too long. > EHL > > On 12/4/09 9:19 AM, "Eran Hammer-Lahav" wrote: > > The Authentication-Info header should be added to > draft-ietf-httpbis-p7-auth to provide a complete list of all the > defined authentication headers. It should generalize the definition > to make it useful for new authentication schemes: > ... As far as I can tell, Authentication-Info in RFC 2617 specific for Digest. If that's correct, it doesn't belong into HTTPbis P7. It may be a good idea to generalize it (I have no opinion on that), but it would still need to be specified in a spec other than HTTPbis. Best regards, Julian From y.oiwa@aist.go.jp Thu Jan 21 03:42:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE7C3A6984 for ; Thu, 21 Jan 2010 03:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pb3bk5vDld9 for ; Thu, 21 Jan 2010 03:42:16 -0800 (PST) Received: from faust.rcis.jp (faust.rcis.jp [61.194.89.210]) by core3.amsl.com (Postfix) with ESMTP id 114E83A6A19 for ; Thu, 21 Jan 2010 03:42:15 -0800 (PST) Received: from [192.168.1.198] (217.Red-81-34-139.dynamicIP.rima-tde.net [81.34.139.217]) (authenticated bits=0) by faust.rcis.jp (8.13.8/8.13.8/Debian-3) with ESMTP id o0LBfnsc016478; Thu, 21 Jan 2010 20:41:52 +0900 Message-ID: <4B583D79.4050500@aist.go.jp> Date: Thu, 21 Jan 2010 20:41:45 +0900 From: Yutaka Oiwa Organization: RCIS, AIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: HTTP Group , OAuth WG Subject: Re: [OAUTH-WG] Authentication-Info Header X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe:

= --_000_90C41DD21FB7C64BB94121FBBC2E723437899D25C8P3PW5EX1MB01E_-- From recordond@gmail.com Fri Jan 29 00:38:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31EE03A67EA for ; Fri, 29 Jan 2010 00:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_UNSUB38=0.777] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OoEx3IuRLJb for ; Fri, 29 Jan 2010 00:38:57 -0800 (PST) Received: from mail-iw0-f184.google.com (mail-iw0-f184.google.com [209.85.223.184]) by core3.amsl.com (Postfix) with ESMTP id F40393A6966 for ; Fri, 29 Jan 2010 00:38:56 -0800 (PST) Received: by iwn14 with SMTP id 14so1638102iwn.17 for ; Fri, 29 Jan 2010 00:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=lDKhQQPOP1L04YOFmvpHepvxtoN6pZQq7ZHJQBvEsYM=; b=U1rI/zCrVyPqSyQT90TbwRN0kUxa6m9cPEIc2Ex2mxZ2Hiufh3o4Cm3XHRVos3bXKi Fh99G8FZphzzo+9RNpTwmgIuob4z+PHGUqJosPWjklx8cNBGaQITuGvicJr1BmSx0TL4 O6vfJZVEjY0+FOZi4V7/woxyftYq1GxiRQzUU= 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=QUZBk9iv72JDGChCiV/g6V81xLR6kpEe4jnBJ4h7rcR1N440wx2mkevC3B5q634j1g jwvx/8zoPbfgNodxi4HxaeSQ8BNv6aM9TSEY9L5YeIE2eRrVKPkl6Rd4SLiCM36XyY/y jXf+qfltE01E8eygripdxfXrv7nGJAkbDyOJs= MIME-Version: 1.0 Received: by 10.231.158.21 with SMTP id d21mr580974ibx.61.1264754355625; Fri, 29 Jan 2010 00:39:15 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437899D25C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B61AFF0.6060302@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437899D25C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 29 Jan 2010 00:39:15 -0800 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=005045015a061860fc047e499235 Cc: OAuth WG Subject: Re: [OAUTH-WG] terminology X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 08:38:58 -0000 --005045015a061860fc047e499235 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Of course. :) On Fri, Jan 29, 2010 at 12:13 AM, Eran Hammer-Lahav wr= ote: > Hopefully by 1.0 you mean draft-hammer-oauth, not the community edition > with its =93Consumer Key=94 and other inventions. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *David Recordon > *Sent:* Thursday, January 28, 2010 10:35 PM > *To:* Peter Saint-Andre; Luke Shepard > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] terminology > > > > Hey Peter, > > Luke put together a spreadsheet comparing the terminology across five or > six different protocols. Hopefully he'll share it. :) > > > > I have a pretty strong preference of sticking with OAuth 1.0 terminology = as > much as possible. > > > > --David > > On Thu, Jan 28, 2010 at 7:40 AM, Peter Saint-Andre > wrote: > > One of the topics discussed during our conference call last week was the > matter of terminology. All agreed that we need to gain clarity and > consensus regarding the terms we use. To help us achieve that, I've > created a stub wiki page: > > http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthTerms > > If you don't yet have a wiki account, please go here: > > http://tools.ietf.org/newlogin > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --005045015a061860fc047e499235 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Of course. :)

On Fri, Jan 29, 2010 at 12:= 13 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Hopefully by 1.0 you mea= n draft-hammer-oauth, not the community edition with its =93Consumer Key=94= and other inventions.

=A0
EHL
=A0

From: oauth-bounces@ietf.org [mailto:= oauth-bounces@i= etf.org] On Behalf Of David Recordon
Sent: Thursday, January 28, 2010 10:35 PM
To: Peter Saint-= Andre; Luke Shepard
Cc: OAuth WG
Subject: Re: [OAUTH-WG= ] terminology
=A0
Hey Peter,
Luk= e put together a spreadsheet comparing the terminology=A0across=A0five or s= ix different protocols. =A0Hopefully he'll share it. :)
<= p class=3D"MsoNormal"> =A0
I have a pretty strong preference = of sticking with OAuth 1.0 terminology as much as possible.
<= p class=3D"MsoNormal">=A0
--David
On Thu, Jan 28, 2010 at 7:40 AM, Pet= er Saint-Andre <= stpeter@stpeter.im> wrote:
One of the topics discussed during our conference call last week was thematter of terminology. All agreed that we need to gain clarity and
cons= ensus regarding the terms we use. To help us achieve that, I've
created a stub wiki page:

http://trac.tools.ietf.org/wg/= oauth/trac/wiki/OauthTerms

If you don't yet have a wiki acco= unt, please go here:

http://too= ls.ietf.org/newlogin

Peter

= --
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
O= Auth mailing list
OA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=A0

--005045015a061860fc047e499235-- From eran@hueniverse.com Fri Jan 29 00:42:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6094628C125 for ; Fri, 29 Jan 2010 00:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.207, 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 hfme1PZm+r3m for ; Fri, 29 Jan 2010 00:42:56 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2EA4128C132 for ; Fri, 29 Jan 2010 00:42:56 -0800 (PST) Received: (qmail 21273 invoked from network); 29 Jan 2010 08:43:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 Jan 2010 08:43:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 29 Jan 2010 01:43:13 -0700 From: Eran Hammer-Lahav To: Luke Shepard , David Recordon Date: Fri, 29 Jan 2010 01:43:11 -0700 Thread-Topic: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication Thread-Index: AcqgrPOi0FTartjmRxaABHr563lNewAC2oRMAADHEsA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437899D25CF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jan 2010 08:42:58 -0000 > -----Original Message----- > From: Luke Shepard [mailto:lshepard@facebook.com] > Sent: Thursday, January 28, 2010 11:55 PM > > We have no business telling servers what they MUST implement (they > > might consider S-Plain too weak for their needs) > > Of all the negatives I listed below about SSL, being insecure was not one= of > them. I'm very interested in hearing real world use cases where you think > SSL will be too insecure? Having to go through intermediaries is one. You are also limiting your review to symmetric secrets in which there is li= ttle difference between sending the secret or using it to sign something (a= ssuming the secret remains secret and you prevent MITM). But using asymmetr= ic secrets to sign requests offers more protections such as preventing the = server from being able to imitate the client. It also doesn't need to be insecure, just not acceptable in the environment= it is deployed. For example, it can be wasteful over a VPN connection or i= llegal in some countries. > > But the advantage is that I do not mandate Facebook to do anything it > doesn't want. > > I would rather mandate that the Service Provider support something extra > than require it in every client. But it goes much beyond 'supporting something extra'. Either S-Plain is goo= d enough for everything or it's not. If it is, we should just mandate it an= d forget about the rest. But as your analysis clearly shows, there are case= s where it is not appropriate. What if I have a service with only large API= clients? > > Any OAuth 2.0 client will work with Facebook. It is true that writing a= fully > compliant client will require more work. > > If it's more work to write libraries, then fewer libraries will be writte= n, and > they will be less well maintained. My primary goal with this spec is to m= ake > adoption as easy as possible and supported on as many platforms as > possible. Part of the point of adopting a spec is you get to share code a= cross > libraries. If we start by saying "you'll have a different client library = for each > service" then doesn't that defeat the point? This reflects your specific needs. Your view is that your users will most l= ikely use S-Plain but that some large (and more sophisticated) clients will= use signatures. It sounds to me like you don't really care much about help= ing the big guys because they should be able to write their own custom libr= aries. If we create an environment where no one ever bothers to implement t= he more advanced features because they don't have to, we might as well not = bother including them. A big part of our work is to figure out what is core and what is not. I thi= nk signatures are core and consider the use of asymmetric secrets in OAuth = as critical for the future of the web. If you consider protocols like Salmo= n where pre-registration is not likely, being able to establish a client id= entity simply by publishing a public key using discovery and using that to = sign OAuth requests is an important use case. If Facebook, Yahoo, Google, Microsoft, and others will all support S-Plain,= you will have libraries that work across many services, not just one, and = I think this is a very likely scenario considering the interest these vendo= rs have in adopting WRAP. As an aside, I don't buy the argument (when it comes from the likes of the = companies behind WRAP) that we should put the amateur developer on a pedest= al and design web architecture to meet their needs. It is pathetic that the= se companies have failed to produce quality open source libraries or make a= significant contribution to them over the past two years. That includes my= own employer (at least they pay for all the editorial work and documentati= on I produce). EHL > > On 1/28/10 10:33 PM, "David Recordon" wrote: > On Thu, Jan 28, 2010 at 7:10 PM, Eran Hammer-Lahav > wrote: > (For the sake of simplicity, I am going to refer to the Plain bearer toke= n with > SSL/TLS as S-Plain) WRAP appeal is also its limitation and (strictly as w= ritten) it > sacrifices security for client ease. We still don't know what OAuth 2.0 i= s (it is > *not* WRAP, but likely to include ideas from it). > How is security sacrificed in the S-Plain method proposed for OAuth 2.0? = I > understand that WRAP makes sacrifices, but am I missing something in term= s > of moving a Plain bearer token always over SSL/TLS when making > authentication requests? > The problem I have with your approach is that you are mandating server > deployment and given that this is a security protocol, we have no busines= s > telling servers what they MUST implement (they might consider S-Plain too > weak for their needs). There are many reasons why vendors would rather > not use the S-Plain option (you listed some of those) for every protected > resource request. There are also many reasons why vendors would only > support S-Plain and no signature option. > My proposal allows you to do everything you have asked for and your > developers will have an easy life with the S-Plain option, or performance= / > flexibility with one of the HMAC methods. But the advantage is that I do = not > mandate Facebook to do anything it doesn't want. Any OAuth 2.0 client wil= l > work with Facebook. > It is true that writing a fully compliant client will require more work. = But the > whole point of the S-Plain option is that it requires *no* additional lib= rary > beyond having SSL/TLS available. So this is a vendor support issue - if y= ou > want to enable a library-less client development, offer S-Plain. This aga= in, is a > vendor choice. > Yes, but the tradeoff here is that a client will have S-Plain plus two or= three > other algorithms. The library size is increased, the complexity is incre= ased, > and it encourages servers (like Facebook) to develop separate libraries w= hich > only support the one or two methods they have chosen to use. Luke and I > would like to avoid creating Facebook specific client libraries. (This i= s of > course based on the assumption that the majority of implementations will > adopt S-Plain. We then envision an advanced client library which also > implements HMAC SHA-256.) Also keep in mind that the current proposal > moves the algorithm choice to the token request/issue phase. Each token > will only work with a single algorithm (which is better cryptographic hyg= iene). > So a vendor can choose to allow the client to pick the algorithm they wan= t to > you, or just tell them which one they are going to use. > > EHL > > > > From: Luke Shepard [mailto:lshepard@facebook.com] > Sent: Thursday, January 28, 2010 6:36 PM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth > communication > > > Thanks for the detailed reply, Eran. > > I think that your proposed design has it backwards: servers should bear > complexity and one-time costs, not clients. Much of why I think OAuth WRA= P > / 2.0 is so appealing is that it dramatically simplifies life for develop= ers. If a > client can support SSL and doesn't want to deal with signatures, then the= y > never should have to. I want to be able to write a very lightweight SSL-o= nly > client library that is still fully OAuth 2.0 compatible. > > I think instead, the consensus should be: > * Support an extensible set of signature algorithms * Servers required to > support plaintext tokens over a secure channel (SSL/TLS) * Servers requir= ed > to support at least one or a small subset of encryption algorithms. Possi= ble > candidates include hmac-sha-1, hmac-sha-256, and rsassa.... > * Clients must support at least ONE of the required encryption methods > > If a client supports at least one of the required methods (SSL or one of = the > algorithms), then it can be considered fully OAuth 2.0 compliant. If it o= nly > supports encryption methods that are not in the required list, then it is > partially compliant - that is, it may work with a specific vendor that ad= vertises > support for that algorithm, but it won't work with all servers. As algori= thms > gradually change over time, client libraries can be upgraded while server= s > need to maintain backwards compatibility. (For example, Facebook will > deprecate MD5 as its sig algorithm, but will continue to support it for t= he > clients using it in the wild) > > As a concrete example of what can be written when you don't need to worry > about encryption, see: http://github.com/lshepard/oauth-wrap- > demo/tree/master/src/wrap.js > If I were to modify that JS to accommodate multiple signature algorithms, > then I would need to include at least another 1-2k of JavaScript for each > method just in case. That would be fairly ridiculous. > > > On 1/28/10 1:41 PM, "Eran Hammer-Lahav" > wrote: > Thanks Luke. This is a useful analysis. > > I believe we have already reached consensus in this regard: > > * Support an extensible set of signature algorithms > * Define hmac-sha-1, hmac-sha-256, and rsassa-pkcs1-v1.5-sha-256 > * Define a plain method for bearer tokens and either require SSL/TLS or > strongly recommend it (open issue) > > (if these assumptions are incorrect, raise your hand now) > > The specification is going to define the four methods above (and possibly > more) as *must implement*. This does not mean vendors have to support all > of them, but that any *client* library or application claiming to be 'OAu= th 2.0 > compliant' must implement all these methods. > > If a vendor issues tokens not using all these methods (which is more like= ly), it > does not have to implement all these methods and can still be called 'OAu= th > 2.0 compliant' because any it can interop with *any* compliant library. > However, if such a vendor produces a client library for its developers wh= ich > only implements the methods deployed by the vendor, that library is 'OAut= h > 2.0 partially compliant' (because it will not interop with *all* vendors)= . > > In practice, from Facebook's perspective, you will be able to deploy OAut= h > 2.0 in a compliant way, while only implementing the methods that you find > suitable for your developers. It sounds like you will be using the plain = method > over SSL and either hmac-sha-1 or hmac-sha-256. Since Facebook usually > makes things trivial for its developers, I expect Facebook to produce lib= raries > that will implement these two methods, but not others. This will be a > 'Facebook API' library that uses OAuth 2.0. It will be partially complian= t but > this only means it is only guaranteed to work with Facebook, but that it = does > so in a fully compliant way. > > EHL > > > > > > From: oauth-bounces@ietf.org bounces@ietf.org> [mailto:oauth-bounces@ietf.org] On Behalf Of Luke > Shepard > Sent: Thursday, January 28, 2010 7:30 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Discussion of SSL as the primary means for OAuth > communication > > In the discussions around the OAuth WRAP spec, one of the questions often > asked is, "why use SSL exclusively?" Several of us have done a lot of thi= nking > on it and I wanted to articulate my understanding of the pros and cons of= the > approach for discussion. The use case I primarily have in mind is that of= a web > service, like Facebook, Twitter, or Google services. Our service is prima= rily > authenticated via the Web, but we have a use for all of the WRAP profiles > (web app, client app, desktop, mobile). > > Overall, I think that the simplicity of using SSL outweighs all the assoc= iated > costs for most developers. However, we should offer plaintext signatures = as > an optional performance enhancement for advanced developers. > > =3D=3D Advantages of using SSL for API calls > > -- It's overwhelmingly simpler for developers. > I've implemented OpenID and OAuth, and I've worked for years with > developers trying to handle signatures on the Facebook Platform. In my > experience, calculating signatures is one of the most complex and difficu= lt > parts of an authentication protocol, and developers often get it wrong. B= y > moving that piece down the stack we can get it out of their way and let > developers focus on building their apps. > > -- Existing tools ecosystem > It's not that SSL is a simpler encryption protocol than OAuth (it's not) = but > rather that commonly available tools almost universally support it - ever= y > major web browser, as well as most libraries for making HTTP requests (li= ke > curl) have built-in support for SSL. For OAuth 1.0, you need to use a cli= ent > library just to construct your very first request. > > -- Smaller client libraries > A good chunk of code in many client libraries is devoted to calculating a= nd > verifying signatures. For example, the OpenID PHP library imports several > BigMath modules and encryption schemes. Even the relatively simpler > Facebook client library requires several functions to sign requests. This > makes the client libraries a black box and impedes understanding. > > Wouldn't it be great if we could write a protocol that doesn't even requi= re a > client library to implement? If I could just make an authenticated API re= quest > in my browser, as easily as with Basic Auth? > > =3D=3D Disadvantages of using SSL for API calls > > -- Difficulties of debugging > > Both signatures and SSL present difficulties in debugging, but they tend = to be > different. While with signatures you worry about composing the arguments > wrong or using the wrong algorithm, with SSL you worry about reading the > request over the wire. You can't sniff a request, and to intercept it, yo= u need > an HTTP proxy that understands SSL, and you need to worry about invalid > certificate errors. To aid in this, providers will probably offer a non-S= SL > endpoint for debugging, but they may need to set up a sandbox > environment to prevent damage from tokens exposed in plaintext. > > -- Variable costs for providers > > Server CPU costs will increase when handling SSL requests - especially on > every API call instead of just at the auth stage. At scale, this can beco= me > expensive, although it can be offset by using specialized hardware to > terminate the SSL connection. All the big companies I've talked to are > comfortable trading these higher costs for increased adoption due to the > simplicity. > > -- Fixed costs for smaller providers > > There is a fixed cost to obtaining and signing an SSL certificates, altho= ugh that > has dropped in recent years such that an operator can have a cert signed = for > a single domain for pretty cheap. > > -- Latency > > SSL connections take more time to establish than normal HTTP connections. > Servers can use specialized hardware to speed it up, but clients rarely d= o, > which means that for client-to-server API requests, there may be some > higher latency in each request. Smaller, mobile devices may be > disproportionately affected by this, but as they grow more powerful it's = less > of a concern. Already today newer phones can handle SSL just fine. > > -- Browser limitations for cross domain communication > > A more niche disadvantage is that some cross domain communication > techniques require the protocol of the parent page to match that of the > endpoint being queried. So for example, in some browsers, for some API > calls, it would be impossible to make an API call to an HTTPS endpoint fr= om a > normal HTTP page. However, as browsers advance and HTML5 methods like > postMessage become more common, this will become less of an issue. > > -- Verifying information on the relying party > > If information is passed from a Service Provider to a Consumer through th= e > user's browser, then that information cannot be verified without an API c= all, > unless a signature is provided. Similar to stateful vs. stateless mode in= the > OpenID 2.0 spec, the signature can serve as a performance enhancement to > avoid an API call. > > =3D=3D Providing a non-SSL option for the short head > > Most platforms tend to have a small number of fairly large developers and > then a really large number of smaller developers. The former are typicall= y > experienced (or at least, they are by the time they get big) and have mad= e a > large investment in the platform. The latter range from experienced > developers to amateurs to folks that would not typically program. For thi= s > spec to be successful, it must meet the needs of both groups. > > Facebook is very interested in adopting OAuth WRAP / 2.0 / whatever > because we want to help our long tail developers use our platform more > easily. For the long tail, the simplicity provided by SSL will be crucial= . It means > smaller or nonexistent client libaries, it means that developers can just= try > out the API by typing it into a web browser, and it will help reduce debu= gging > and maintenance costs. > > However, for the short head of high volume developers, we probably want > an option to use something other than SSL to make secure requests. These > developers tend to have already solved the low hanging performance fruit, > and for them it may be a significant penalty to pay the SSL connection co= st on > every request. To that end, I think it's pretty important that OAuth 2.0 > support a method other than SSL as an option for advanced developers. But > it should be just that - an option, and only for advanced developers, so = that > beginning programmers and folks learning an API don't need to worry about > signatures when they just want to play around. > > Please let me know if I'm missing something or if my assumptions sound > incorrect. > > -Luke Shepard > Software Engineer, Facebook Platform > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From john.hurliman@intel.com Fri Jan 29 10:14:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B1F3A6359 for ; Fri, 29 Jan 2010 10:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.05 X-Spam-Level: X-Spam-Status: No, score=-6.05 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x7=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 rvDwRf5dqg-G for ; Fri, 29 Jan 2010 10:14:08 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 221F03A6A2A for ; Fri, 29 Jan 2010 10:14:02 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 29 Jan 2010 10:12:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.49,369,1262592000"; d="scan'208,217";a="591564365" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by orsmga001.jf.intel.com with ESMTP; 29 Jan 2010 10:13:56 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Fri, 29 Jan 2010 11:13:59 -0700 From: "Hurliman, John" To: "oauth@ietf.org" Date: Fri, 29 Jan 2010 11:13:55 -0700 Thread-Topic: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication Thread-Index: AcqgrPfOGBNEmkaqSUuZKa5RikmUIAADBKBgABU4nJA= Message-ID: <62BFE5680C037E4DA0B0A08946C0933DC746B868@rrsmsx506.amr.corp.intel.com> References: <90C41DD21FB7C64BB94121FBBC2E723437899D24CF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437899D258E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437899D25C7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437899D25C7@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_62BFE5680C037E4DA0B0A08946C0933DC746B868rrsmsx506amrcor_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jan 2010 18:14:27 -0000 --_000_62BFE5680C037E4DA0B0A08946C0933DC746B868rrsmsx506amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm fine with letting the market decide whether to use SSL or implement the= ir own crypto in libraries (I know our implementations will choose SSL-only= ), but that means we'll be going from fully compliant with OAuth WRAP to pa= rtially compliant with OAuth 2.0 by making the same choices. Some concern w= as raised that the client library offerings will fragment because of this, = but I think it's more likely there will just be two versions of OAuth 2.0 c= lient libraries. The thin SSL-only version of the library used by Facebook,= VWRAP, and anyone else that is fine with the SSL mode, and the thick clien= t lib used by vendors that require other modes. John From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, January 29, 2010 12:12 AM To: David Recordon Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth co= mmunication For one, we know never to assume that SSL is implemented correctly (not in = terms of the libraries but how certificate exceptions are handled and how i= ts defenses can be compromised). S-Plain also exposes the secret to interme= diaries while signatures can pass through without being compromised. I am s= ure Ben Laurie and others can list more differences (and hope they will). I disagree with your second comment about client library size. Typically if= you have one crypto algorithm, you have many others available. And if you = are suggesting that by requiring only S-Plain it will enable crypto-less li= braries, I would rather the community avoided producing such limited *libra= ries*. If we make it ok not to support signatures in generic libraries, it = will make it even harder for vendors to offer them. At the end, the market will decide between signatures and S-Plain, the same= way the RSA method in OAuth 1.0 gained very little traction (mostly becaus= e it was underspecified IMO). I don't think we should make that decision he= re. EHL From: David Recordon [mailto:recordond@gmail.com] Sent: Thursday, January 28, 2010 10:33 PM To: Eran Hammer-Lahav Cc: Luke Shepard; oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth co= mmunication On Thu, Jan 28, 2010 at 7:10 PM, Eran Hammer-Lahav > wrote: (For the sake of simplicity, I am going to refer to the Plain bearer token = with SSL/TLS as S-Plain) WRAP appeal is also its limitation and (strictly as written) it sacrifices = security for client ease. We still don't know what OAuth 2.0 is (it is *not= * WRAP, but likely to include ideas from it). How is security sacrificed in the S-Plain method proposed for OAuth 2.0? I= understand that WRAP makes sacrifices, but am I missing something in terms= of moving a Plain bearer token always over SSL/TLS when making authenticat= ion requests? The problem I have with your approach is that you are mandating server depl= oyment and given that this is a security protocol, we have no business tell= ing servers what they MUST implement (they might consider S-Plain too weak = for their needs). There are many reasons why vendors would rather not use t= he S-Plain option (you listed some of those) for every protected resource r= equest. There are also many reasons why vendors would only support S-Plain = and no signature option. My proposal allows you to do everything you have asked for and your develop= ers will have an easy life with the S-Plain option, or performance / flexib= ility with one of the HMAC methods. But the advantage is that I do not mand= ate Facebook to do anything it doesn't want. Any OAuth 2.0 client will work= with Facebook. It is true that writing a fully compliant client will require more work. Bu= t the whole point of the S-Plain option is that it requires *no* additional= library beyond having SSL/TLS available. So this is a vendor support issue= - if you want to enable a library-less client development, offer S-Plain. = This again, is a vendor choice. Yes, but the tradeoff here is that a client will have S-Plain plus two or t= hree other algorithms. The library size is increased, the complexity is in= creased, and it encourages servers (like Facebook) to develop separate libr= aries which only support the one or two methods they have chosen to use. L= uke and I would like to avoid creating Facebook specific client libraries. = (This is of course based on the assumption that the majority of implementa= tions will adopt S-Plain. We then envision an advanced client library whic= h also implements HMAC SHA-256.) Also keep in mind that the current proposal moves the algorithm choice to t= he token request/issue phase. Each token will only work with a single algor= ithm (which is better cryptographic hygiene). So a vendor can choose to all= ow the client to pick the algorithm they want to you, or just tell them whi= ch one they are going to use. EHL From: Luke Shepard [mailto:lshepard@facebook.com] Sent: Thursday, January 28, 2010 6:36 PM To: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth co= mmunication Thanks for the detailed reply, Eran. I think that your proposed design has it backwards: servers should bear com= plexity and one-time costs, not clients. Much of why I think OAuth WRAP / 2= .0 is so appealing is that it dramatically simplifies life for developers. = If a client can support SSL and doesn't want to deal with signatures, then = they never should have to. I want to be able to write a very lightweight SS= L-only client library that is still fully OAuth 2.0 compatible. I think instead, the consensus should be: * Support an extensible set of signature algorithms * Servers required to support plaintext tokens over a secure channel (SS= L/TLS) * Servers required to support at least one or a small subset of encrypti= on algorithms. Possible candidates include hmac-sha-1, hmac-sha-256, and rs= assa.... * Clients must support at least ONE of the required encryption methods If a client supports at least one of the required methods (SSL or one of th= e algorithms), then it can be considered fully OAuth 2.0 compliant. If it o= nly supports encryption methods that are not in the required list, then it = is partially compliant - that is, it may work with a specific vendor that a= dvertises support for that algorithm, but it won't work with all servers. A= s algorithms gradually change over time, client libraries can be upgraded w= hile servers need to maintain backwards compatibility. (For example, Facebo= ok will deprecate MD5 as its sig algorithm, but will continue to support it= for the clients using it in the wild) As a concrete example of what can be written when you don't need to worry a= bout encryption, see: http://github.com/lshepard/oauth-wrap-demo/tree/maste= r/src/wrap.js If I were to modify that JS to accommodate multiple signature algorithms, t= hen I would need to include at least another 1-2k of JavaScript for each me= thod just in case. That would be fairly ridiculous. On 1/28/10 1:41 PM, "Eran Hammer-Lahav" > wrote: Thanks Luke. This is a useful analysis. I believe we have already reached consensus in this regard: * Support an extensible set of signature algorithms * Define hmac-sha-1, hmac-sha-256, and rsassa-pkcs1-v1.5-sha-256 * Define a plain method for bearer tokens and either require SSL/TLS or str= ongly recommend it (open issue) (if these assumptions are incorrect, raise your hand now) The specification is going to define the four methods above (and possibly m= ore) as *must implement*. This does not mean vendors have to support all of= them, but that any *client* library or application claiming to be 'OAuth 2= .0 compliant' must implement all these methods. If a vendor issues tokens not using all these methods (which is more likely= ), it does not have to implement all these methods and can still be called = 'OAuth 2.0 compliant' because any it can interop with *any* compliant libra= ry. However, if such a vendor produces a client library for its developers = which only implements the methods deployed by the vendor, that library is '= OAuth 2.0 partially compliant' (because it will not interop with *all* vend= ors). In practice, from Facebook's perspective, you will be able to deploy OAuth = 2.0 in a compliant way, while only implementing the methods that you find s= uitable for your developers. It sounds like you will be using the plain met= hod over SSL and either hmac-sha-1 or hmac-sha-256. Since Facebook usually = makes things trivial for its developers, I expect Facebook to produce libra= ries that will implement these two methods, but not others. This will be a = 'Facebook API' library that uses OAuth 2.0. It will be partially compliant = but this only means it is only guaranteed to work with Facebook, but that i= t does so in a fully compliant way. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Luke Shepard Sent: Thursday, January 28, 2010 7:30 AM To: oauth@ietf.org Subject: [OAUTH-WG] Discussion of SSL as the primary means for OAuth commun= ication In the discussions around the OAuth WRAP spec, one of the questions often a= sked is, "why use SSL exclusively?" Several of us have done a lot of thinki= ng on it and I wanted to articulate my understanding of the pros and cons o= f the approach for discussion. The use case I primarily have in mind is tha= t of a web service, like Facebook, Twitter, or Google services. Our service= is primarily authenticated via the Web, but we have a use for all of the W= RAP profiles (web app, client app, desktop, mobile). Overall, I think that the simplicity of using SSL outweighs all the associa= ted costs for most developers. However, we should offer plaintext signature= s as an optional performance enhancement for advanced developers. =3D=3D Advantages of using SSL for API calls -- It's overwhelmingly simpler for developers. I've implemented OpenID and OAuth, and I've worked for years with developer= s trying to handle signatures on the Facebook Platform. In my experience, c= alculating signatures is one of the most complex and difficult parts of an = authentication protocol, and developers often get it wrong. By moving that = piece down the stack we can get it out of their way and let developers focu= s on building their apps. -- Existing tools ecosystem It's not that SSL is a simpler encryption protocol than OAuth (it's not) bu= t rather that commonly available tools almost universally support it - ever= y major web browser, as well as most libraries for making HTTP requests (li= ke curl) have built-in support for SSL. For OAuth 1.0, you need to use a cl= ient library just to construct your very first request. -- Smaller client libraries A good chunk of code in many client libraries is devoted to calculating and= verifying signatures. For example, the OpenID PHP library imports several = BigMath modules and encryption schemes. Even the relatively simpler Faceboo= k client library requires several functions to sign requests. This makes th= e client libraries a black box and impedes understanding. Wouldn't it be great if we could write a protocol that doesn't even require= a client library to implement? If I could just make an authenticated API r= equest in my browser, as easily as with Basic Auth? =3D=3D Disadvantages of using SSL for API calls -- Difficulties of debugging Both signatures and SSL present difficulties in debugging, but they tend to= be different. While with signatures you worry about composing the argument= s wrong or using the wrong algorithm, with SSL you worry about reading the = request over the wire. You can't sniff a request, and to intercept it, you = need an HTTP proxy that understands SSL, and you need to worry about invali= d certificate errors. To aid in this, providers will probably offer a non-S= SL endpoint for debugging, but they may need to set up a sandbox environmen= t to prevent damage from tokens exposed in plaintext. -- Variable costs for providers Server CPU costs will increase when handling SSL requests - especially on e= very API call instead of just at the auth stage. At scale, this can become = expensive, although it can be offset by using specialized hardware to termi= nate the SSL connection. All the big companies I've talked to are comfortab= le trading these higher costs for increased adoption due to the simplicity. -- Fixed costs for smaller providers There is a fixed cost to obtaining and signing an SSL certificates, althoug= h that has dropped in recent years such that an operator can have a cert si= gned for a single domain for pretty cheap. -- Latency SSL connections take more time to establish than normal HTTP connections. S= ervers can use specialized hardware to speed it up, but clients rarely do, = which means that for client-to-server API requests, there may be some highe= r latency in each request. Smaller, mobile devices may be disproportionatel= y affected by this, but as they grow more powerful it's less of a concern. = Already today newer phones can handle SSL just fine. -- Browser limitations for cross domain communication A more niche disadvantage is that some cross domain communication technique= s require the protocol of the parent page to match that of the endpoint bei= ng queried. So for example, in some browsers, for some API calls, it would = be impossible to make an API call to an HTTPS endpoint from a normal HTTP p= age. However, as browsers advance and HTML5 methods like postMessage become= more common, this will become less of an issue. -- Verifying information on the relying party If information is passed from a Service Provider to a Consumer through the = user's browser, then that information cannot be verified without an API cal= l, unless a signature is provided. Similar to stateful vs. stateless mode i= n the OpenID 2.0 spec, the signature can serve as a performance enhancement= to avoid an API call. =3D=3D Providing a non-SSL option for the short head Most platforms tend to have a small number of fairly large developers and t= hen a really large number of smaller developers. The former are typically e= xperienced (or at least, they are by the time they get big) and have made a= large investment in the platform. The latter range from experienced develo= pers to amateurs to folks that would not typically program. For this spec t= o be successful, it must meet the needs of both groups. Facebook is very interested in adopting OAuth WRAP / 2.0 / whatever because= we want to help our long tail developers use our platform more easily. For= the long tail, the simplicity provided by SSL will be crucial. It means sm= aller or nonexistent client libaries, it means that developers can just try= out the API by typing it into a web browser, and it will help reduce debug= ging and maintenance costs. However, for the short head of high volume developers, we probably want an = option to use something other than SSL to make secure requests. These devel= opers tend to have already solved the low hanging performance fruit, and fo= r them it may be a significant penalty to pay the SSL connection cost on ev= ery request. To that end, I think it's pretty important that OAuth 2.0 supp= ort a method other than SSL as an option for advanced developers. But it sh= ould be just that - an option, and only for advanced developers, so that be= ginning programmers and folks learning an API don't need to worry about sig= natures when they just want to play around. Please let me know if I'm missing something or if my assumptions sound inco= rrect. -Luke Shepard Software Engineer, Facebook Platform _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_62BFE5680C037E4DA0B0A08946C0933DC746B868rrsmsx506amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m fine with letting the market decide whether to use= SSL or implement their own crypto in libraries (I know our implementations will choose SSL-only), but that means we’ll be going from fully compliant = with OAuth WRAP to partially compliant with OAuth 2.0 by making the same choices= . Some concern was raised that the client library offerings will fragment bec= ause of this, but I think it’s more likely there will just be two versions= of OAuth 2.0 client libraries. The thin SSL-only version of the library used b= y Facebook, VWRAP, and anyone else that is fine with the SSL mode, and the th= ick client lib used by vendors that require other modes.

John

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Eran Hammer-Lahav
Sent: Friday, January 29, 2010 12:12 AM
To: David Recordon
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for O= Auth communication

For one, we know never to assume that SSL is implemented correctly (not in terms of the libraries but how certificate exceptions are handled and how its defenses can be compromised). S-Plain also exposes the secret to intermediaries while signatures can pass through without being compromised. I am sure Ben Laurie and others can list more differences (and hope they will).

I disagree with your second comment about client library siz= e. Typically if you have one crypto algorithm, you have many others available.= And if you are suggesting that by requiring only S-Plain it will enable crypto-= less libraries, I would rather the community avoided producing such limited *= libraries*. If we make it ok not to support signatures in generic libraries, it will ma= ke it even harder for vendors to offer them.

At the end, the market will decide between signatures and S-Plain, the same way the RSA method in OAuth 1.0 gained very little tracti= on (mostly because it was underspecified IMO). I don’t think we should m= ake that decision here.

EHL

From: David Recordo= n [mailto:recordond@gmail.com]
Sent: Thursday, January 28, 2010 10:33 PM
To: Eran Hammer-Lahav
Cc: Luke Shepard; oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for O= Auth communication

On Thu, Jan 28, 2010 at 7:10 PM, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:=

(For the sake of simplicity, I am = going to refer to the Plain bearer token with SSL/TLS as S-Plain)

WRAP appeal is also its limitation= and (strictly as written) it sacrifices security for client ease. We still don’t know what OAuth 2.0 is (it is *not* WRAP, but likely to include ideas from it).

How is security sacrificed in the S-Plain method propo= sed for OAuth 2.0? I understand that WRAP makes sacrifices, but am I miss= ing something in terms of moving a Plain bearer token always over SSL/TLS when making authentication requests?

The problem I have with your appro= ach is that you are mandating server deployment and given that this is a security protocol, we have no business telling servers what they MUST implement (the= y might consider S-Plain too weak for their needs). There are many reasons wh= y vendors would rather not use the S-Plain option (you listed some of those) = for every protected resource request. There are also many reasons why vendors w= ould only support S-Plain and no signature option.

My proposal allows you to do every= thing you have asked for and your developers will have an easy life with the S-Pl= ain option, or performance / flexibility with one of the HMAC methods. But the advantage is that I do not mandate Facebook to do anything it doesn’t want. Any OAuth 2.0 client will work with Facebook.

It is true that writing a fully compliant client will require more work. But the whole point of the S-Plain option is that it requires *no* additional library beyond having SSL= /TLS available. So this is a vendor support issue – if you want to enable = a library-less client development, offer S-Plain. This again, is a vendor cho= ice.

Yes, but the tradeoff here is that a client will have S-Plain plus two or three other algorithms. The library size is increased, the complexity is increased, and it encourages servers (like Facebook) to develop separate libraries which only support the one or two methods they have chosen to use. Luke and I would like to avoid creat= ing Facebook specific client libraries. (This is of course based on the assumption that the majority of implementations will adopt S-Plain. W= e then envision an advanced client library which also implements HMAC SHA-256= .)

Also keep in mind that the current proposal moves the algorithm choice to the token request/issue phase. Each token will only work with a single algorithm (which is better cryptographic hygiene). So a vendor can choose to allow the client to pick the algorithm = they want to you, or just tell them which one they are going to use.=

EHL

From: Luke Shepard [mailto:= lshepard@facebook.com]
Sent: Thursday, January 28, 2010 6:36 PM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for O= Auth communication

Thanks for the detailed reply, Eran.

I think that your proposed design has it backwards: servers should bear complexity and one-time costs, not clients. Much of why I think OAuth WRAP = / 2.0 is so appealing is that it dramatically simplifies life for developers.= If a client can support SSL and doesn’t want to deal with signatures, th= en they never should have to. I want to be able to write a very lightweight SSL-only client library that is still fully OAuth 2.0 compatible.

I think instead, the consensus should be:

Support an extensible set of signature algorithms

Servers requ= ired to support plaintext tokens over a secure channel (SSL/TLS)

Servers requ= ired to support at least one or a small subset of encryption algorithms. Possible candidates include hmac-sha-1, hmac-sha-256, and rsassa.... <= /span>

Clients must support at least ONE of the required encryption methods

If a client supports at least one of the required methods (SSL or one of th= e algorithms), then it can be considered fully OAuth 2.0 compliant. If it onl= y supports encryption methods that are not in the required list, then it is partially compliant – that is, it may work with a specific vendor tha= t advertises support for that algorithm, but it won’t work with all servers. As algorithms gradually change over time, client libraries can be upgraded while servers need to maintain backwards compatibility. (For examp= le, Facebook will deprecate MD5 as its sig algorithm, but will continue to supp= ort it for the clients using it in the wild)

As a concrete example of what can be written when you don’t need to w= orry about encryption, see: http://github.com/lshepard/oauth-wrap-demo/tree/master/sr= c/wrap.js
If I were to modify that JS to accommodate multiple signature algorithms, t= hen I would need to include at least another 1-2k of JavaScript for each method just in case. That would be fairly ridiculous.

On 1/28/10 1:41 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

Thanks Luke. This is a useful analysis.

I believe we have already reached consensus in this regard:

* Support an extensible set of signature algorithms
* Define hmac-sha-1, hmac-sha-256, and rsassa-pkcs1-v1.5-sha-256
* Define a plain method for bearer tokens and either require SSL/TLS or strongly recommend it (open issue)

(if these assumptions are incorrect, raise your hand now)

The specification is going to define the four methods above (and possibly m= ore) as *must implement*. This does not mean vendors have to support all = of them, but that any *client* library or application claiming to be ‘OAuth 2.0 compliant’ must implement all these methods.

If a vendor issues tokens not using all these methods (which is more likely= ), it does not have to implement all these methods and can still be called ‘OAuth 2.0 compliant’ because any it can interop with *any* compliant library. However, if such a vendor produces a client library for = its developers which only implements the methods deployed by the vendor, that l= ibrary is ‘OAuth 2.0 partially compliant’ (because it will not interop with *all* vendors).

In practice, from Facebook’s perspective, you will be able to deploy OAuth 2.0 in a compliant way, while only implementing the methods that you = find suitable for your developers. It sounds like you will be using the plain me= thod over SSL and either hmac-sha-1 or hmac-sha-256. Since Facebook usually make= s things trivial for its developers, I expect Facebook to produce libraries t= hat will implement these two methods, but not others. This will be a ‘Facebook API’ library that uses OAuth 2.0. It will be partiall= y compliant but this only means it is only guaranteed to work with Facebook, = but that it does so in a fully compliant way.

EHL

From: oauth-bounces@ietf.org [mailto:oauth-bounc= es@ietf.org] On Behalf Of Luke Shepard
Sent: Thursday, January 28, 2010 7:30 AM
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

In the discussions around the OAuth WRAP s= pec, one of the questions often asked is, “why use SSL exclusively?” Several of us have done a lot of thinking on it and I wanted to articulate = my understanding of the pros and cons of the approach for discussion. The use = case I primarily have in mind is that of a web service, like Facebook, Twitter, = or Google services. Our service is primarily authenticated via the Web, but we have a use for all of the WRAP profiles (web app, client app, desktop, mobi= le).

Overall, I think that the simplicity of using SSL outweighs all the associa= ted costs for most developers. However, we should offer plaintext signatures as= an optional performance enhancement for advanced developers.

=3D=3D Advantages of using SSL for API calls

-- It’s overwhelmingly simpler for developers.
I’ve implemented OpenID and OAuth, and I’ve worked for years wi= th developers trying to handle signatures on the Facebook Platform. In my experience, calculating signatures is one of the most complex and difficult parts of an authentication protocol, and developers often get it wrong. By moving that piece down the stack we can get it out of their way and let developers focus on building their apps.

-- Existing tools ecosystem
It’s not that SSL is a simpler encryption protocol than OAuth (itR= 17;s not) but rather that commonly available tools almost universally support it – every major web browser, as well as most libraries for making HTTP requests (like curl) have built-in support for SSL. For OAuth 1.0, you need= to use a client library just to construct your very first request.

-- Smaller client libraries
A good chunk of code in many client libraries is devoted to calculating and verifying signatures. For example, the OpenID PHP library imports several BigMath modules and encryption schemes. Even the relatively simpler Faceboo= k client library requires several functions to sign requests. This makes the client libraries a black box and impedes understanding.

Wouldn’t it be great if we could write a protocol that doesn’t = even require a client library to implement? If I could just make an authenticate= d API request in my browser, as easily as with Basic Auth?

=3D=3D Disadvantages of using SSL for API calls

-- Difficulties of debugging

Both signatures and SSL present difficulties in debugging, but they tend to= be different. While with signatures you worry about composing the arguments wr= ong or using the wrong algorithm, with SSL you worry about reading the request = over the wire. You can’t sniff a request, and to intercept it, you need an HTTP proxy that understands SSL, and you need to worry about invalid certificate errors. To aid in this, providers will probably offer a non-SSL endpoint for debugging, but they may need to set up a sandbox environment t= o prevent damage from tokens exposed in plaintext.

-- Variable costs for providers

Server CPU costs will increase when handling SSL requests – especiall= y on every API call instead of just at the auth stage. At scale, this can become expensive, although it can be offset by using specialized hardware to termi= nate the SSL connection. All the big companies I’ve talked to are comforta= ble trading these higher costs for increased adoption due to the simplicity.
-- Fixed costs for smaller providers

There is a fixed cost to obtaining and signing an SSL certificates, althoug= h that has dropped in recent years such that an operator can have a cert sign= ed for a single domain for pretty cheap.

-- Latency

SSL connections take more time to establish than normal HTTP connections. Servers can use specialized hardware to speed it up, but clients rarely do, which means that for client-to-server API requests, there may be some highe= r latency in each request. Smaller, mobile devices may be disproportionately affected by this, but as they grow more powerful it’s less of a conce= rn. Already today newer phones can handle SSL just fine.

-- Browser limitations for cross domain communication

A more niche disadvantage is that some cross domain communication technique= s require the protocol of the parent page to match that of the endpoint being queried. So for example, in some browsers, for some API calls, it would be impossible to make an API call to an HTTPS endpoint from a normal HTTP page= . However, as browsers advance and HTML5 methods like postMessage become more common, this will become less of an issue.

-- Verifying information on the relying party

If information is passed from a Service Provider to a Consumer through the user’s browser, then that information cannot be verified without an A= PI call, unless a signature is provided. Similar to stateful vs. stateless mod= e in the OpenID 2.0 spec, the signature can serve as a performance enhancement t= o avoid an API call.

=3D=3D Providing a non-SSL option for the short head

Most platforms tend to have a small number of fairly large developers and t= hen a really large number of smaller developers. The former are typically experienced (or at least, they are by the time they get big) and have made = a large investment in the platform. The latter range from experienced develop= ers to amateurs to folks that would not typically program. For this spec to be successful, it must meet the needs of both groups.

Facebook is very interested in adopting OAuth WRAP / 2.0 / whatever because= we want to help our long tail developers use our platform more easily. For the long tail, the simplicity provided by SSL will be crucial. It means smaller= or nonexistent client libaries, it means that developers can just try out the = API by typing it into a web browser, and it will help reduce debugging and maintenance costs.

However, for the short head of high volume developers, we probably want an = option to use something other than SSL to make secure requests. These developers t= end to have already solved the low hanging performance fruit, and for them it m= ay be a significant penalty to pay the SSL connection cost on every request. T= o that end, I think it’s pretty important that OAuth 2.0 support a meth= od other than SSL as an option for advanced developers. But it should be just = that – an option, and only for advanced developers, so that beginning programmers and folks learning an API don’t need to worry about signatures when they just want to play around.

Please let me know if I’m missing something or if my assumptions soun= d incorrect.

-Luke Shepard
Software Engineer, Facebook Platform

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

--_000_62BFE5680C037E4DA0B0A08946C0933DC746B868rrsmsx506amrcor_-- From hannes.tschofenig@nsn.com Fri Jan 29 11:24:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49AF53A6803 for ; Fri, 29 Jan 2010 11:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgGaj+5uY--c for ; Fri, 29 Jan 2010 11:24:18 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 69F4B3A67BD for ; Fri, 29 Jan 2010 11:24:18 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o0TJOdBa021406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Jan 2010 20:24:39 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0TJOdY3006028; Fri, 29 Jan 2010 20:24:39 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 20:24:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 21:24:39 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450220F59F@FIESEXC015.nsn-intra.net> In-Reply-To: <1562D46F-058C-4EE6-956C-469719CA3E81@xmlgrrl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] FYI, UMA webinar followup Thread-Index: AcqeDBRGfd5kq5nFSVCbT3Dk1QfSVQDAdHEA References: <1562D46F-058C-4EE6-956C-469719CA3E81@xmlgrrl.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Eve Maler" , "OAuth WG" X-OriginalArrivalTime: 29 Jan 2010 19:24:39.0526 (UTC) FILETIME=[B3707860:01CAA118] Subject: Re: [OAUTH-WG] FYI, UMA webinar followup X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jan 2010 19:24:20 -0000 I registered for the seminar, got the bridge info, dialed in and nobody was there.=20 Are there slides available?=20 >-----Original Message----- >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 >On Behalf Of ext Eve Maler >Sent: 25 January, 2010 14:03 >To: OAuth WG >Subject: [OAUTH-WG] FYI, UMA webinar followup > >I think I mentioned on last week's call that those of us=20 >working on UMA are doing a status update in a webinar on=20 >Thursday of this week. You're invited to sign up (there's a=20 >small handful of slots left). Info and registration link are here: > >http://kantarainitiative.org/confluence/display/uma/Meetings+an >d+Minutes > > Eve > >Eve Maler >eve@xmlgrrl.com >http://www.xmlgrrl.com/blog > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Fri Jan 29 11:25:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F893A67BD for ; Fri, 29 Jan 2010 11:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_BAYES_5x7=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 Y6YHfoEbzP0T for ; Fri, 29 Jan 2010 11:24:56 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9F5583A6961 for ; Fri, 29 Jan 2010 11:24:56 -0800 (PST) Received: (qmail 26963 invoked from network); 29 Jan 2010 19:25:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 Jan 2010 19:25:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 29 Jan 2010 12:25:14 -0700 From: Eran Hammer-Lahav To: "Hurliman, John" Date: Fri, 29 Jan 2010 12:25:01 -0700 Thread-Topic: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication Thread-Index: AcqhGMeMfejtCJdoSd+GzkYrkTw6ew== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723437899D24CF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437899D258E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437899D25C7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62BFE5680C037E4DA0B0A08946C0933DC746B868@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DC746B868@rrsmsx506.amr.corp.intel.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_A2CF729A181248C98C9623BAD0947C49hueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jan 2010 19:25:00 -0000 --_000_A2CF729A181248C98C9623BAD0947C49hueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91ciBzZXJ2ZXIgd2lsbCBiZSBmdWxseSBjb21wbGlhbnQuIEJ1dCBpZiB5b3UgcHJvZHVjZSBh IGxpYnJhcnkgdGhhdCBvbmx5IHN1cHBvcnRzIHlvdSBsaW1pdGVkIG5lZWRzLCBpdCB3aWxsIGJl IHBhcnRpYWxseSBjb21wbGlhbnQuDQoNCkVITA0KDQpPbiBKYW4gMjksIDIwMTAsIGF0IDEwOjU0 LCAiSHVybGltYW4sIEpvaG4iIDxqb2huLmh1cmxpbWFuQGludGVsLmNvbTxtYWlsdG86am9obi5o dXJsaW1hbkBpbnRlbC5jb20+PiB3cm90ZToNCg0KSeKAmW0gZmluZSB3aXRoIGxldHRpbmcgdGhl IG1hcmtldCBkZWNpZGUgd2hldGhlciB0byB1c2UgU1NMIG9yIGltcGxlbWVudCB0aGVpciBvd24g Y3J5cHRvIGluIGxpYnJhcmllcyAoSSBrbm93IG91ciBpbXBsZW1lbnRhdGlvbnMgd2lsbCBjaG9v c2UgU1NMLW9ubHkpLCBidXQgdGhhdCBtZWFucyB3ZeKAmWxsIGJlIGdvaW5nIGZyb20gZnVsbHkg Y29tcGxpYW50IHdpdGggT0F1dGggV1JBUCB0byBwYXJ0aWFsbHkgY29tcGxpYW50IHdpdGggT0F1 dGggMi4wIGJ5IG1ha2luZyB0aGUgc2FtZSBjaG9pY2VzLiBTb21lIGNvbmNlcm4gd2FzIHJhaXNl ZCB0aGF0IHRoZSBjbGllbnQgbGlicmFyeSBvZmZlcmluZ3Mgd2lsbCBmcmFnbWVudCBiZWNhdXNl IG9mIHRoaXMsIGJ1dCBJIHRoaW5rIGl04oCZcyBtb3JlIGxpa2VseSB0aGVyZSB3aWxsIGp1c3Qg YmUgdHdvIHZlcnNpb25zIG9mIE9BdXRoIDIuMCBjbGllbnQgbGlicmFyaWVzLiBUaGUgdGhpbiBT U0wtb25seSB2ZXJzaW9uIG9mIHRoZSBsaWJyYXJ5IHVzZWQgYnkgRmFjZWJvb2ssIFZXUkFQLCBh bmQgYW55b25lIGVsc2UgdGhhdCBpcyBmaW5lIHdpdGggdGhlIFNTTCBtb2RlLCBhbmQgdGhlIHRo aWNrIGNsaWVudCBsaWIgdXNlZCBieSB2ZW5kb3JzIHRoYXQgcmVxdWlyZSBvdGhlciBtb2Rlcy4N Cg0KSm9obg0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBFcmFuIEhhbW1lci1MYWhhdg0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDI5LCAyMDEwIDEyOjEy IEFNDQpUbzogRGF2aWQgUmVjb3Jkb24NCkNjOiA8bWFpbHRvOm9hdXRoQGlldGYub3JnPiBvYXV0 aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBEaXNjdXNzaW9uIG9mIFNTTCBhcyB0aGUgcHJpbWFyeSBtZWFucyBmb3IgT0F1dGggY29tbXVu aWNhdGlvbg0KDQpGb3Igb25lLCB3ZSBrbm93IG5ldmVyIHRvIGFzc3VtZSB0aGF0IFNTTCBpcyBp bXBsZW1lbnRlZCBjb3JyZWN0bHkgKG5vdCBpbiB0ZXJtcyBvZiB0aGUgbGlicmFyaWVzIGJ1dCBo b3cgY2VydGlmaWNhdGUgZXhjZXB0aW9ucyBhcmUgaGFuZGxlZCBhbmQgaG93IGl0cyBkZWZlbnNl cyBjYW4gYmUgY29tcHJvbWlzZWQpLiBTLVBsYWluIGFsc28gZXhwb3NlcyB0aGUgc2VjcmV0IHRv IGludGVybWVkaWFyaWVzIHdoaWxlIHNpZ25hdHVyZXMgY2FuIHBhc3MgdGhyb3VnaCB3aXRob3V0 IGJlaW5nIGNvbXByb21pc2VkLiBJIGFtIHN1cmUgQmVuIExhdXJpZSBhbmQgb3RoZXJzIGNhbiBs aXN0IG1vcmUgZGlmZmVyZW5jZXMgKGFuZCBob3BlIHRoZXkgd2lsbCkuDQoNCkkgZGlzYWdyZWUg d2l0aCB5b3VyIHNlY29uZCBjb21tZW50IGFib3V0IGNsaWVudCBsaWJyYXJ5IHNpemUuIFR5cGlj YWxseSBpZiB5b3UgaGF2ZSBvbmUgY3J5cHRvIGFsZ29yaXRobSwgeW91IGhhdmUgbWFueSBvdGhl cnMgYXZhaWxhYmxlLiBBbmQgaWYgeW91IGFyZSBzdWdnZXN0aW5nIHRoYXQgYnkgcmVxdWlyaW5n IG9ubHkgUy1QbGFpbiBpdCB3aWxsIGVuYWJsZSBjcnlwdG8tbGVzcyBsaWJyYXJpZXMsIEkgd291 bGQgcmF0aGVyIHRoZSBjb21tdW5pdHkgYXZvaWRlZCBwcm9kdWNpbmcgc3VjaCBsaW1pdGVkICps aWJyYXJpZXMqLiBJZiB3ZSBtYWtlIGl0IG9rIG5vdCB0byBzdXBwb3J0IHNpZ25hdHVyZXMgaW4g Z2VuZXJpYyBsaWJyYXJpZXMsIGl0IHdpbGwgbWFrZSBpdCBldmVuIGhhcmRlciBmb3IgdmVuZG9y cyB0byBvZmZlciB0aGVtLg0KDQpBdCB0aGUgZW5kLCB0aGUgbWFya2V0IHdpbGwgZGVjaWRlIGJl dHdlZW4gc2lnbmF0dXJlcyBhbmQgUy1QbGFpbiwgdGhlIHNhbWUgd2F5IHRoZSBSU0EgbWV0aG9k IGluIE9BdXRoIDEuMCBnYWluZWQgdmVyeSBsaXR0bGUgdHJhY3Rpb24gKG1vc3RseSBiZWNhdXNl IGl0IHdhcyB1bmRlcnNwZWNpZmllZCBJTU8pLiBJIGRvbuKAmXQgdGhpbmsgd2Ugc2hvdWxkIG1h a2UgdGhhdCBkZWNpc2lvbiBoZXJlLg0KDQpFSEwNCg0KDQpGcm9tOiBEYXZpZCBSZWNvcmRvbiBb bWFpbHRvOnJlY29yZG9uZEBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyOCwg MjAxMCAxMDozMyBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2DQpDYzogTHVrZSBTaGVwYXJkOyA8 bWFpbHRvOm9hdXRoQGlldGYub3JnPiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBEaXNjdXNzaW9uIG9mIFNTTCBhcyB0aGUgcHJp bWFyeSBtZWFucyBmb3IgT0F1dGggY29tbXVuaWNhdGlvbg0KDQpPbiBUaHUsIEphbiAyOCwgMjAx MCBhdCA3OjEwIFBNLCBFcmFuIEhhbW1lci1MYWhhdiA8PG1haWx0bzplcmFuQGh1ZW5pdmVyc2Uu Y29tPmVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PiB3cm90 ZToNCihGb3IgdGhlIHNha2Ugb2Ygc2ltcGxpY2l0eSwgSSBhbSBnb2luZyB0byByZWZlciB0byB0 aGUgUGxhaW4gYmVhcmVyIHRva2VuIHdpdGggU1NML1RMUyBhcyBTLVBsYWluKQ0KV1JBUCBhcHBl YWwgaXMgYWxzbyBpdHMgbGltaXRhdGlvbiBhbmQgKHN0cmljdGx5IGFzIHdyaXR0ZW4pIGl0IHNh Y3JpZmljZXMgc2VjdXJpdHkgZm9yIGNsaWVudCBlYXNlLiBXZSBzdGlsbCBkb27igJl0IGtub3cg d2hhdCBPQXV0aCAyLjAgaXMgKGl0IGlzICpub3QqIFdSQVAsIGJ1dCBsaWtlbHkgdG8gaW5jbHVk ZSBpZGVhcyBmcm9tIGl0KS4NCkhvdyBpcyBzZWN1cml0eSBzYWNyaWZpY2VkIGluIHRoZSBTLVBs YWluIG1ldGhvZCBwcm9wb3NlZCBmb3IgT0F1dGggMi4wPyAgSSB1bmRlcnN0YW5kIHRoYXQgV1JB UCBtYWtlcyBzYWNyaWZpY2VzLCBidXQgYW0gSSBtaXNzaW5nIHNvbWV0aGluZyBpbiB0ZXJtcyBv ZiBtb3ZpbmcgYSBQbGFpbiBiZWFyZXIgdG9rZW4gYWx3YXlzIG92ZXIgU1NML1RMUyB3aGVuIG1h a2luZyBhdXRoZW50aWNhdGlvbiByZXF1ZXN0cz8NCg0KVGhlIHByb2JsZW0gSSBoYXZlIHdpdGgg eW91ciBhcHByb2FjaCBpcyB0aGF0IHlvdSBhcmUgbWFuZGF0aW5nIHNlcnZlciBkZXBsb3ltZW50 IGFuZCBnaXZlbiB0aGF0IHRoaXMgaXMgYSBzZWN1cml0eSBwcm90b2NvbCwgd2UgaGF2ZSBubyBi dXNpbmVzcyB0ZWxsaW5nIHNlcnZlcnMgd2hhdCB0aGV5IE1VU1QgaW1wbGVtZW50ICh0aGV5IG1p Z2h0IGNvbnNpZGVyIFMtUGxhaW4gdG9vIHdlYWsgZm9yIHRoZWlyIG5lZWRzKS4gVGhlcmUgYXJl IG1hbnkgcmVhc29ucyB3aHkgdmVuZG9ycyB3b3VsZCByYXRoZXIgbm90IHVzZSB0aGUgUy1QbGFp biBvcHRpb24gKHlvdSBsaXN0ZWQgc29tZSBvZiB0aG9zZSkgZm9yIGV2ZXJ5IHByb3RlY3RlZCBy ZXNvdXJjZSByZXF1ZXN0LiBUaGVyZSBhcmUgYWxzbyBtYW55IHJlYXNvbnMgd2h5IHZlbmRvcnMg d291bGQgb25seSBzdXBwb3J0IFMtUGxhaW4gYW5kIG5vIHNpZ25hdHVyZSBvcHRpb24uDQpNeSBw cm9wb3NhbCBhbGxvd3MgeW91IHRvIGRvIGV2ZXJ5dGhpbmcgeW91IGhhdmUgYXNrZWQgZm9yIGFu ZCB5b3VyIGRldmVsb3BlcnMgd2lsbCBoYXZlIGFuIGVhc3kgbGlmZSB3aXRoIHRoZSBTLVBsYWlu IG9wdGlvbiwgb3IgcGVyZm9ybWFuY2UgLyBmbGV4aWJpbGl0eSB3aXRoIG9uZSBvZiB0aGUgSE1B QyBtZXRob2RzLiBCdXQgdGhlIGFkdmFudGFnZSBpcyB0aGF0IEkgZG8gbm90IG1hbmRhdGUgRmFj ZWJvb2sgdG8gZG8gYW55dGhpbmcgaXQgZG9lc27igJl0IHdhbnQuIEFueSBPQXV0aCAyLjAgY2xp ZW50IHdpbGwgd29yayB3aXRoIEZhY2Vib29rLg0KSXQgaXMgdHJ1ZSB0aGF0IHdyaXRpbmcgYSBm dWxseSBjb21wbGlhbnQgY2xpZW50IHdpbGwgcmVxdWlyZSBtb3JlIHdvcmsuIEJ1dCB0aGUgd2hv bGUgcG9pbnQgb2YgdGhlIFMtUGxhaW4gb3B0aW9uIGlzIHRoYXQgaXQgcmVxdWlyZXMgKm5vKiBh ZGRpdGlvbmFsIGxpYnJhcnkgYmV5b25kIGhhdmluZyBTU0wvVExTIGF2YWlsYWJsZS4gU28gdGhp cyBpcyBhIHZlbmRvciBzdXBwb3J0IGlzc3VlIOKAkyBpZiB5b3Ugd2FudCB0byBlbmFibGUgYSBs aWJyYXJ5LWxlc3MgY2xpZW50IGRldmVsb3BtZW50LCBvZmZlciBTLVBsYWluLiBUaGlzIGFnYWlu LCBpcyBhIHZlbmRvciBjaG9pY2UuDQpZZXMsIGJ1dCB0aGUgdHJhZGVvZmYgaGVyZSBpcyB0aGF0 IGEgY2xpZW50IHdpbGwgaGF2ZSBTLVBsYWluIHBsdXMgdHdvIG9yIHRocmVlIG90aGVyIGFsZ29y aXRobXMuICBUaGUgbGlicmFyeSBzaXplIGlzIGluY3JlYXNlZCwgdGhlIGNvbXBsZXhpdHkgaXMg aW5jcmVhc2VkLCBhbmQgaXQgZW5jb3VyYWdlcyBzZXJ2ZXJzIChsaWtlIEZhY2Vib29rKSB0byBk ZXZlbG9wIHNlcGFyYXRlIGxpYnJhcmllcyB3aGljaCBvbmx5IHN1cHBvcnQgdGhlIG9uZSBvciB0 d28gbWV0aG9kcyB0aGV5IGhhdmUgY2hvc2VuIHRvIHVzZS4gIEx1a2UgYW5kIEkgd291bGQgbGlr ZSB0byBhdm9pZCBjcmVhdGluZyBGYWNlYm9vayBzcGVjaWZpYyBjbGllbnQgbGlicmFyaWVzLiAg KFRoaXMgaXMgb2YgY291cnNlIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIG1ham9y aXR5IG9mIGltcGxlbWVudGF0aW9ucyB3aWxsIGFkb3B0IFMtUGxhaW4uICBXZSB0aGVuIGVudmlz aW9uIGFuIGFkdmFuY2VkIGNsaWVudCBsaWJyYXJ5IHdoaWNoIGFsc28gaW1wbGVtZW50cyBITUFD IFNIQS0yNTYuKQ0KDQpBbHNvIGtlZXAgaW4gbWluZCB0aGF0IHRoZSBjdXJyZW50IHByb3Bvc2Fs IG1vdmVzIHRoZSBhbGdvcml0aG0gY2hvaWNlIHRvIHRoZSB0b2tlbiByZXF1ZXN0L2lzc3VlIHBo YXNlLiBFYWNoIHRva2VuIHdpbGwgb25seSB3b3JrIHdpdGggYSBzaW5nbGUgYWxnb3JpdGhtICh3 aGljaCBpcyBiZXR0ZXIgY3J5cHRvZ3JhcGhpYyBoeWdpZW5lKS4gU28gYSB2ZW5kb3IgY2FuIGNo b29zZSB0byBhbGxvdyB0aGUgY2xpZW50IHRvIHBpY2sgdGhlIGFsZ29yaXRobSB0aGV5IHdhbnQg dG8geW91LCBvciBqdXN0IHRlbGwgdGhlbSB3aGljaCBvbmUgdGhleSBhcmUgZ29pbmcgdG8gdXNl Lg0KDQpFSEwNCg0KDQpGcm9tOiBMdWtlIFNoZXBhcmQgW21haWx0bzo8bWFpbHRvOmxzaGVwYXJk QGZhY2Vib29rLmNvbT5sc2hlcGFyZEBmYWNlYm9vay5jb208bWFpbHRvOmxzaGVwYXJkQGZhY2Vi b29rLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyOCwgMjAxMCA2OjM2IFBNDQpUbzog RXJhbiBIYW1tZXItTGFoYXY7IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IG9hdXRoQGlldGYub3Jn PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIERpc2N1c3Np b24gb2YgU1NMIGFzIHRoZSBwcmltYXJ5IG1lYW5zIGZvciBPQXV0aCBjb21tdW5pY2F0aW9uDQoN ClRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIHJlcGx5LCBFcmFuLg0KDQpJIHRoaW5rIHRoYXQgeW91 ciBwcm9wb3NlZCBkZXNpZ24gaGFzIGl0IGJhY2t3YXJkczogc2VydmVycyBzaG91bGQgYmVhciBj b21wbGV4aXR5IGFuZCBvbmUtdGltZSBjb3N0cywgbm90IGNsaWVudHMuIE11Y2ggb2Ygd2h5IEkg dGhpbmsgT0F1dGggV1JBUCAvIDIuMCBpcyBzbyBhcHBlYWxpbmcgaXMgdGhhdCBpdCBkcmFtYXRp Y2FsbHkgc2ltcGxpZmllcyBsaWZlIGZvciBkZXZlbG9wZXJzLiBJZiBhIGNsaWVudCBjYW4gc3Vw cG9ydCBTU0wgYW5kIGRvZXNu4oCZdCB3YW50IHRvIGRlYWwgd2l0aCBzaWduYXR1cmVzLCB0aGVu IHRoZXkgbmV2ZXIgc2hvdWxkIGhhdmUgdG8uIEkgd2FudCB0byBiZSBhYmxlIHRvIHdyaXRlIGEg dmVyeSBsaWdodHdlaWdodCBTU0wtb25seSBjbGllbnQgbGlicmFyeSB0aGF0IGlzIHN0aWxsIGZ1 bGx5IE9BdXRoIDIuMCBjb21wYXRpYmxlLg0KDQpJIHRoaW5rIGluc3RlYWQsIHRoZSBjb25zZW5z dXMgc2hvdWxkIGJlOg0KDQogKiAgIFN1cHBvcnQgYW4gZXh0ZW5zaWJsZSBzZXQgb2Ygc2lnbmF0 dXJlIGFsZ29yaXRobXMNCiAqICAgU2VydmVycyByZXF1aXJlZCB0byBzdXBwb3J0IHBsYWludGV4 dCB0b2tlbnMgb3ZlciBhIHNlY3VyZSBjaGFubmVsIChTU0wvVExTKQ0KICogICBTZXJ2ZXJzIHJl cXVpcmVkIHRvIHN1cHBvcnQgYXQgbGVhc3Qgb25lIG9yIGEgc21hbGwgc3Vic2V0IG9mIGVuY3J5 cHRpb24gYWxnb3JpdGhtcy4gUG9zc2libGUgY2FuZGlkYXRlcyBpbmNsdWRlIGhtYWMtc2hhLTEs IGhtYWMtc2hhLTI1NiwgYW5kIHJzYXNzYS4uLi4NCiAqICAgQ2xpZW50cyBtdXN0IHN1cHBvcnQg YXQgbGVhc3QgT05FIG9mIHRoZSByZXF1aXJlZCBlbmNyeXB0aW9uIG1ldGhvZHMNCg0KSWYgYSBj bGllbnQgc3VwcG9ydHMgYXQgbGVhc3Qgb25lIG9mIHRoZSByZXF1aXJlZCBtZXRob2RzIChTU0wg b3Igb25lIG9mIHRoZSBhbGdvcml0aG1zKSwgdGhlbiBpdCBjYW4gYmUgY29uc2lkZXJlZCBmdWxs eSBPQXV0aCAyLjAgY29tcGxpYW50LiBJZiBpdCBvbmx5IHN1cHBvcnRzIGVuY3J5cHRpb24gbWV0 aG9kcyB0aGF0IGFyZSBub3QgaW4gdGhlIHJlcXVpcmVkIGxpc3QsIHRoZW4gaXQgaXMgcGFydGlh bGx5IGNvbXBsaWFudCDigJMgdGhhdCBpcywgaXQgbWF5IHdvcmsgd2l0aCBhIHNwZWNpZmljIHZl bmRvciB0aGF0IGFkdmVydGlzZXMgc3VwcG9ydCBmb3IgdGhhdCBhbGdvcml0aG0sIGJ1dCBpdCB3 b27igJl0IHdvcmsgd2l0aCBhbGwgc2VydmVycy4gQXMgYWxnb3JpdGhtcyBncmFkdWFsbHkgY2hh bmdlIG92ZXIgdGltZSwgY2xpZW50IGxpYnJhcmllcyBjYW4gYmUgdXBncmFkZWQgd2hpbGUgc2Vy dmVycyBuZWVkIHRvIG1haW50YWluIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LiAoRm9yIGV4YW1w bGUsIEZhY2Vib29rIHdpbGwgZGVwcmVjYXRlIE1ENSBhcyBpdHMgc2lnIGFsZ29yaXRobSwgYnV0 IHdpbGwgY29udGludWUgdG8gc3VwcG9ydCBpdCBmb3IgdGhlIGNsaWVudHMgdXNpbmcgaXQgaW4g dGhlIHdpbGQpDQoNCkFzIGEgY29uY3JldGUgZXhhbXBsZSBvZiB3aGF0IGNhbiBiZSB3cml0dGVu IHdoZW4geW91IGRvbuKAmXQgbmVlZCB0byB3b3JyeSBhYm91dCBlbmNyeXB0aW9uLCBzZWU6IDxo dHRwOi8vZ2l0aHViLmNvbS9sc2hlcGFyZC9vYXV0aC13cmFwLWRlbW8vdHJlZS9tYXN0ZXIvc3Jj L3dyYXAuanM+IGh0dHA6Ly9naXRodWIuY29tL2xzaGVwYXJkL29hdXRoLXdyYXAtZGVtby90cmVl L21hc3Rlci9zcmMvd3JhcC5qcw0KSWYgSSB3ZXJlIHRvIG1vZGlmeSB0aGF0IEpTIHRvIGFjY29t bW9kYXRlIG11bHRpcGxlIHNpZ25hdHVyZSBhbGdvcml0aG1zLCB0aGVuIEkgd291bGQgbmVlZCB0 byBpbmNsdWRlIGF0IGxlYXN0IGFub3RoZXIgMS0yayBvZiBKYXZhU2NyaXB0IGZvciBlYWNoIG1l dGhvZCBqdXN0IGluIGNhc2UuIFRoYXQgd291bGQgYmUgZmFpcmx5IHJpZGljdWxvdXMuDQoNCg0K T24gMS8yOC8xMCAxOjQxIFBNLCAiRXJhbiBIYW1tZXItTGFoYXYiIDw8aHR0cDovL2VyYW5AaHVl bml2ZXJzZS5jb20+ZXJhbkBodWVuaXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNv bT4+IHdyb3RlOg0KVGhhbmtzIEx1a2UuIFRoaXMgaXMgYSB1c2VmdWwgYW5hbHlzaXMuDQoNCkkg YmVsaWV2ZSB3ZSBoYXZlIGFscmVhZHkgcmVhY2hlZCBjb25zZW5zdXMgaW4gdGhpcyByZWdhcmQ6 DQoNCiogU3VwcG9ydCBhbiBleHRlbnNpYmxlIHNldCBvZiBzaWduYXR1cmUgYWxnb3JpdGhtcw0K KiBEZWZpbmUgaG1hYy1zaGEtMSwgaG1hYy1zaGEtMjU2LCBhbmQgcnNhc3NhLXBrY3MxLXYxLjUt c2hhLTI1Ng0KKiBEZWZpbmUgYSBwbGFpbiBtZXRob2QgZm9yIGJlYXJlciB0b2tlbnMgYW5kIGVp dGhlciByZXF1aXJlIFNTTC9UTFMgb3Igc3Ryb25nbHkgcmVjb21tZW5kIGl0IChvcGVuIGlzc3Vl KQ0KDQooaWYgdGhlc2UgYXNzdW1wdGlvbnMgYXJlIGluY29ycmVjdCwgcmFpc2UgeW91ciBoYW5k IG5vdykNCg0KVGhlIHNwZWNpZmljYXRpb24gaXMgZ29pbmcgdG8gZGVmaW5lIHRoZSBmb3VyIG1l dGhvZHMgYWJvdmUgKGFuZCBwb3NzaWJseSBtb3JlKSBhcyAqbXVzdCBpbXBsZW1lbnQqLiBUaGlz IGRvZXMgbm90IG1lYW4gdmVuZG9ycyBoYXZlIHRvIHN1cHBvcnQgYWxsIG9mIHRoZW0sIGJ1dCB0 aGF0IGFueSAqY2xpZW50KiBsaWJyYXJ5IG9yIGFwcGxpY2F0aW9uIGNsYWltaW5nIHRvIGJlIOKA mE9BdXRoIDIuMCBjb21wbGlhbnTigJkgbXVzdCBpbXBsZW1lbnQgYWxsIHRoZXNlIG1ldGhvZHMu DQoNCklmIGEgdmVuZG9yIGlzc3VlcyB0b2tlbnMgbm90IHVzaW5nIGFsbCB0aGVzZSBtZXRob2Rz ICh3aGljaCBpcyBtb3JlIGxpa2VseSksIGl0IGRvZXMgbm90IGhhdmUgdG8gaW1wbGVtZW50IGFs bCB0aGVzZSBtZXRob2RzIGFuZCBjYW4gc3RpbGwgYmUgY2FsbGVkIOKAmE9BdXRoIDIuMCBjb21w bGlhbnTigJkgYmVjYXVzZSBhbnkgaXQgY2FuIGludGVyb3Agd2l0aCAqYW55KiBjb21wbGlhbnQg bGlicmFyeS4gSG93ZXZlciwgaWYgc3VjaCBhIHZlbmRvciBwcm9kdWNlcyBhIGNsaWVudCBsaWJy YXJ5IGZvciBpdHMgZGV2ZWxvcGVycyB3aGljaCBvbmx5IGltcGxlbWVudHMgdGhlIG1ldGhvZHMg ZGVwbG95ZWQgYnkgdGhlIHZlbmRvciwgdGhhdCBsaWJyYXJ5IGlzIOKAmE9BdXRoIDIuMCBwYXJ0 aWFsbHkgY29tcGxpYW504oCZIChiZWNhdXNlIGl0IHdpbGwgbm90IGludGVyb3Agd2l0aCAqYWxs KiB2ZW5kb3JzKS4NCg0KSW4gcHJhY3RpY2UsIGZyb20gRmFjZWJvb2vigJlzIHBlcnNwZWN0aXZl LCB5b3Ugd2lsbCBiZSBhYmxlIHRvIGRlcGxveSBPQXV0aCAyLjAgaW4gYSBjb21wbGlhbnQgd2F5 LCB3aGlsZSBvbmx5IGltcGxlbWVudGluZyB0aGUgbWV0aG9kcyB0aGF0IHlvdSBmaW5kIHN1aXRh YmxlIGZvciB5b3VyIGRldmVsb3BlcnMuIEl0IHNvdW5kcyBsaWtlIHlvdSB3aWxsIGJlIHVzaW5n IHRoZSBwbGFpbiBtZXRob2Qgb3ZlciBTU0wgYW5kIGVpdGhlciBobWFjLXNoYS0xIG9yIGhtYWMt c2hhLTI1Ni4gU2luY2UgRmFjZWJvb2sgdXN1YWxseSBtYWtlcyB0aGluZ3MgdHJpdmlhbCBmb3Ig aXRzIGRldmVsb3BlcnMsIEkgZXhwZWN0IEZhY2Vib29rIHRvIHByb2R1Y2UgbGlicmFyaWVzIHRo YXQgd2lsbCBpbXBsZW1lbnQgdGhlc2UgdHdvIG1ldGhvZHMsIGJ1dCBub3Qgb3RoZXJzLiBUaGlz IHdpbGwgYmUgYSDigJhGYWNlYm9vayBBUEnigJkgbGlicmFyeSB0aGF0IHVzZXMgT0F1dGggMi4w LiBJdCB3aWxsIGJlIHBhcnRpYWxseSBjb21wbGlhbnQgYnV0IHRoaXMgb25seSBtZWFucyBpdCBp cyBvbmx5IGd1YXJhbnRlZWQgdG8gd29yayB3aXRoIEZhY2Vib29rLCBidXQgdGhhdCBpdCBkb2Vz IHNvIGluIGEgZnVsbHkgY29tcGxpYW50IHdheS4NCg0KRUhMDQoNCg0KDQoNCg0KRnJvbTogPGh0 dHA6Ly9vYXV0aC1ib3VuY2VzQGlldGYub3JnPiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBbPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn Pm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTHVrZSBTaGVwYXJk DQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyOCwgMjAxMCA3OjMwIEFNDQpUbzogPGh0dHA6Ly9v YXV0aEBpZXRmLm9yZz4gb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3Vi amVjdDogW09BVVRILVdHXSBEaXNjdXNzaW9uIG9mIFNTTCBhcyB0aGUgcHJpbWFyeSBtZWFucyBm b3IgT0F1dGggY29tbXVuaWNhdGlvbg0KDQpJbiB0aGUgZGlzY3Vzc2lvbnMgYXJvdW5kIHRoZSBP QXV0aCBXUkFQIHNwZWMsIG9uZSBvZiB0aGUgcXVlc3Rpb25zIG9mdGVuIGFza2VkIGlzLCDigJx3 aHkgdXNlIFNTTCBleGNsdXNpdmVseT/igJ0gU2V2ZXJhbCBvZiB1cyBoYXZlIGRvbmUgYSBsb3Qg b2YgdGhpbmtpbmcgb24gaXQgYW5kIEkgd2FudGVkIHRvIGFydGljdWxhdGUgbXkgdW5kZXJzdGFu ZGluZyBvZiB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUgYXBwcm9hY2ggZm9yIGRpc2N1c3Npb24u IFRoZSB1c2UgY2FzZSBJIHByaW1hcmlseSBoYXZlIGluIG1pbmQgaXMgdGhhdCBvZiBhIHdlYiBz ZXJ2aWNlLCBsaWtlIEZhY2Vib29rLCBUd2l0dGVyLCBvciBHb29nbGUgc2VydmljZXMuIE91ciBz ZXJ2aWNlIGlzIHByaW1hcmlseSBhdXRoZW50aWNhdGVkIHZpYSB0aGUgV2ViLCBidXQgd2UgaGF2 ZSBhIHVzZSBmb3IgYWxsIG9mIHRoZSBXUkFQIHByb2ZpbGVzICh3ZWIgYXBwLCBjbGllbnQgYXBw LCBkZXNrdG9wLCBtb2JpbGUpLg0KDQpPdmVyYWxsLCBJIHRoaW5rIHRoYXQgdGhlIHNpbXBsaWNp dHkgb2YgdXNpbmcgU1NMIG91dHdlaWdocyBhbGwgdGhlIGFzc29jaWF0ZWQgY29zdHMgZm9yIG1v c3QgZGV2ZWxvcGVycy4gSG93ZXZlciwgd2Ugc2hvdWxkIG9mZmVyIHBsYWludGV4dCBzaWduYXR1 cmVzIGFzIGFuIG9wdGlvbmFsIHBlcmZvcm1hbmNlIGVuaGFuY2VtZW50IGZvciBhZHZhbmNlZCBk ZXZlbG9wZXJzLg0KDQo9PSBBZHZhbnRhZ2VzIG9mIHVzaW5nIFNTTCBmb3IgQVBJIGNhbGxzDQoN Ci0tIEl04oCZcyBvdmVyd2hlbG1pbmdseSBzaW1wbGVyIGZvciBkZXZlbG9wZXJzLg0KSeKAmXZl IGltcGxlbWVudGVkIE9wZW5JRCBhbmQgT0F1dGgsIGFuZCBJ4oCZdmUgd29ya2VkIGZvciB5ZWFy cyB3aXRoIGRldmVsb3BlcnMgdHJ5aW5nIHRvIGhhbmRsZSBzaWduYXR1cmVzIG9uIHRoZSBGYWNl Ym9vayBQbGF0Zm9ybS4gSW4gbXkgZXhwZXJpZW5jZSwgY2FsY3VsYXRpbmcgc2lnbmF0dXJlcyBp cyBvbmUgb2YgdGhlIG1vc3QgY29tcGxleCBhbmQgZGlmZmljdWx0IHBhcnRzIG9mIGFuIGF1dGhl bnRpY2F0aW9uIHByb3RvY29sLCBhbmQgZGV2ZWxvcGVycyBvZnRlbiBnZXQgaXQgd3JvbmcuIEJ5 IG1vdmluZyB0aGF0IHBpZWNlIGRvd24gdGhlIHN0YWNrIHdlIGNhbiBnZXQgaXQgb3V0IG9mIHRo ZWlyIHdheSBhbmQgbGV0IGRldmVsb3BlcnMgZm9jdXMgb24gYnVpbGRpbmcgdGhlaXIgYXBwcy4N Cg0KLS0gRXhpc3RpbmcgdG9vbHMgZWNvc3lzdGVtDQpJdOKAmXMgbm90IHRoYXQgU1NMIGlzIGEg c2ltcGxlciBlbmNyeXB0aW9uIHByb3RvY29sIHRoYW4gT0F1dGggKGl04oCZcyBub3QpIGJ1dCBy YXRoZXIgdGhhdCBjb21tb25seSBhdmFpbGFibGUgdG9vbHMgYWxtb3N0IHVuaXZlcnNhbGx5IHN1 cHBvcnQgaXQg4oCTIGV2ZXJ5IG1ham9yIHdlYiBicm93c2VyLCBhcyB3ZWxsIGFzIG1vc3QgbGli cmFyaWVzIGZvciBtYWtpbmcgSFRUUCByZXF1ZXN0cyAobGlrZSBjdXJsKSBoYXZlIGJ1aWx0LWlu IHN1cHBvcnQgZm9yIFNTTC4gRm9yIE9BdXRoIDEuMCwgeW91IG5lZWQgdG8gdXNlIGEgY2xpZW50 IGxpYnJhcnkganVzdCB0byBjb25zdHJ1Y3QgeW91ciB2ZXJ5IGZpcnN0IHJlcXVlc3QuDQoNCi0t IFNtYWxsZXIgY2xpZW50IGxpYnJhcmllcw0KQSBnb29kIGNodW5rIG9mIGNvZGUgaW4gbWFueSBj bGllbnQgbGlicmFyaWVzIGlzIGRldm90ZWQgdG8gY2FsY3VsYXRpbmcgYW5kIHZlcmlmeWluZyBz aWduYXR1cmVzLiBGb3IgZXhhbXBsZSwgdGhlIE9wZW5JRCBQSFAgbGlicmFyeSBpbXBvcnRzIHNl dmVyYWwgQmlnTWF0aCBtb2R1bGVzIGFuZCBlbmNyeXB0aW9uIHNjaGVtZXMuIEV2ZW4gdGhlIHJl bGF0aXZlbHkgc2ltcGxlciBGYWNlYm9vayBjbGllbnQgbGlicmFyeSByZXF1aXJlcyBzZXZlcmFs IGZ1bmN0aW9ucyB0byBzaWduIHJlcXVlc3RzLiBUaGlzIG1ha2VzIHRoZSBjbGllbnQgbGlicmFy aWVzIGEgYmxhY2sgYm94IGFuZCBpbXBlZGVzIHVuZGVyc3RhbmRpbmcuDQoNCldvdWxkbuKAmXQg aXQgYmUgZ3JlYXQgaWYgd2UgY291bGQgd3JpdGUgYSBwcm90b2NvbCB0aGF0IGRvZXNu4oCZdCBl dmVuIHJlcXVpcmUgYSBjbGllbnQgbGlicmFyeSB0byBpbXBsZW1lbnQ/IElmIEkgY291bGQganVz dCBtYWtlIGFuIGF1dGhlbnRpY2F0ZWQgQVBJIHJlcXVlc3QgaW4gbXkgYnJvd3NlciwgYXMgZWFz aWx5IGFzIHdpdGggQmFzaWMgQXV0aD8NCg0KPT0gRGlzYWR2YW50YWdlcyBvZiB1c2luZyBTU0wg Zm9yIEFQSSBjYWxscw0KDQotLSBEaWZmaWN1bHRpZXMgb2YgZGVidWdnaW5nDQoNCkJvdGggc2ln bmF0dXJlcyBhbmQgU1NMIHByZXNlbnQgZGlmZmljdWx0aWVzIGluIGRlYnVnZ2luZywgYnV0IHRo ZXkgdGVuZCB0byBiZSBkaWZmZXJlbnQuIFdoaWxlIHdpdGggc2lnbmF0dXJlcyB5b3Ugd29ycnkg YWJvdXQgY29tcG9zaW5nIHRoZSBhcmd1bWVudHMgd3Jvbmcgb3IgdXNpbmcgdGhlIHdyb25nIGFs Z29yaXRobSwgd2l0aCBTU0wgeW91IHdvcnJ5IGFib3V0IHJlYWRpbmcgdGhlIHJlcXVlc3Qgb3Zl ciB0aGUgd2lyZS4gWW91IGNhbuKAmXQgc25pZmYgYSByZXF1ZXN0LCBhbmQgdG8gaW50ZXJjZXB0 IGl0LCB5b3UgbmVlZCBhbiBIVFRQIHByb3h5IHRoYXQgdW5kZXJzdGFuZHMgU1NMLCBhbmQgeW91 IG5lZWQgdG8gd29ycnkgYWJvdXQgaW52YWxpZCBjZXJ0aWZpY2F0ZSBlcnJvcnMuIFRvIGFpZCBp biB0aGlzLCBwcm92aWRlcnMgd2lsbCBwcm9iYWJseSBvZmZlciBhIG5vbi1TU0wgZW5kcG9pbnQg Zm9yIGRlYnVnZ2luZywgYnV0IHRoZXkgbWF5IG5lZWQgdG8gc2V0IHVwIGEgc2FuZGJveCBlbnZp cm9ubWVudCB0byBwcmV2ZW50IGRhbWFnZSBmcm9tIHRva2VucyBleHBvc2VkIGluIHBsYWludGV4 dC4NCg0KLS0gVmFyaWFibGUgY29zdHMgZm9yIHByb3ZpZGVycw0KDQpTZXJ2ZXIgQ1BVIGNvc3Rz IHdpbGwgaW5jcmVhc2Ugd2hlbiBoYW5kbGluZyBTU0wgcmVxdWVzdHMg4oCTIGVzcGVjaWFsbHkg b24gZXZlcnkgQVBJIGNhbGwgaW5zdGVhZCBvZiBqdXN0IGF0IHRoZSBhdXRoIHN0YWdlLiBBdCBz Y2FsZSwgdGhpcyBjYW4gYmVjb21lIGV4cGVuc2l2ZSwgYWx0aG91Z2ggaXQgY2FuIGJlIG9mZnNl dCBieSB1c2luZyBzcGVjaWFsaXplZCBoYXJkd2FyZSB0byB0ZXJtaW5hdGUgdGhlIFNTTCBjb25u ZWN0aW9uLiBBbGwgdGhlIGJpZyBjb21wYW5pZXMgSeKAmXZlIHRhbGtlZCB0byBhcmUgY29tZm9y dGFibGUgdHJhZGluZyB0aGVzZSBoaWdoZXIgY29zdHMgZm9yIGluY3JlYXNlZCBhZG9wdGlvbiBk dWUgdG8gdGhlIHNpbXBsaWNpdHkuDQoNCi0tIEZpeGVkIGNvc3RzIGZvciBzbWFsbGVyIHByb3Zp ZGVycw0KDQpUaGVyZSBpcyBhIGZpeGVkIGNvc3QgdG8gb2J0YWluaW5nIGFuZCBzaWduaW5nIGFu IFNTTCBjZXJ0aWZpY2F0ZXMsIGFsdGhvdWdoIHRoYXQgaGFzIGRyb3BwZWQgaW4gcmVjZW50IHll YXJzIHN1Y2ggdGhhdCBhbiBvcGVyYXRvciBjYW4gaGF2ZSBhIGNlcnQgc2lnbmVkIGZvciBhIHNp bmdsZSBkb21haW4gZm9yIHByZXR0eSBjaGVhcC4NCg0KLS0gTGF0ZW5jeQ0KDQpTU0wgY29ubmVj dGlvbnMgdGFrZSBtb3JlIHRpbWUgdG8gZXN0YWJsaXNoIHRoYW4gbm9ybWFsIEhUVFAgY29ubmVj dGlvbnMuIFNlcnZlcnMgY2FuIHVzZSBzcGVjaWFsaXplZCBoYXJkd2FyZSB0byBzcGVlZCBpdCB1 cCwgYnV0IGNsaWVudHMgcmFyZWx5IGRvLCB3aGljaCBtZWFucyB0aGF0IGZvciBjbGllbnQtdG8t c2VydmVyIEFQSSByZXF1ZXN0cywgdGhlcmUgbWF5IGJlIHNvbWUgaGlnaGVyIGxhdGVuY3kgaW4g ZWFjaCByZXF1ZXN0LiBTbWFsbGVyLCBtb2JpbGUgZGV2aWNlcyBtYXkgYmUgZGlzcHJvcG9ydGlv bmF0ZWx5IGFmZmVjdGVkIGJ5IHRoaXMsIGJ1dCBhcyB0aGV5IGdyb3cgbW9yZSBwb3dlcmZ1bCBp dOKAmXMgbGVzcyBvZiBhIGNvbmNlcm4uIEFscmVhZHkgdG9kYXkgbmV3ZXIgcGhvbmVzIGNhbiBo YW5kbGUgU1NMIGp1c3QgZmluZS4NCg0KLS0gQnJvd3NlciBsaW1pdGF0aW9ucyBmb3IgY3Jvc3Mg ZG9tYWluIGNvbW11bmljYXRpb24NCg0KQSBtb3JlIG5pY2hlIGRpc2FkdmFudGFnZSBpcyB0aGF0 IHNvbWUgY3Jvc3MgZG9tYWluIGNvbW11bmljYXRpb24gdGVjaG5pcXVlcyByZXF1aXJlIHRoZSBw cm90b2NvbCBvZiB0aGUgcGFyZW50IHBhZ2UgdG8gbWF0Y2ggdGhhdCBvZiB0aGUgZW5kcG9pbnQg YmVpbmcgcXVlcmllZC4gU28gZm9yIGV4YW1wbGUsIGluIHNvbWUgYnJvd3NlcnMsIGZvciBzb21l IEFQSSBjYWxscywgaXQgd291bGQgYmUgaW1wb3NzaWJsZSB0byBtYWtlIGFuIEFQSSBjYWxsIHRv IGFuIEhUVFBTIGVuZHBvaW50IGZyb20gYSBub3JtYWwgSFRUUCBwYWdlLiBIb3dldmVyLCBhcyBi cm93c2VycyBhZHZhbmNlIGFuZCBIVE1MNSBtZXRob2RzIGxpa2UgcG9zdE1lc3NhZ2UgYmVjb21l IG1vcmUgY29tbW9uLCB0aGlzIHdpbGwgYmVjb21lIGxlc3Mgb2YgYW4gaXNzdWUuDQoNCi0tIFZl cmlmeWluZyBpbmZvcm1hdGlvbiBvbiB0aGUgcmVseWluZyBwYXJ0eQ0KDQpJZiBpbmZvcm1hdGlv biBpcyBwYXNzZWQgZnJvbSBhIFNlcnZpY2UgUHJvdmlkZXIgdG8gYSBDb25zdW1lciB0aHJvdWdo IHRoZSB1c2Vy4oCZcyBicm93c2VyLCB0aGVuIHRoYXQgaW5mb3JtYXRpb24gY2Fubm90IGJlIHZl cmlmaWVkIHdpdGhvdXQgYW4gQVBJIGNhbGwsIHVubGVzcyBhIHNpZ25hdHVyZSBpcyBwcm92aWRl ZC4gU2ltaWxhciB0byBzdGF0ZWZ1bCB2cy4gc3RhdGVsZXNzIG1vZGUgaW4gdGhlIE9wZW5JRCAy LjAgc3BlYywgdGhlIHNpZ25hdHVyZSBjYW4gc2VydmUgYXMgYSBwZXJmb3JtYW5jZSBlbmhhbmNl bWVudCB0byBhdm9pZCBhbiBBUEkgY2FsbC4NCg0KPT0gUHJvdmlkaW5nIGEgbm9uLVNTTCBvcHRp b24gZm9yIHRoZSBzaG9ydCBoZWFkDQoNCk1vc3QgcGxhdGZvcm1zIHRlbmQgdG8gaGF2ZSBhIHNt YWxsIG51bWJlciBvZiBmYWlybHkgbGFyZ2UgZGV2ZWxvcGVycyBhbmQgdGhlbiBhIHJlYWxseSBs YXJnZSBudW1iZXIgb2Ygc21hbGxlciBkZXZlbG9wZXJzLiBUaGUgZm9ybWVyIGFyZSB0eXBpY2Fs bHkgZXhwZXJpZW5jZWQgKG9yIGF0IGxlYXN0LCB0aGV5IGFyZSBieSB0aGUgdGltZSB0aGV5IGdl dCBiaWcpIGFuZCBoYXZlIG1hZGUgYSBsYXJnZSBpbnZlc3RtZW50IGluIHRoZSBwbGF0Zm9ybS4g VGhlIGxhdHRlciByYW5nZSBmcm9tIGV4cGVyaWVuY2VkIGRldmVsb3BlcnMgdG8gYW1hdGV1cnMg dG8gZm9sa3MgdGhhdCB3b3VsZCBub3QgdHlwaWNhbGx5IHByb2dyYW0uIEZvciB0aGlzIHNwZWMg dG8gYmUgc3VjY2Vzc2Z1bCwgaXQgbXVzdCBtZWV0IHRoZSBuZWVkcyBvZiBib3RoIGdyb3Vwcy4N Cg0KRmFjZWJvb2sgaXMgdmVyeSBpbnRlcmVzdGVkIGluIGFkb3B0aW5nIE9BdXRoIFdSQVAgLyAy LjAgLyB3aGF0ZXZlciBiZWNhdXNlIHdlIHdhbnQgdG8gaGVscCBvdXIgbG9uZyB0YWlsIGRldmVs b3BlcnMgdXNlIG91ciBwbGF0Zm9ybSBtb3JlIGVhc2lseS4gRm9yIHRoZSBsb25nIHRhaWwsIHRo ZSBzaW1wbGljaXR5IHByb3ZpZGVkIGJ5IFNTTCB3aWxsIGJlIGNydWNpYWwuIEl0IG1lYW5zIHNt YWxsZXIgb3Igbm9uZXhpc3RlbnQgY2xpZW50IGxpYmFyaWVzLCBpdCBtZWFucyB0aGF0IGRldmVs b3BlcnMgY2FuIGp1c3QgdHJ5IG91dCB0aGUgQVBJIGJ5IHR5cGluZyBpdCBpbnRvIGEgd2ViIGJy b3dzZXIsIGFuZCBpdCB3aWxsIGhlbHAgcmVkdWNlIGRlYnVnZ2luZyBhbmQgbWFpbnRlbmFuY2Ug Y29zdHMuDQoNCkhvd2V2ZXIsIGZvciB0aGUgc2hvcnQgaGVhZCBvZiBoaWdoIHZvbHVtZSBkZXZl bG9wZXJzLCB3ZSBwcm9iYWJseSB3YW50IGFuIG9wdGlvbiB0byB1c2Ugc29tZXRoaW5nIG90aGVy IHRoYW4gU1NMIHRvIG1ha2Ugc2VjdXJlIHJlcXVlc3RzLiBUaGVzZSBkZXZlbG9wZXJzIHRlbmQg dG8gaGF2ZSBhbHJlYWR5IHNvbHZlZCB0aGUgbG93IGhhbmdpbmcgcGVyZm9ybWFuY2UgZnJ1aXQs IGFuZCBmb3IgdGhlbSBpdCBtYXkgYmUgYSBzaWduaWZpY2FudCBwZW5hbHR5IHRvIHBheSB0aGUg U1NMIGNvbm5lY3Rpb24gY29zdCBvbiBldmVyeSByZXF1ZXN0LiBUbyB0aGF0IGVuZCwgSSB0aGlu ayBpdOKAmXMgcHJldHR5IGltcG9ydGFudCB0aGF0IE9BdXRoIDIuMCBzdXBwb3J0IGEgbWV0aG9k IG90aGVyIHRoYW4gU1NMIGFzIGFuIG9wdGlvbiBmb3IgYWR2YW5jZWQgZGV2ZWxvcGVycy4gQnV0 IGl0IHNob3VsZCBiZSBqdXN0IHRoYXQg4oCTIGFuIG9wdGlvbiwgYW5kIG9ubHkgZm9yIGFkdmFu Y2VkIGRldmVsb3BlcnMsIHNvIHRoYXQgYmVnaW5uaW5nIHByb2dyYW1tZXJzIGFuZCBmb2xrcyBs ZWFybmluZyBhbiBBUEkgZG9u4oCZdCBuZWVkIHRvIHdvcnJ5IGFib3V0IHNpZ25hdHVyZXMgd2hl biB0aGV5IGp1c3Qgd2FudCB0byBwbGF5IGFyb3VuZC4NCg0KUGxlYXNlIGxldCBtZSBrbm93IGlm IEnigJltIG1pc3Npbmcgc29tZXRoaW5nIG9yIGlmIG15IGFzc3VtcHRpb25zIHNvdW5kIGluY29y cmVjdC4NCg0KLUx1a2UgU2hlcGFyZA0KU29mdHdhcmUgRW5naW5lZXIsIEZhY2Vib29rIFBsYXRm b3JtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCjxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+T0F1dGhAaWV0Zi5vcmc8 bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_A2CF729A181248C98C9623BAD0947C49hueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5Zb3VyIHNlcnZlciB3aWxsIGJlIGZ1 bGx5IGNvbXBsaWFudC4gQnV0IGlmIHlvdSBwcm9kdWNlIGEgbGlicmFyeSB0aGF0IG9ubHkgc3Vw cG9ydHMgeW91IGxpbWl0ZWQgbmVlZHMsIGl0IHdpbGwgYmUgcGFydGlhbGx5IGNvbXBsaWFudC4m bmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkVITDxicj48YnI+T24gSmFuIDI5LCAyMDEw LCBhdCAxMDo1NCwgIkh1cmxpbWFuLCBKb2huIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG4uaHVy bGltYW5AaW50ZWwuY29tIj5qb2huLmh1cmxpbWFuQGludGVsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj48YnI+PC9kaXY+PGRpdj48c3Bhbj48L3NwYW4+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PGRpdj4NCg0KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5J4oCZbSBmaW5l IHdpdGggbGV0dGluZyB0aGUgbWFya2V0IGRlY2lkZSB3aGV0aGVyIHRvIHVzZSBTU0wNCm9yIGlt cGxlbWVudCB0aGVpciBvd24gY3J5cHRvIGluIGxpYnJhcmllcyAoSSBrbm93IG91ciBpbXBsZW1l bnRhdGlvbnMgd2lsbA0KY2hvb3NlIFNTTC1vbmx5KSwgYnV0IHRoYXQgbWVhbnMgd2XigJlsbCBi ZSBnb2luZyBmcm9tIGZ1bGx5IGNvbXBsaWFudCB3aXRoDQpPQXV0aCBXUkFQIHRvIHBhcnRpYWxs eSBjb21wbGlhbnQgd2l0aCBPQXV0aCAyLjAgYnkgbWFraW5nIHRoZSBzYW1lIGNob2ljZXMuDQpT b21lIGNvbmNlcm4gd2FzIHJhaXNlZCB0aGF0IHRoZSBjbGllbnQgbGlicmFyeSBvZmZlcmluZ3Mg d2lsbCBmcmFnbWVudCBiZWNhdXNlDQpvZiB0aGlzLCBidXQgSSB0aGluayBpdOKAmXMgbW9yZSBs aWtlbHkgdGhlcmUgd2lsbCBqdXN0IGJlIHR3byB2ZXJzaW9ucyBvZg0KT0F1dGggMi4wIGNsaWVu dCBsaWJyYXJpZXMuIFRoZSB0aGluIFNTTC1vbmx5IHZlcnNpb24gb2YgdGhlIGxpYnJhcnkgdXNl ZCBieQ0KRmFjZWJvb2ssIFZXUkFQLCBhbmQgYW55b25lIGVsc2UgdGhhdCBpcyBmaW5lIHdpdGgg dGhlIFNTTCBtb2RlLCBhbmQgdGhlIHRoaWNrDQpjbGllbnQgbGliIHVzZWQgYnkgdmVuZG9ycyB0 aGF0IHJlcXVpcmUgb3RoZXIgbW9kZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkpvaG48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCg0KPGRpdj4NCg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9 Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9h PiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+RXJh bg0KSGFtbWVyLUxhaGF2PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSmFudWFyeSAyOSwgMjAx MCAxMjoxMiBBTTxicj4NCjxiPlRvOjwvYj4gRGF2aWQgUmVjb3Jkb248YnI+DQo8Yj5DYzo8L2I+ IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll dGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb T0FVVEgtV0ddIERpc2N1c3Npb24gb2YgU1NMIGFzIHRoZSBwcmltYXJ5IG1lYW5zIGZvciBPQXV0 aA0KY29tbXVuaWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3 RCI+Rm9yIG9uZSwgd2Uga25vdyBuZXZlciB0byBhc3N1bWUgdGhhdCBTU0wgaXMgaW1wbGVtZW50 ZWQNCmNvcnJlY3RseSAobm90IGluIHRlcm1zIG9mIHRoZSBsaWJyYXJpZXMgYnV0IGhvdyBjZXJ0 aWZpY2F0ZSBleGNlcHRpb25zIGFyZQ0KaGFuZGxlZCBhbmQgaG93IGl0cyBkZWZlbnNlcyBjYW4g YmUgY29tcHJvbWlzZWQpLiBTLVBsYWluIGFsc28gZXhwb3NlcyB0aGUNCnNlY3JldCB0byBpbnRl cm1lZGlhcmllcyB3aGlsZSBzaWduYXR1cmVzIGNhbiBwYXNzIHRocm91Z2ggd2l0aG91dCBiZWlu Zw0KY29tcHJvbWlzZWQuIEkgYW0gc3VyZSBCZW4gTGF1cmllIGFuZCBvdGhlcnMgY2FuIGxpc3Qg bW9yZSBkaWZmZXJlbmNlcyAoYW5kDQpob3BlIHRoZXkgd2lsbCkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PkkgZGlzYWdyZWUgd2l0aCB5b3VyIHNlY29uZCBjb21tZW50IGFib3V0IGNsaWVudCBsaWJyYXJ5 IHNpemUuDQpUeXBpY2FsbHkgaWYgeW91IGhhdmUgb25lIGNyeXB0byBhbGdvcml0aG0sIHlvdSBo YXZlIG1hbnkgb3RoZXJzIGF2YWlsYWJsZS4gQW5kDQppZiB5b3UgYXJlIHN1Z2dlc3RpbmcgdGhh dCBieSByZXF1aXJpbmcgb25seSBTLVBsYWluIGl0IHdpbGwgZW5hYmxlIGNyeXB0by1sZXNzDQps aWJyYXJpZXMsIEkgd291bGQgcmF0aGVyIHRoZSBjb21tdW5pdHkgYXZvaWRlZCBwcm9kdWNpbmcg c3VjaCBsaW1pdGVkICo8Yj5saWJyYXJpZXM8L2I+Ki4NCklmIHdlIG1ha2UgaXQgb2sgbm90IHRv IHN1cHBvcnQgc2lnbmF0dXJlcyBpbiBnZW5lcmljIGxpYnJhcmllcywgaXQgd2lsbCBtYWtlDQpp dCBldmVuIGhhcmRlciBmb3IgdmVuZG9ycyB0byBvZmZlciB0aGVtLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij5BdCB0aGUgZW5kLCB0aGUgbWFya2V0IHdpbGwgZGVjaWRlIGJldHdlZW4gc2lnbmF0dXJlcyBh bmQNClMtUGxhaW4sIHRoZSBzYW1lIHdheSB0aGUgUlNBIG1ldGhvZCBpbiBPQXV0aCAxLjAgZ2Fp bmVkIHZlcnkgbGl0dGxlIHRyYWN0aW9uDQoobW9zdGx5IGJlY2F1c2UgaXQgd2FzIHVuZGVyc3Bl Y2lmaWVkIElNTykuIEkgZG9u4oCZdCB0aGluayB3ZSBzaG91bGQgbWFrZQ0KdGhhdCBkZWNpc2lv biBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5FSEw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KDQo8ZGl2Pg0K DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBEYXZpZCBSZWNvcmRvbg0KW21haWx0bzpyZWNvcmRvbmRAZ21haWwuY29t XSA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMjgsIDIwMTAgMTA6MzMgUE08 YnI+DQo8Yj5Ubzo8L2I+IEVyYW4gSGFtbWVyLUxhaGF2PGJyPg0KPGI+Q2M6PC9iPiBMdWtlIFNo ZXBhcmQ7IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbT0FVVEgtV0ddIERpc2N1c3Npb24gb2YgU1NMIGFzIHRoZSBwcmltYXJ5IG1lYW5zIGZv ciBPQXV0aA0KY29tbXVuaWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoN CjwvZGl2Pg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gMjgsIDIwMTAgYXQgNzoxMCBQTSwgRXJh biBIYW1tZXItTGFoYXYgJmx0OzxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj48 YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+ZXJhbkBodWVuaXZlcnNlLmNvbTwv YT48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDsNCm1hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCg0KPGRpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEIj4oRm9yIHRoZSBzYWtlIG9mIHNpbXBsaWNpdHksIEkgYW0gZ29pbmcNCnRv IHJlZmVyIHRvIHRoZSBQbGFpbiBiZWFyZXIgdG9rZW4gd2l0aCBTU0wvVExTIGFzIFMtUGxhaW4p PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPldSQVAgYXBwZWFsIGlzIGFsc28g aXRzIGxpbWl0YXRpb24gYW5kDQooc3RyaWN0bHkgYXMgd3JpdHRlbikgaXQgc2FjcmlmaWNlcyBz ZWN1cml0eSBmb3IgY2xpZW50IGVhc2UuIFdlIHN0aWxsDQpkb27igJl0IGtub3cgd2hhdCBPQXV0 aCAyLjAgaXMgKGl0IGlzICo8Yj5ub3Q8L2I+KiBXUkFQLCBidXQgbGlrZWx5IHRvDQppbmNsdWRl IGlkZWFzIGZyb20gaXQpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8L2Jsb2NrcXVvdGU+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBp cyBzZWN1cml0eSBzYWNyaWZpY2VkIGluIHRoZSBTLVBsYWluIG1ldGhvZCBwcm9wb3NlZA0KZm9y IE9BdXRoIDIuMD8gJm5ic3A7SSB1bmRlcnN0YW5kIHRoYXQgV1JBUCBtYWtlcyBzYWNyaWZpY2Vz LCBidXQgYW0gSSBtaXNzaW5nDQpzb21ldGhpbmcgaW4gdGVybXMgb2YgbW92aW5nIGEgUGxhaW4g YmVhcmVyIHRva2VuIGFsd2F5cyBvdmVyIFNTTC9UTFMgd2hlbg0KbWFraW5nIGF1dGhlbnRpY2F0 aW9uIHJlcXVlc3RzPzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0Ow0KbWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KDQo8ZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0QiPlRoZSBwcm9ibGVtIEkgaGF2ZSB3aXRoIHlvdXIgYXBwcm9hY2gg aXMNCnRoYXQgeW91IGFyZSBtYW5kYXRpbmcgc2VydmVyIGRlcGxveW1lbnQgYW5kIGdpdmVuIHRo YXQgdGhpcyBpcyBhIHNlY3VyaXR5DQpwcm90b2NvbCwgd2UgaGF2ZSBubyBidXNpbmVzcyB0ZWxs aW5nIHNlcnZlcnMgd2hhdCB0aGV5IE1VU1QgaW1wbGVtZW50ICh0aGV5DQptaWdodCBjb25zaWRl ciBTLVBsYWluIHRvbyB3ZWFrIGZvciB0aGVpciBuZWVkcykuIFRoZXJlIGFyZSBtYW55IHJlYXNv bnMgd2h5DQp2ZW5kb3JzIHdvdWxkIHJhdGhlciBub3QgdXNlIHRoZSBTLVBsYWluIG9wdGlvbiAo eW91IGxpc3RlZCBzb21lIG9mIHRob3NlKSBmb3INCmV2ZXJ5IHByb3RlY3RlZCByZXNvdXJjZSBy ZXF1ZXN0LiBUaGVyZSBhcmUgYWxzbyBtYW55IHJlYXNvbnMgd2h5IHZlbmRvcnMgd291bGQNCm9u bHkgc3VwcG9ydCBTLVBsYWluIGFuZCBubyBzaWduYXR1cmUgb3B0aW9uLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjojMUY0OTdEIj5NeSBwcm9wb3NhbCBhbGxvd3MgeW91IHRvIGRvIGV2ZXJ5 dGhpbmcNCnlvdSBoYXZlIGFza2VkIGZvciBhbmQgeW91ciBkZXZlbG9wZXJzIHdpbGwgaGF2ZSBh biBlYXN5IGxpZmUgd2l0aCB0aGUgUy1QbGFpbg0Kb3B0aW9uLCBvciBwZXJmb3JtYW5jZSAvIGZs ZXhpYmlsaXR5IHdpdGggb25lIG9mIHRoZSBITUFDIG1ldGhvZHMuIEJ1dCB0aGUNCmFkdmFudGFn ZSBpcyB0aGF0IEkgZG8gbm90IG1hbmRhdGUgRmFjZWJvb2sgdG8gZG8gYW55dGhpbmcgaXQgZG9l c27igJl0DQp3YW50LiBBbnkgT0F1dGggMi4wIGNsaWVudCB3aWxsIHdvcmsgd2l0aCBGYWNlYm9v ay48L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SXQgaXMgdHJ1ZSB0aGF0IHdy aXRpbmcgYSBmdWxseQ0KY29tcGxpYW50IGNsaWVudCB3aWxsIHJlcXVpcmUgbW9yZSB3b3JrLiBC dXQgdGhlIHdob2xlIHBvaW50IG9mIHRoZSBTLVBsYWluDQpvcHRpb24gaXMgdGhhdCBpdCByZXF1 aXJlcyAqPGI+bm88L2I+KiBhZGRpdGlvbmFsIGxpYnJhcnkgYmV5b25kIGhhdmluZyBTU0wvVExT DQphdmFpbGFibGUuIFNvIHRoaXMgaXMgYSB2ZW5kb3Igc3VwcG9ydCBpc3N1ZSDigJMgaWYgeW91 IHdhbnQgdG8gZW5hYmxlIGENCmxpYnJhcnktbGVzcyBjbGllbnQgZGV2ZWxvcG1lbnQsIG9mZmVy IFMtUGxhaW4uIFRoaXMgYWdhaW4sIGlzIGEgdmVuZG9yIGNob2ljZS48L3NwYW4+PG86cD48L286 cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ibG9ja3F1b3RlPg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIGJ1dCB0aGUgdHJhZGVvZmYgaGVyZSBpcyB0aGF0IGEg Y2xpZW50IHdpbGwgaGF2ZQ0KUy1QbGFpbiBwbHVzIHR3byBvciB0aHJlZSBvdGhlciZuYnNwO2Fs Z29yaXRobXMuICZuYnNwO1RoZSBsaWJyYXJ5IHNpemUgaXMNCmluY3JlYXNlZCwgdGhlIGNvbXBs ZXhpdHkgaXMgaW5jcmVhc2VkLCBhbmQgaXQgZW5jb3VyYWdlcyBzZXJ2ZXJzIChsaWtlDQpGYWNl Ym9vaykgdG8gZGV2ZWxvcCBzZXBhcmF0ZSBsaWJyYXJpZXMgd2hpY2ggb25seSBzdXBwb3J0IHRo ZSBvbmUgb3IgdHdvDQptZXRob2RzIHRoZXkgaGF2ZSBjaG9zZW4gdG8gdXNlLiAmbmJzcDtMdWtl IGFuZCBJIHdvdWxkIGxpa2UgdG8gYXZvaWQgY3JlYXRpbmcNCkZhY2Vib29rIHNwZWNpZmljIGNs aWVudCBsaWJyYXJpZXMuICZuYnNwOyhUaGlzIGlzIG9mIGNvdXJzZSBiYXNlZCBvbiB0aGUNCmFz c3VtcHRpb24gdGhhdCB0aGUgbWFqb3JpdHkgb2YgaW1wbGVtZW50YXRpb25zIHdpbGwgYWRvcHQg Uy1QbGFpbi4gJm5ic3A7V2UNCnRoZW4gZW52aXNpb24gYW4gYWR2YW5jZWQgY2xpZW50IGxpYnJh cnkgd2hpY2ggYWxzbyBpbXBsZW1lbnRzIEhNQUMgU0hBLTI1Ni4pPG86cD48L286cD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCg0KPC9kaXY+DQoNCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7DQptYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+QWxzbyBrZWVwIGlu IG1pbmQgdGhhdCB0aGUgY3VycmVudA0KcHJvcG9zYWwgbW92ZXMgdGhlIGFsZ29yaXRobSBjaG9p Y2UgdG8gdGhlIHRva2VuIHJlcXVlc3QvaXNzdWUgcGhhc2UuIEVhY2gNCnRva2VuIHdpbGwgb25s eSB3b3JrIHdpdGggYSBzaW5nbGUgYWxnb3JpdGhtICh3aGljaCBpcyBiZXR0ZXIgY3J5cHRvZ3Jh cGhpYw0KaHlnaWVuZSkuIFNvIGEgdmVuZG9yIGNhbiBjaG9vc2UgdG8gYWxsb3cgdGhlIGNsaWVu dCB0byBwaWNrIHRoZSBhbGdvcml0aG0gdGhleQ0Kd2FudCB0byB5b3UsIG9yIGp1c3QgdGVsbCB0 aGVtIHdoaWNoIG9uZSB0aGV5IGFyZSBnb2luZyB0byB1c2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Ij5FSEw8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N Cg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCg0KPGRpdj4NCg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiBMdWtlDQpTaGVwYXJkIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmxzaGVwYXJkQGZhY2Vib29r LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9Im1haWx0bzpsc2hlcGFyZEBmYWNlYm9vay5j b20iPmxzaGVwYXJkQGZhY2Vib29rLmNvbTwvYT48L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBKYW51YXJ5IDI4LCAyMDEwIDY6MzYgUE08YnI+DQo8Yj5Ubzo8L2I+IEVyYW4gSGFt bWVyLUxhaGF2OyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gRGlzY3Vzc2lvbiBvZiBTU0wgYXMg dGhlIHByaW1hcnkgbWVhbnMgZm9yIE9BdXRoDQpjb21tdW5pY2F0aW9uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIHJl cGx5LCBFcmFuLjxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCB5b3VyIHByb3Bvc2VkIGRlc2lnbiBo YXMgaXQgYmFja3dhcmRzOiBzZXJ2ZXJzIHNob3VsZCBiZWFyDQpjb21wbGV4aXR5IGFuZCBvbmUt dGltZSBjb3N0cywgbm90IGNsaWVudHMuIE11Y2ggb2Ygd2h5IEkgdGhpbmsgT0F1dGggV1JBUCAv DQoyLjAgaXMgc28gYXBwZWFsaW5nIGlzIHRoYXQgaXQgZHJhbWF0aWNhbGx5IHNpbXBsaWZpZXMg bGlmZSBmb3IgZGV2ZWxvcGVycy4gSWYNCmEgY2xpZW50IGNhbiBzdXBwb3J0IFNTTCBhbmQgZG9l c27igJl0IHdhbnQgdG8gZGVhbCB3aXRoIHNpZ25hdHVyZXMsIHRoZW4NCnRoZXkgbmV2ZXIgc2hv dWxkIGhhdmUgdG8uIEkgd2FudCB0byBiZSBhYmxlIHRvIHdyaXRlIGEgdmVyeSBsaWdodHdlaWdo dA0KU1NMLW9ubHkgY2xpZW50IGxpYnJhcnkgdGhhdCBpcyBzdGlsbCBmdWxseSBPQXV0aCAyLjAg Y29tcGF0aWJsZS48YnI+DQo8YnI+DQpJIHRoaW5rIGluc3RlYWQsIHRoZSBjb25zZW5zdXMgc2hv dWxkIGJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHVsIHR5cGU9ImRpc2MiPg0KIDxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQogICAgIG1zby1saXN0OmwwIGxldmVsMSBsZm8zIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+U3VwcG9ydCBhbg0KICAgICBleHRlbnNpYmxlIHNldCBv ZiBzaWduYXR1cmUgYWxnb3JpdGhtcyA8L3NwYW4+PG86cD48L286cD48L2xpPg0KIDxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQogICAgIG1zby1saXN0OmwwIGxldmVsMSBsZm8zIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+U2VydmVycyByZXF1aXJlZA0KICAgICB0byBzdXBwb3J0IHBs YWludGV4dCB0b2tlbnMgb3ZlciBhIHNlY3VyZSBjaGFubmVsIChTU0wvVExTKSA8L3NwYW4+PG86 cD48L286cD48L2xpPg0KIDxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQogICAgIG1zby1saXN0Omww IGxldmVsMSBsZm8zIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VydmVycyByZXF1 aXJlZA0KICAgICB0byBzdXBwb3J0IGF0IGxlYXN0IG9uZSBvciBhIHNtYWxsIHN1YnNldCBvZiBl bmNyeXB0aW9uIGFsZ29yaXRobXMuDQogICAgIFBvc3NpYmxlIGNhbmRpZGF0ZXMgaW5jbHVkZSBo bWFjLXNoYS0xLCBobWFjLXNoYS0yNTYsIGFuZCByc2Fzc2EuLi4uIDwvc3Bhbj48bzpwPjwvbzpw PjwvbGk+DQogPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCiAgICAgbXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DbGllbnRzIG11c3QNCiAgICAg c3VwcG9ydCBhdCBsZWFzdCBPTkUgb2YgdGhlIHJlcXVpcmVkIGVuY3J5cHRpb24gbWV0aG9kczwv c3Bhbj48bzpwPjwvbzpwPjwvbGk+DQo8L3VsPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YnI+DQpJZiBhIGNsaWVudCBzdXBwb3J0cyBhdCBsZWFz dCBvbmUgb2YgdGhlIHJlcXVpcmVkIG1ldGhvZHMgKFNTTCBvciBvbmUgb2YgdGhlDQphbGdvcml0 aG1zKSwgdGhlbiBpdCBjYW4gYmUgY29uc2lkZXJlZCBmdWxseSBPQXV0aCAyLjAgY29tcGxpYW50 LiBJZiBpdCBvbmx5DQpzdXBwb3J0cyBlbmNyeXB0aW9uIG1ldGhvZHMgdGhhdCBhcmUgbm90IGlu IHRoZSByZXF1aXJlZCBsaXN0LCB0aGVuIGl0IGlzDQpwYXJ0aWFsbHkgY29tcGxpYW50IOKAkyB0 aGF0IGlzLCBpdCBtYXkgd29yayB3aXRoIGEgc3BlY2lmaWMgdmVuZG9yIHRoYXQNCmFkdmVydGlz ZXMgc3VwcG9ydCBmb3IgdGhhdCBhbGdvcml0aG0sIGJ1dCBpdCB3b27igJl0IHdvcmsgd2l0aCBh bGwNCnNlcnZlcnMuIEFzIGFsZ29yaXRobXMgZ3JhZHVhbGx5IGNoYW5nZSBvdmVyIHRpbWUsIGNs aWVudCBsaWJyYXJpZXMgY2FuIGJlDQp1cGdyYWRlZCB3aGlsZSBzZXJ2ZXJzIG5lZWQgdG8gbWFp bnRhaW4gYmFja3dhcmRzIGNvbXBhdGliaWxpdHkuIChGb3IgZXhhbXBsZSwNCkZhY2Vib29rIHdp bGwgZGVwcmVjYXRlIE1ENSBhcyBpdHMgc2lnIGFsZ29yaXRobSwgYnV0IHdpbGwgY29udGludWUg dG8gc3VwcG9ydA0KaXQgZm9yIHRoZSBjbGllbnRzIHVzaW5nIGl0IGluIHRoZSB3aWxkKTxicj4N Cjxicj4NCkFzIGEgY29uY3JldGUgZXhhbXBsZSBvZiB3aGF0IGNhbiBiZSB3cml0dGVuIHdoZW4g eW91IGRvbuKAmXQgbmVlZCB0byB3b3JyeQ0KYWJvdXQgZW5jcnlwdGlvbiwgc2VlOiA8YSBocmVm PSJodHRwOi8vZ2l0aHViLmNvbS9sc2hlcGFyZC9vYXV0aC13cmFwLWRlbW8vdHJlZS9tYXN0ZXIv c3JjL3dyYXAuanMiIHRhcmdldD0iX2JsYW5rIj48YSBocmVmPSJodHRwOi8vZ2l0aHViLmNvbS9s c2hlcGFyZC9vYXV0aC13cmFwLWRlbW8vdHJlZS9tYXN0ZXIvc3JjL3dyYXAuanMiPmh0dHA6Ly9n aXRodWIuY29tL2xzaGVwYXJkL29hdXRoLXdyYXAtZGVtby90cmVlL21hc3Rlci9zcmMvd3JhcC5q czwvYT48L2E+PGJyPg0KSWYgSSB3ZXJlIHRvIG1vZGlmeSB0aGF0IEpTIHRvIGFjY29tbW9kYXRl IG11bHRpcGxlIHNpZ25hdHVyZSBhbGdvcml0aG1zLCB0aGVuDQpJIHdvdWxkIG5lZWQgdG8gaW5j bHVkZSBhdCBsZWFzdCBhbm90aGVyIDEtMmsgb2YgSmF2YVNjcmlwdCBmb3IgZWFjaCBtZXRob2QN Cmp1c3QgaW4gY2FzZS4gVGhhdCB3b3VsZCBiZSBmYWlybHkgcmlkaWN1bG91cy48YnI+DQo8YnI+ DQo8YnI+DQpPbiAxLzI4LzEwIDE6NDEgUE0sICJFcmFuIEhhbW1lci1MYWhhdiIgJmx0OzxhIGhy ZWY9Imh0dHA6Ly9lcmFuQGh1ZW5pdmVyc2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+PGEgaHJlZj0i bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+PC9hPiZn dDsNCndyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzIEx1a2UuIFRoaXMgaXMgYSB1c2VmdWwg YW5hbHlzaXMuPGJyPg0KJm5ic3A7PGJyPg0KSSBiZWxpZXZlIHdlIGhhdmUgYWxyZWFkeSByZWFj aGVkIGNvbnNlbnN1cyBpbiB0aGlzIHJlZ2FyZDo8YnI+DQombmJzcDs8YnI+DQoqIFN1cHBvcnQg YW4gZXh0ZW5zaWJsZSBzZXQgb2Ygc2lnbmF0dXJlIGFsZ29yaXRobXM8YnI+DQoqIERlZmluZSBo bWFjLXNoYS0xLCBobWFjLXNoYS0yNTYsIGFuZCByc2Fzc2EtcGtjczEtdjEuNS1zaGEtMjU2PGJy Pg0KKiBEZWZpbmUgYSBwbGFpbiBtZXRob2QgZm9yIGJlYXJlciB0b2tlbnMgYW5kIGVpdGhlciBy ZXF1aXJlIFNTTC9UTFMgb3INCnN0cm9uZ2x5IHJlY29tbWVuZCBpdCAob3BlbiBpc3N1ZSk8YnI+ DQombmJzcDs8YnI+DQooaWYgdGhlc2UgYXNzdW1wdGlvbnMgYXJlIGluY29ycmVjdCwgcmFpc2Ug eW91ciBoYW5kIG5vdyk8YnI+DQombmJzcDs8YnI+DQpUaGUgc3BlY2lmaWNhdGlvbiBpcyBnb2lu ZyB0byBkZWZpbmUgdGhlIGZvdXIgbWV0aG9kcyBhYm92ZSAoYW5kIHBvc3NpYmx5IG1vcmUpDQph cyAqPGI+bXVzdCBpbXBsZW1lbnQ8L2I+Ki4gVGhpcyBkb2VzIG5vdCBtZWFuIHZlbmRvcnMgaGF2 ZSB0byBzdXBwb3J0IGFsbCBvZg0KdGhlbSwgYnV0IHRoYXQgYW55ICo8Yj5jbGllbnQ8L2I+KiBs aWJyYXJ5IG9yIGFwcGxpY2F0aW9uIGNsYWltaW5nIHRvIGJlDQrigJhPQXV0aCAyLjAgY29tcGxp YW504oCZIG11c3QgaW1wbGVtZW50IGFsbCB0aGVzZSBtZXRob2RzLjxicj4NCiZuYnNwOzxicj4N CklmIGEgdmVuZG9yIGlzc3VlcyB0b2tlbnMgbm90IHVzaW5nIGFsbCB0aGVzZSBtZXRob2RzICh3 aGljaCBpcyBtb3JlIGxpa2VseSksDQppdCBkb2VzIG5vdCBoYXZlIHRvIGltcGxlbWVudCBhbGwg dGhlc2UgbWV0aG9kcyBhbmQgY2FuIHN0aWxsIGJlIGNhbGxlZA0K4oCYT0F1dGggMi4wIGNvbXBs aWFudOKAmSBiZWNhdXNlIGFueSBpdCBjYW4gaW50ZXJvcCB3aXRoICo8Yj5hbnk8L2I+Kg0KY29t cGxpYW50IGxpYnJhcnkuIEhvd2V2ZXIsIGlmIHN1Y2ggYSB2ZW5kb3IgcHJvZHVjZXMgYSBjbGll bnQgbGlicmFyeSBmb3IgaXRzDQpkZXZlbG9wZXJzIHdoaWNoIG9ubHkgaW1wbGVtZW50cyB0aGUg bWV0aG9kcyBkZXBsb3llZCBieSB0aGUgdmVuZG9yLCB0aGF0IGxpYnJhcnkNCmlzIOKAmE9BdXRo IDIuMCBwYXJ0aWFsbHkgY29tcGxpYW504oCZIChiZWNhdXNlIGl0IHdpbGwgbm90IGludGVyb3AN CndpdGggKjxiPmFsbDwvYj4qIHZlbmRvcnMpLjxicj4NCiZuYnNwOzxicj4NCkluIHByYWN0aWNl LCBmcm9tIEZhY2Vib29r4oCZcyBwZXJzcGVjdGl2ZSwgeW91IHdpbGwgYmUgYWJsZSB0byBkZXBs b3kNCk9BdXRoIDIuMCBpbiBhIGNvbXBsaWFudCB3YXksIHdoaWxlIG9ubHkgaW1wbGVtZW50aW5n IHRoZSBtZXRob2RzIHRoYXQgeW91IGZpbmQNCnN1aXRhYmxlIGZvciB5b3VyIGRldmVsb3BlcnMu IEl0IHNvdW5kcyBsaWtlIHlvdSB3aWxsIGJlIHVzaW5nIHRoZSBwbGFpbiBtZXRob2QNCm92ZXIg U1NMIGFuZCBlaXRoZXIgaG1hYy1zaGEtMSBvciBobWFjLXNoYS0yNTYuIFNpbmNlIEZhY2Vib29r IHVzdWFsbHkgbWFrZXMNCnRoaW5ncyB0cml2aWFsIGZvciBpdHMgZGV2ZWxvcGVycywgSSBleHBl Y3QgRmFjZWJvb2sgdG8gcHJvZHVjZSBsaWJyYXJpZXMgdGhhdA0Kd2lsbCBpbXBsZW1lbnQgdGhl c2UgdHdvIG1ldGhvZHMsIGJ1dCBub3Qgb3RoZXJzLiBUaGlzIHdpbGwgYmUgYQ0K4oCYRmFjZWJv b2sgQVBJ4oCZIGxpYnJhcnkgdGhhdCB1c2VzIE9BdXRoIDIuMC4gSXQgd2lsbCBiZSBwYXJ0aWFs bHkNCmNvbXBsaWFudCBidXQgdGhpcyBvbmx5IG1lYW5zIGl0IGlzIG9ubHkgZ3VhcmFudGVlZCB0 byB3b3JrIHdpdGggRmFjZWJvb2ssIGJ1dA0KdGhhdCBpdCBkb2VzIHNvIGluIGEgZnVsbHkgY29t cGxpYW50IHdheS48YnI+DQombmJzcDs8YnI+DQpFSEw8YnI+DQombmJzcDs8YnI+DQombmJzcDs8 YnI+DQombmJzcDs8YnI+DQombmJzcDs8YnI+DQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+IDxhIGhyZWY9Imh0dHA6Ly9vYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc8L2E+PC9hPiBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PC9hPl0NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+THVrZSBTaGVwYXJkPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5 IDI4LCAyMDEwIDc6MzAgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Imh0dHA6Ly9vYXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+ b2F1dGhAaWV0Zi5vcmc8L2E+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIERp c2N1c3Npb24gb2YgU1NMIGFzIHRoZSBwcmltYXJ5IG1lYW5zIGZvciBPQXV0aA0KY29tbXVuaWNh dGlvbjxicj4NCjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SW4g dGhlIGRpc2N1c3Npb25zIGFyb3VuZCB0aGUgT0F1dGggV1JBUCBzcGVjLA0Kb25lIG9mIHRoZSBx dWVzdGlvbnMgb2Z0ZW4gYXNrZWQgaXMsIOKAnHdoeSB1c2UgU1NMIGV4Y2x1c2l2ZWx5P+KAnQ0K U2V2ZXJhbCBvZiB1cyBoYXZlIGRvbmUgYSBsb3Qgb2YgdGhpbmtpbmcgb24gaXQgYW5kIEkgd2Fu dGVkIHRvIGFydGljdWxhdGUgbXkNCnVuZGVyc3RhbmRpbmcgb2YgdGhlIHByb3MgYW5kIGNvbnMg b2YgdGhlIGFwcHJvYWNoIGZvciBkaXNjdXNzaW9uLiBUaGUgdXNlIGNhc2UNCkkgcHJpbWFyaWx5 IGhhdmUgaW4gbWluZCBpcyB0aGF0IG9mIGEgd2ViIHNlcnZpY2UsIGxpa2UgRmFjZWJvb2ssIFR3 aXR0ZXIsIG9yDQpHb29nbGUgc2VydmljZXMuIE91ciBzZXJ2aWNlIGlzIHByaW1hcmlseSBhdXRo ZW50aWNhdGVkIHZpYSB0aGUgV2ViLCBidXQgd2UNCmhhdmUgYSB1c2UgZm9yIGFsbCBvZiB0aGUg V1JBUCBwcm9maWxlcyAod2ViIGFwcCwgY2xpZW50IGFwcCwgZGVza3RvcCwgbW9iaWxlKS48YnI+ DQombmJzcDs8YnI+DQpPdmVyYWxsLCBJIHRoaW5rIHRoYXQgdGhlIHNpbXBsaWNpdHkgb2YgdXNp bmcgU1NMIG91dHdlaWdocyBhbGwgdGhlIGFzc29jaWF0ZWQNCmNvc3RzIGZvciBtb3N0IGRldmVs b3BlcnMuIEhvd2V2ZXIsIHdlIHNob3VsZCBvZmZlciBwbGFpbnRleHQgc2lnbmF0dXJlcyBhcyBh bg0Kb3B0aW9uYWwgcGVyZm9ybWFuY2UgZW5oYW5jZW1lbnQgZm9yIGFkdmFuY2VkIGRldmVsb3Bl cnMuPGJyPg0KPGJyPg0KPT0gQWR2YW50YWdlcyBvZiB1c2luZyBTU0wgZm9yIEFQSSBjYWxsczxi cj4NCjxicj4NCi0tIEl04oCZcyBvdmVyd2hlbG1pbmdseSBzaW1wbGVyIGZvciBkZXZlbG9wZXJz Ljxicj4NCknigJl2ZSBpbXBsZW1lbnRlZCBPcGVuSUQgYW5kIE9BdXRoLCBhbmQgSeKAmXZlIHdv cmtlZCBmb3IgeWVhcnMgd2l0aA0KZGV2ZWxvcGVycyB0cnlpbmcgdG8gaGFuZGxlIHNpZ25hdHVy ZXMgb24gdGhlIEZhY2Vib29rIFBsYXRmb3JtLiBJbiBteQ0KZXhwZXJpZW5jZSwgY2FsY3VsYXRp bmcgc2lnbmF0dXJlcyBpcyBvbmUgb2YgdGhlIG1vc3QgY29tcGxleCBhbmQgZGlmZmljdWx0DQpw YXJ0cyBvZiBhbiBhdXRoZW50aWNhdGlvbiBwcm90b2NvbCwgYW5kIGRldmVsb3BlcnMgb2Z0ZW4g Z2V0IGl0IHdyb25nLiBCeQ0KbW92aW5nIHRoYXQgcGllY2UgZG93biB0aGUgc3RhY2sgd2UgY2Fu IGdldCBpdCBvdXQgb2YgdGhlaXIgd2F5IGFuZCBsZXQNCmRldmVsb3BlcnMgZm9jdXMgb24gYnVp bGRpbmcgdGhlaXIgYXBwcy48YnI+DQo8YnI+DQotLSBFeGlzdGluZyB0b29scyBlY29zeXN0ZW08 YnI+DQpJdOKAmXMgbm90IHRoYXQgU1NMIGlzIGEgc2ltcGxlciBlbmNyeXB0aW9uIHByb3RvY29s IHRoYW4gT0F1dGggKGl04oCZcw0Kbm90KSBidXQgcmF0aGVyIHRoYXQgY29tbW9ubHkgYXZhaWxh YmxlIHRvb2xzIGFsbW9zdCB1bml2ZXJzYWxseSBzdXBwb3J0IGl0DQrigJMgZXZlcnkgbWFqb3Ig d2ViIGJyb3dzZXIsIGFzIHdlbGwgYXMgbW9zdCBsaWJyYXJpZXMgZm9yIG1ha2luZyBIVFRQDQpy ZXF1ZXN0cyAobGlrZSBjdXJsKSBoYXZlIGJ1aWx0LWluIHN1cHBvcnQgZm9yIFNTTC4gRm9yIE9B dXRoIDEuMCwgeW91IG5lZWQgdG8NCnVzZSBhIGNsaWVudCBsaWJyYXJ5IGp1c3QgdG8gY29uc3Ry dWN0IHlvdXIgdmVyeSBmaXJzdCByZXF1ZXN0Ljxicj4NCjxicj4NCi0tIFNtYWxsZXIgY2xpZW50 IGxpYnJhcmllczxicj4NCkEgZ29vZCBjaHVuayBvZiBjb2RlIGluIG1hbnkgY2xpZW50IGxpYnJh cmllcyBpcyBkZXZvdGVkIHRvIGNhbGN1bGF0aW5nIGFuZA0KdmVyaWZ5aW5nIHNpZ25hdHVyZXMu IEZvciBleGFtcGxlLCB0aGUgT3BlbklEIFBIUCBsaWJyYXJ5IGltcG9ydHMgc2V2ZXJhbA0KQmln TWF0aCBtb2R1bGVzIGFuZCBlbmNyeXB0aW9uIHNjaGVtZXMuIEV2ZW4gdGhlIHJlbGF0aXZlbHkg c2ltcGxlciBGYWNlYm9vaw0KY2xpZW50IGxpYnJhcnkgcmVxdWlyZXMgc2V2ZXJhbCBmdW5jdGlv bnMgdG8gc2lnbiByZXF1ZXN0cy4gVGhpcyBtYWtlcyB0aGUNCmNsaWVudCBsaWJyYXJpZXMgYSBi bGFjayBib3ggYW5kIGltcGVkZXMgdW5kZXJzdGFuZGluZy4gPGJyPg0KPGJyPg0KV291bGRu4oCZ dCBpdCBiZSBncmVhdCBpZiB3ZSBjb3VsZCB3cml0ZSBhIHByb3RvY29sIHRoYXQgZG9lc27igJl0 IGV2ZW4NCnJlcXVpcmUgYSBjbGllbnQgbGlicmFyeSB0byBpbXBsZW1lbnQ/IElmIEkgY291bGQg anVzdCBtYWtlIGFuIGF1dGhlbnRpY2F0ZWQNCkFQSSByZXF1ZXN0IGluIG15IGJyb3dzZXIsIGFz IGVhc2lseSBhcyB3aXRoIEJhc2ljIEF1dGg/PGJyPg0KPGJyPg0KPT0gRGlzYWR2YW50YWdlcyBv ZiB1c2luZyBTU0wgZm9yIEFQSSBjYWxsczxicj4NCjxicj4NCi0tIERpZmZpY3VsdGllcyBvZiBk ZWJ1Z2dpbmc8YnI+DQo8YnI+DQpCb3RoIHNpZ25hdHVyZXMgYW5kIFNTTCBwcmVzZW50IGRpZmZp Y3VsdGllcyBpbiBkZWJ1Z2dpbmcsIGJ1dCB0aGV5IHRlbmQgdG8gYmUNCmRpZmZlcmVudC4gV2hp bGUgd2l0aCBzaWduYXR1cmVzIHlvdSB3b3JyeSBhYm91dCBjb21wb3NpbmcgdGhlIGFyZ3VtZW50 cyB3cm9uZw0Kb3IgdXNpbmcgdGhlIHdyb25nIGFsZ29yaXRobSwgd2l0aCBTU0wgeW91IHdvcnJ5 IGFib3V0IHJlYWRpbmcgdGhlIHJlcXVlc3Qgb3Zlcg0KdGhlIHdpcmUuIFlvdSBjYW7igJl0IHNu aWZmIGEgcmVxdWVzdCwgYW5kIHRvIGludGVyY2VwdCBpdCwgeW91IG5lZWQgYW4NCkhUVFAgcHJv eHkgdGhhdCB1bmRlcnN0YW5kcyBTU0wsIGFuZCB5b3UgbmVlZCB0byB3b3JyeSBhYm91dCBpbnZh bGlkDQpjZXJ0aWZpY2F0ZSBlcnJvcnMuIFRvIGFpZCBpbiB0aGlzLCBwcm92aWRlcnMgd2lsbCBw cm9iYWJseSBvZmZlciBhIG5vbi1TU0wNCmVuZHBvaW50IGZvciBkZWJ1Z2dpbmcsIGJ1dCB0aGV5 IG1heSBuZWVkIHRvIHNldCB1cCBhIHNhbmRib3ggZW52aXJvbm1lbnQgdG8NCnByZXZlbnQgZGFt YWdlIGZyb20gdG9rZW5zIGV4cG9zZWQgaW4gcGxhaW50ZXh0Ljxicj4NCjxicj4NCi0tIFZhcmlh YmxlIGNvc3RzIGZvciBwcm92aWRlcnM8YnI+DQo8YnI+DQpTZXJ2ZXIgQ1BVIGNvc3RzIHdpbGwg aW5jcmVhc2Ugd2hlbiBoYW5kbGluZyBTU0wgcmVxdWVzdHMg4oCTIGVzcGVjaWFsbHkgb24NCmV2 ZXJ5IEFQSSBjYWxsIGluc3RlYWQgb2YganVzdCBhdCB0aGUgYXV0aCBzdGFnZS4gQXQgc2NhbGUs IHRoaXMgY2FuIGJlY29tZQ0KZXhwZW5zaXZlLCBhbHRob3VnaCBpdCBjYW4gYmUgb2Zmc2V0IGJ5 IHVzaW5nIHNwZWNpYWxpemVkIGhhcmR3YXJlIHRvIHRlcm1pbmF0ZQ0KdGhlIFNTTCBjb25uZWN0 aW9uLiBBbGwgdGhlIGJpZyBjb21wYW5pZXMgSeKAmXZlIHRhbGtlZCB0byBhcmUgY29tZm9ydGFi bGUNCnRyYWRpbmcgdGhlc2UgaGlnaGVyIGNvc3RzIGZvciBpbmNyZWFzZWQgYWRvcHRpb24gZHVl IHRvIHRoZSBzaW1wbGljaXR5Ljxicj4NCjxicj4NCi0tIEZpeGVkIGNvc3RzIGZvciBzbWFsbGVy IHByb3ZpZGVyczxicj4NCjxicj4NClRoZXJlIGlzIGEgZml4ZWQgY29zdCB0byBvYnRhaW5pbmcg YW5kIHNpZ25pbmcgYW4gU1NMIGNlcnRpZmljYXRlcywgYWx0aG91Z2gNCnRoYXQgaGFzIGRyb3Bw ZWQgaW4gcmVjZW50IHllYXJzIHN1Y2ggdGhhdCBhbiBvcGVyYXRvciBjYW4gaGF2ZSBhIGNlcnQg c2lnbmVkDQpmb3IgYSBzaW5nbGUgZG9tYWluIGZvciBwcmV0dHkgY2hlYXAuPGJyPg0KPGJyPg0K LS0gTGF0ZW5jeTxicj4NCjxicj4NClNTTCBjb25uZWN0aW9ucyB0YWtlIG1vcmUgdGltZSB0byBl c3RhYmxpc2ggdGhhbiBub3JtYWwgSFRUUCBjb25uZWN0aW9ucy4NClNlcnZlcnMgY2FuIHVzZSBz cGVjaWFsaXplZCBoYXJkd2FyZSB0byBzcGVlZCBpdCB1cCwgYnV0IGNsaWVudHMgcmFyZWx5IGRv LA0Kd2hpY2ggbWVhbnMgdGhhdCBmb3IgY2xpZW50LXRvLXNlcnZlciBBUEkgcmVxdWVzdHMsIHRo ZXJlIG1heSBiZSBzb21lIGhpZ2hlcg0KbGF0ZW5jeSBpbiBlYWNoIHJlcXVlc3QuIFNtYWxsZXIs IG1vYmlsZSBkZXZpY2VzIG1heSBiZSBkaXNwcm9wb3J0aW9uYXRlbHkNCmFmZmVjdGVkIGJ5IHRo aXMsIGJ1dCBhcyB0aGV5IGdyb3cgbW9yZSBwb3dlcmZ1bCBpdOKAmXMgbGVzcyBvZiBhIGNvbmNl cm4uDQpBbHJlYWR5IHRvZGF5IG5ld2VyIHBob25lcyBjYW4gaGFuZGxlIFNTTCBqdXN0IGZpbmUu PGJyPg0KPGJyPg0KLS0gQnJvd3NlciBsaW1pdGF0aW9ucyBmb3IgY3Jvc3MgZG9tYWluIGNvbW11 bmljYXRpb248YnI+DQo8YnI+DQpBIG1vcmUgbmljaGUgZGlzYWR2YW50YWdlIGlzIHRoYXQgc29t ZSBjcm9zcyBkb21haW4gY29tbXVuaWNhdGlvbiB0ZWNobmlxdWVzDQpyZXF1aXJlIHRoZSBwcm90 b2NvbCBvZiB0aGUgcGFyZW50IHBhZ2UgdG8gbWF0Y2ggdGhhdCBvZiB0aGUgZW5kcG9pbnQgYmVp bmcNCnF1ZXJpZWQuIFNvIGZvciBleGFtcGxlLCBpbiBzb21lIGJyb3dzZXJzLCBmb3Igc29tZSBB UEkgY2FsbHMsIGl0IHdvdWxkIGJlDQppbXBvc3NpYmxlIHRvIG1ha2UgYW4gQVBJIGNhbGwgdG8g YW4gSFRUUFMgZW5kcG9pbnQgZnJvbSBhIG5vcm1hbCBIVFRQIHBhZ2UuDQpIb3dldmVyLCBhcyBi cm93c2VycyBhZHZhbmNlIGFuZCBIVE1MNSBtZXRob2RzIGxpa2UgcG9zdE1lc3NhZ2UgYmVjb21l IG1vcmUNCmNvbW1vbiwgdGhpcyB3aWxsIGJlY29tZSBsZXNzIG9mIGFuIGlzc3VlLjxicj4NCjxi cj4NCi0tIFZlcmlmeWluZyBpbmZvcm1hdGlvbiBvbiB0aGUgcmVseWluZyBwYXJ0eTxicj4NCjxi cj4NCklmIGluZm9ybWF0aW9uIGlzIHBhc3NlZCBmcm9tIGEgU2VydmljZSBQcm92aWRlciB0byBh IENvbnN1bWVyIHRocm91Z2ggdGhlDQp1c2Vy4oCZcyBicm93c2VyLCB0aGVuIHRoYXQgaW5mb3Jt YXRpb24gY2Fubm90IGJlIHZlcmlmaWVkIHdpdGhvdXQgYW4gQVBJDQpjYWxsLCB1bmxlc3MgYSBz aWduYXR1cmUgaXMgcHJvdmlkZWQuIFNpbWlsYXIgdG8gc3RhdGVmdWwgdnMuIHN0YXRlbGVzcyBt b2RlIGluDQp0aGUgT3BlbklEIDIuMCBzcGVjLCB0aGUgc2lnbmF0dXJlIGNhbiBzZXJ2ZSBhcyBh IHBlcmZvcm1hbmNlIGVuaGFuY2VtZW50IHRvDQphdm9pZCBhbiBBUEkgY2FsbC48YnI+DQo8YnI+ DQo9PSBQcm92aWRpbmcgYSBub24tU1NMIG9wdGlvbiBmb3IgdGhlIHNob3J0IGhlYWQ8YnI+DQo8 YnI+DQpNb3N0IHBsYXRmb3JtcyB0ZW5kIHRvIGhhdmUgYSBzbWFsbCBudW1iZXIgb2YgZmFpcmx5 IGxhcmdlIGRldmVsb3BlcnMgYW5kIHRoZW4NCmEgcmVhbGx5IGxhcmdlIG51bWJlciBvZiBzbWFs bGVyIGRldmVsb3BlcnMuIFRoZSBmb3JtZXIgYXJlIHR5cGljYWxseQ0KZXhwZXJpZW5jZWQgKG9y IGF0IGxlYXN0LCB0aGV5IGFyZSBieSB0aGUgdGltZSB0aGV5IGdldCBiaWcpIGFuZCBoYXZlIG1h ZGUgYQ0KbGFyZ2UgaW52ZXN0bWVudCBpbiB0aGUgcGxhdGZvcm0uIFRoZSBsYXR0ZXIgcmFuZ2Ug ZnJvbSBleHBlcmllbmNlZCBkZXZlbG9wZXJzDQp0byBhbWF0ZXVycyB0byBmb2xrcyB0aGF0IHdv dWxkIG5vdCB0eXBpY2FsbHkgcHJvZ3JhbS4gRm9yIHRoaXMgc3BlYyB0byBiZQ0Kc3VjY2Vzc2Z1 bCwgaXQgbXVzdCBtZWV0IHRoZSBuZWVkcyBvZiBib3RoIGdyb3Vwcy48YnI+DQo8YnI+DQpGYWNl Ym9vayBpcyB2ZXJ5IGludGVyZXN0ZWQgaW4gYWRvcHRpbmcgT0F1dGggV1JBUCAvIDIuMCAvIHdo YXRldmVyIGJlY2F1c2Ugd2UNCndhbnQgdG8gaGVscCBvdXIgbG9uZyB0YWlsIGRldmVsb3BlcnMg dXNlIG91ciBwbGF0Zm9ybSBtb3JlIGVhc2lseS4gRm9yIHRoZQ0KbG9uZyB0YWlsLCB0aGUgc2lt cGxpY2l0eSBwcm92aWRlZCBieSBTU0wgd2lsbCBiZSBjcnVjaWFsLiBJdCBtZWFucyBzbWFsbGVy IG9yDQpub25leGlzdGVudCBjbGllbnQgbGliYXJpZXMsIGl0IG1lYW5zIHRoYXQgZGV2ZWxvcGVy cyBjYW4ganVzdCB0cnkgb3V0IHRoZSBBUEkNCmJ5IHR5cGluZyBpdCBpbnRvIGEgd2ViIGJyb3dz ZXIsIGFuZCBpdCB3aWxsIGhlbHAgcmVkdWNlIGRlYnVnZ2luZyBhbmQNCm1haW50ZW5hbmNlIGNv c3RzLjxicj4NCjxicj4NCkhvd2V2ZXIsIGZvciB0aGUgc2hvcnQgaGVhZCBvZiBoaWdoIHZvbHVt ZSBkZXZlbG9wZXJzLCB3ZSBwcm9iYWJseSB3YW50IGFuIG9wdGlvbg0KdG8gdXNlIHNvbWV0aGlu ZyBvdGhlciB0aGFuIFNTTCB0byBtYWtlIHNlY3VyZSByZXF1ZXN0cy4gVGhlc2UgZGV2ZWxvcGVy cyB0ZW5kDQp0byBoYXZlIGFscmVhZHkgc29sdmVkIHRoZSBsb3cgaGFuZ2luZyBwZXJmb3JtYW5j ZSBmcnVpdCwgYW5kIGZvciB0aGVtIGl0IG1heQ0KYmUgYSBzaWduaWZpY2FudCBwZW5hbHR5IHRv IHBheSB0aGUgU1NMIGNvbm5lY3Rpb24gY29zdCBvbiBldmVyeSByZXF1ZXN0LiBUbw0KdGhhdCBl bmQsIEkgdGhpbmsgaXTigJlzIHByZXR0eSBpbXBvcnRhbnQgdGhhdCBPQXV0aCAyLjAgc3VwcG9y dCBhIG1ldGhvZA0Kb3RoZXIgdGhhbiBTU0wgYXMgYW4gb3B0aW9uIGZvciBhZHZhbmNlZCBkZXZl bG9wZXJzLiBCdXQgaXQgc2hvdWxkIGJlIGp1c3QgdGhhdA0K4oCTIGFuIG9wdGlvbiwgYW5kIG9u bHkgZm9yIGFkdmFuY2VkIGRldmVsb3BlcnMsIHNvIHRoYXQgYmVnaW5uaW5nDQpwcm9ncmFtbWVy cyBhbmQgZm9sa3MgbGVhcm5pbmcgYW4gQVBJIGRvbuKAmXQgbmVlZCB0byB3b3JyeSBhYm91dA0K c2lnbmF0dXJlcyB3aGVuIHRoZXkganVzdCB3YW50IHRvIHBsYXkgYXJvdW5kLjxicj4NCjxicj4N ClBsZWFzZSBsZXQgbWUga25vdyBpZiBJ4oCZbSBtaXNzaW5nIHNvbWV0aGluZyBvciBpZiBteSBh c3N1bXB0aW9ucyBzb3VuZA0KaW5jb3JyZWN0Ljxicj4NCjxicj4NCi1MdWtlIFNoZXBhcmQ8YnI+ DQpTb2Z0d2FyZSBFbmdpbmVlciwgRmFjZWJvb2sgUGxhdGZvcm08L3NwYW4+PG86cD48L286cD48 L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRo IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PGEgaHJl Zj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0 PSJfYmxhbmsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9h PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Jsb2NrcXVvdGU+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 L2Rpdj4NCg0KDQoNCg0KPC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L3NwYW4+PGJyPjxzcGFuPk9BdXRoIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+PHNwYW4+PGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48L3NwYW4+PGJy PjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9zcGFu Pjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --_000_A2CF729A181248C98C9623BAD0947C49hueniversecom_-- From grastogi@adobe.com Fri Jan 29 11:58:15 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0483E3A67E7 for ; Fri, 29 Jan 2010 11:58:15 -0800 (PST) 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 PPDzQpanIvcv for ; Fri, 29 Jan 2010 11:58:13 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by core3.amsl.com (Postfix) with ESMTP id 640753A67DA for ; Fri, 29 Jan 2010 11:58:13 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKS2M97FlvitiHHd+tlbSK3yoQr+YAWEW5@postini.com; Fri, 29 Jan 2010 11:58:37 PST Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id o0TJok18029149 for ; Fri, 29 Jan 2010 11:50:46 -0800 (PST) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id o0TJtA8F016787 for ; Fri, 29 Jan 2010 11:58:33 -0800 (PST) Received: from nacas03.corp.adobe.com (10.8.189.121) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 29 Jan 2010 11:58:17 -0800 Received: from NAMBX02.corp.adobe.com ([10.8.127.96]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Fri, 29 Jan 2010 11:58:17 -0800 From: Gaurav Rastogi To: "oauth@ietf.org" Date: Fri, 29 Jan 2010 11:58:15 -0800 Thread-Topic: exclude hostname and port number from normalized string Thread-Index: AcqhHWZGuxOibMAvTH6CoQs6W0OgBg== Message-ID: 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_CF4F27E3920D49C2A871EABA4B1A0F10adobecom_" MIME-Version: 1.0 Subject: [OAUTH-WG] exclude hostname and port number from normalized string X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jan 2010 20:03:58 -0000 --_000_CF4F27E3920D49C2A871EABA4B1A0F10adobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This proposal is to allow use of same token to access multiple protected resource across different servers. At minimum making it optional would help in wide variety of media delivery use cases. Proposal details: Exclude hostname and port number in normalized request string creation. Another possible approach could be to allow modifications of the subdomains as consistent with the name server RFC. Background: Adobe Media Streaming (HTTP and RTMP) use cases. Current Adobe's IPTV and web video services partners including large media broadcasting companies, CDN services, and IPTV solutions vendors all face the problem that multiple resources need to be used for making a single web video experience. In case of HTTP media streaming a single content delivery may comprise of hundreds of individual http fragments served that are delivered over multiple network connections using multiple media assets. In addition, Advertising, DRM and License server API/interaction may also be involved. When dynamic streaming or multi-bit rate media is being streamed then fragments from different versions of the asset are requested based on real time network and client feedback. Client re-authorization can result in high a latency and non-realtime system degrading the user experience in wide variety of rich media solutions delivered over the internet. In several load balancing solutions like CENAME or request redirection may modify server URI based on runtime considerations. Many CDN workflows and global Internet services use such schemes. Having mandatory hostname, which could have been modified, restricts use of HTTP token obtained before the load balancing decision was made. Example workflow +---+ +---------------+ | C |--(A)------ credentials --------->| Authorization | | l |<-(B)------ Access Token ---------| Server | | i | +---------------+ | e | | n | +---+ Access Token +---------------+ | t | | W |--(C)----- in HTTP header ------->| Protected | | | | e |<-(D)------ API response ---------| Resource[0] | | |->| b | +---------------+ | | | | Access Token +---------------+ | |<-| S |--(E)----- in HTTP header ------->| Protected | | | | e |<-(F)------ API response ---------| Resource[i] | | | | r | +---------------+ | | | V | Access Token +---------------+ | | | i |--(G)----- in HTTP header ------->| Protected | | | | c |<-(H)------ API response ---------| Resource[N] | | | | e | +---------------+ +---+ +---+ Figure 1. In the above Figure 1, client uses a webservice which performs a single authorization to obtain an opaque access token. It then uses the same acces= s token to request multiple protected resources without needing to re-authori= ze every time a new resource is used. C,D: Request for license to decrypt the HD content E,F: Multiple requests for the media fragments for HD content G,H: Change request for lower bit-rate content in case there is network congestion or need for lower resources on client. This request may happen a= fter 30 mins of the start of the rich media experience session. Thanks, Gaurav Rastogi Adobe Systems --_000_CF4F27E3920D49C2A871EABA4B1A0F10adobecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This proposal is to allow use of same token to= access multiple
protected resource across different servers. At minimum making it<= br>optional would help in wide variety of media delivery use cases. &n= bsp;

Proposal details:
Exclude hostname and port number in normal= ized request string
creation. Another possible approach could be to allo= w modifications
of the subdomains as consistent with the name server RFC= .

Background: Adobe Media Streaming (HTTP and RTMP) use cases.=
Current Adobe's IPTV and web video services partners including largemedia broadcasting companies, CDN services, and IPTV solutions vendors
= all face the problem that multiple resources need to be used for
making = a single web video experience.

In case of HTTP media str= eaming a single content delivery may comprise
of hundreds of individual = http fragments served that are delivered
over multiple network connectio= ns using multiple media assets. In
addition, Advertising, DRM and Licens= e server API/interaction may also
be involved.

When dynamic strea= ming or multi-bit rate media is being streamed then
fragments from diffe= rent versions of the asset are requested based on
real time network and = client feedback. Client re-authorization can
result in high a latency an= d non-realtime system degrading the user
experience in wide variety of r= ich media solutions delivered over the
internet.

In several load = balancing solutions like CENAME or request redirection
may modify server= URI based on runtime considerations. Many CDN
workflows and global Inte= rnet services use such schemes. Having
mandatory hostname, which could h= ave been modified, restricts use of
HTTP token obtained before the load = balancing decision was made.

Example wo= rkflow
   +---+ &nbs= p; &n= bsp;+---------------+
   | C |--(A)------ credentials -= -------->| Authorization |
   | l |<-= (B)------ Access Token ---------| Server |
&n= bsp; | i | &n= bsp; +-------= --------+
   | e |
   | n | += ---+ Access Token &n= bsp; +---------------+
   | t | | W = |--(C)----- in HTTP header ------->| Protected |
= | | | e |<-(D)------ API response ---------| = Resource[0] |
   | |->| b | &nb= sp; &= nbsp; +---------------+
   |= | | | Access = Token +---------------+
   &= nbsp; | |<-| S |--(E)----- in HTTP header ------->| Protected = |
   | | | e |<-(F)------= API response ---------| Resource[i] |
   | &nbs= p; | | r | &n= bsp; +--------------= -+
   | | | V | = ; Access Token +------------= ---+
   | | | i |--(G)----- in HTTP header= ------->| Protected |
   | | &= nbsp;| c |<-(H)------ API response ---------| Resource[N] |
&n= bsp; | | | e | = &nbs= p; +---------------+
   +---+ +---+
&nbs= p; &nb= sp; Figure 1.
In the above Figure 1, client uses a webs= ervice which performs a single
authorization to obtain an opaque access = token. It then uses the same access
token to request multiple protected = resources without needing to re-authorize
every time a new resource is u= sed.
C,D: Request for license to decrypt the HD content
E,F: Mu= ltiple requests for the media fragments for HD content
G,H: Change reque= st for lower bit-rate content in case there is network
congestion or nee= d for lower resources on client. This request may happen after
30 mins o= f the start of the rich media experience session.

= Thanks,
= Gaurav Rastogi
Adobe Systems

= --_000_CF4F27E3920D49C2A871EABA4B1A0F10adobecom_-- From eve@xmlgrrl.com Fri Jan 29 13:07:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCFFB3A68D3 for ; Fri, 29 Jan 2010 13:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.308 X-Spam-Level: ** X-Spam-Status: No, score=2.308 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FROM_DOMAIN_NOVOWEL=0.5, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_17=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD-v50HQChUJ for ; Fri, 29 Jan 2010 13:07:29 -0800 (PST) Received: from mail.promanage-inc.com (static-98-111-84-13.sttlwa.fios.verizon.net [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id D6B433A659A for ; Fri, 29 Jan 2010 13:07:28 -0800 (PST) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.3/8.14.3) with ESMTP id o0TL7SXg012864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Jan 2010 13:07:51 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450220F59F@FIESEXC015.nsn-intra.net> Date: Fri, 29 Jan 2010 13:07:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1562D46F-058C-4EE6-956C-469719CA3E81@xmlgrrl.com> <3D3C75174CB95F42AD6BCC56E5555B450220F59F@FIESEXC015.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1077) Cc: OAuth WG Subject: Re: [OAUTH-WG] FYI, UMA webinar followup X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jan 2010 21:07:31 -0000 Hi-- We had a bit of a glitch in the half-hour before the webinar, and = sent out fresh notification emails. It sounds like you didn't get = yours, for which I'm very sorry! We had about 20 people on. There will = be a recording (audio/video) available soon -- I'll alert this list at = that time -- and the slides and wireframes are all linked from here: http://kantarainitiative.org/confluence/display/uma/UMA+Explained Specifically, we presented these materials in the order listed: = http://kantarainitiative.org/confluence/download/attachments/37751312/uma-= webinar-2010-01-29.pdf = http://kantarainitiative.org/confluence/download/attachments/37751312/UMA_= CV_wireframeV7.pdf = http://kantarainitiative.org/confluence/download/attachments/37751312/UMA-= protocol-flow-deep-dive.pdf Eve On 29 Jan 2010, at 11:24 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > I registered for the seminar, got the bridge info, dialed in and = nobody > was there.=20 > Are there slides available?=20 >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 >> On Behalf Of ext Eve Maler >> Sent: 25 January, 2010 14:03 >> To: OAuth WG >> Subject: [OAUTH-WG] FYI, UMA webinar followup >>=20 >> I think I mentioned on last week's call that those of us=20 >> working on UMA are doing a status update in a webinar on=20 >> Thursday of this week. You're invited to sign up (there's a=20 >> small handful of slots left). Info and registration link are here: >>=20 >> http://kantarainitiative.org/confluence/display/uma/Meetings+an >> d+Minutes >>=20 >> Eve >>=20 Eve Maler eve@xmlgrrl.com http://www.xmlgrrl.com/blog