From stpeter@stpeter.im Tue Feb 2 14:07: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 ECB5E3A6A1C for ; Tue, 2 Feb 2010 14:07:49 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OficTPg7d6ti for ; Tue, 2 Feb 2010 14:07:49 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1CB513A69B2 for ; Tue, 2 Feb 2010 14:07:49 -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 DF79B40332; Tue, 2 Feb 2010 15:08:26 -0700 (MST) Message-ID: <4B68A258.3070908@stpeter.im> Date: Tue, 02 Feb 2010 15:08:24 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: David Recordon References: <4B61AFF0.6060302@stpeter.im> 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="------------ms050701050306070006060308" 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: Tue, 02 Feb 2010 22:07:50 -0000 This is a cryptographically signed message in MIME format. --------------ms050701050306070006060308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/28/10 11:35 PM, David Recordon wrote: > Hey Peter, > Luke put together a spreadsheet comparing the terminology across five o= r > six different protocols. Hopefully he'll share it. :) That would be great. I'll ping him off-list, or he can just attach it to http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthTerms by first provisioning an account at http://tools.ietf.org/newlogin :) > I have a pretty strong preference of sticking with OAuth 1.0 terminolog= y > as much as possible. Agreed. --------------ms050701050306070006060308 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 hvcNAQkFMQ8XDTEwMDIwMjIyMDgyNFowIwYJKoZIhvcNAQkEMRYEFOH621W0eyDTEkjqhMIo neLWuGqqMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAWc/oXdh3+pqrpCdliXZWrNs//vd1PrROWn0bVJzz 4MRHWYVODx3L66Bt15dKfmnhxySi1EkVIVfBcuM0fv691gSmwiPpI1EPkvFayQLQjYx4ZQaE OKOnB9GVDdWlDgdOFqHXBYDVhyUd+WwQfTr4UIaDjV3tRHdhmioa/0CAURjb7wuZyH/2uOp6 WNK0xla2Lt7HtPsKNTeZQ9Epe3g1O1PE5q03pPRtbg+3FyrgqiiZGvzRZ2BdNXOqhM6Yd5RZ np4OVl30wR6tQ/fUcKuGKim2tLiEfYrpTrDUvMQQFlK2g6nIe48/Hifkl23GSZWeokBuIqKA Lh2X6/QJU7skTwAAAAAAAA== --------------ms050701050306070006060308-- From dick.hardt@gmail.com Tue Feb 2 14:12:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 032253A688D for ; Tue, 2 Feb 2010 14:12:35 -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 j-WpsYHoQ5xR for ; Tue, 2 Feb 2010 14:12:30 -0800 (PST) Received: from mail1.sxip.com (nvg-01-e0.yvr.sxip.com [72.15.146.183]) by core3.amsl.com (Postfix) with ESMTP id 438C03A69B2 for ; Tue, 2 Feb 2010 14:12:20 -0800 (PST) Received: from [192.168.1.243] (c-24-17-212-68.hsd1.wa.comcast.net [24.17.212.68]) (authenticated bits=0) by mail1.sxip.com (8.13.8/8.13.8) with ESMTP id o12MCrIr031992 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 2 Feb 2010 14:12:54 -0800 (PST) (envelope-from dick.hardt@gmail.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <4B68A258.3070908@stpeter.im> Date: Tue, 2 Feb 2010 14:12:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B61AFF0.6060302@stpeter.im> <4B68A258.3070908@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1077) X-Scanned-By: MIMEDefang 2.63 on 172.16.6.3 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: Tue, 02 Feb 2010 22:12:36 -0000 On 2010-02-02, at 2:08 PM, Peter Saint-Andre wrote: > On 1/28/10 11:35 PM, David Recordon wrote: >> I have a pretty strong preference of sticking with OAuth 1.0 = terminology >> as much as possible. >=20 > Agreed. The term "server" in OAuth 1.0 does not differentiate between the = Authorization Server and Protected Resource as are differentiated in = OAuth WRAP. The terms used in OAuth WRAP are a superset of OAuth 1.0 with changes to = provide additional clarity. -- Dick= From stpeter@stpeter.im Tue Feb 2 14:40: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 CC1C928C123 for ; Tue, 2 Feb 2010 14:40: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyzwg0kpaRvC for ; Tue, 2 Feb 2010 14:40:39 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A9CFD28C11F for ; Tue, 2 Feb 2010 14:40:39 -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 5BA8140332; Tue, 2 Feb 2010 15:41:18 -0700 (MST) Message-ID: <4B68AA0C.6030605@stpeter.im> Date: Tue, 02 Feb 2010 15:41:16 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dick Hardt References: <4B61AFF0.6060302@stpeter.im> <4B68A258.3070908@stpeter.im> 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="------------ms030007020201000906060108" 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: Tue, 02 Feb 2010 22:40:40 -0000 This is a cryptographically signed message in MIME format. --------------ms030007020201000906060108 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/2/10 3:12 PM, Dick Hardt wrote: >=20 > On 2010-02-02, at 2:08 PM, Peter Saint-Andre wrote: >> On 1/28/10 11:35 PM, David Recordon wrote: >>> I have a pretty strong preference of sticking with OAuth 1.0 >>> terminology as much as possible. >>=20 >> Agreed. >=20 > The term "server" in OAuth 1.0 does not differentiate between the > Authorization Server and Protected Resource as are differentiated in > OAuth WRAP. >=20 > The terms used in OAuth WRAP are a superset of OAuth 1.0 with changes > to provide additional clarity. I meant to say "agreed, where possible and reasonable". The point of this exercise is to make sure that we differentiate where that makes sense. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030007020201000906060108 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 hvcNAQkFMQ8XDTEwMDIwMjIyNDExNlowIwYJKoZIhvcNAQkEMRYEFMIx/RZs1HVo+utZFQJR ueFjm2F3MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAKHRLsMnOp42y3SSUkkO66chvulOyC4r3EE8YdooF ka15is9HQW+Msp1x2xnQeDcYhpfzQ/Hlp2nHbpXBj1SyEBFge+bRzo8BA2tmyLbyFINhUIb4 tjQbbBs8G0GP8Ny4fLakD8dL9+I23PQMOUJiCWG/vcnUFawdgJguzbnGLuz1rUZyaK7x2gqW 7Ybboqfm+5NJWUnxp943Kdcnv74Y3LP1+rKCHFcsb57D5ca5D6Vu9DcVqdvsWN/SrPWmnNse w6vqF2Ghm8xkVw9vjSvi9WwHceSwWRfcTM+7Pv5xrQ1S7P3wREzl+pfZO8X1EYYnY8MjgoMq FTi+IqFC54RauwAAAAAAAA== --------------ms030007020201000906060108-- From eve@xmlgrrl.com Tue Feb 2 15:16: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 618FC28C12C for ; Tue, 2 Feb 2010 15:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.008 X-Spam-Level: * X-Spam-Status: No, score=1.008 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FROM_DOMAIN_NOVOWEL=0.5, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, 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 sxLNmIelBUib for ; Tue, 2 Feb 2010 15:16:14 -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 60D4B28C101 for ; Tue, 2 Feb 2010 15:16:14 -0800 (PST) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by mail.promanage-inc.com (8.14.3/8.14.3) with ESMTP id o12NGUOE002017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Feb 2010 15:16:53 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <4B68AA0C.6030605@stpeter.im> Date: Tue, 2 Feb 2010 15:16:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2F8A5A2C-8F5D-4B97-BDD9-9ECFA6162A36@xmlgrrl.com> References: <4B61AFF0.6060302@stpeter.im> <4B68A258.3070908@stpeter.im> <4B68AA0C.6030605@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1077) 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: Tue, 02 Feb 2010 23:16:15 -0000 Related to this, in UMA we chose "Host" for the online service where a = protected resource can be accessed, because each resource found there = might potentially be subject to a different user-managed authorization = policy (that is, protection) regime. We've found this word to be quite = copacetic, as it's short and intuitive, has a unique single-letter = abbreviation, and doesn't imply that the service is the same thing as a = particular resource available at the service. At first, we tried to stick with "SP" for this entity -- this was before = the server/client terminology emerged in the OAuth 1.0 cleanup effort -- = but found it to be too confusing because the Host has an OAuth-mediated = relationship with the UMA Authorization Manager (note, not the same = thing as a WRAP Authorization Server!) that is consumer->SP / = client->server. I wonder if "Host" can work in the context of the WRAP patterns too, = since all the same things are true about this word in both contexts... BTW, here's a direct link to the UMA terminology section: = http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol#= UMA1.0CoreProtocol-Terminology Eve On 2 Feb 2010, at 2:41 PM, Peter Saint-Andre wrote: > On 2/2/10 3:12 PM, Dick Hardt wrote: >>=20 >> On 2010-02-02, at 2:08 PM, Peter Saint-Andre wrote: >>> On 1/28/10 11:35 PM, David Recordon wrote: >>>> I have a pretty strong preference of sticking with OAuth 1.0 >>>> terminology as much as possible. >>>=20 >>> Agreed. >>=20 >> The term "server" in OAuth 1.0 does not differentiate between the >> Authorization Server and Protected Resource as are differentiated in >> OAuth WRAP. >>=20 >> The terms used in OAuth WRAP are a superset of OAuth 1.0 with changes >> to provide additional clarity. >=20 > I meant to say "agreed, where possible and reasonable". The point of > this exercise is to make sure that we differentiate where that makes > sense. :) >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ Eve Maler eve@xmlgrrl.com http://www.xmlgrrl.com/blog From stpeter@stpeter.im Tue Feb 2 15:30:09 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7A83A69AE for ; Tue, 2 Feb 2010 15:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXq67y+bddlb for ; Tue, 2 Feb 2010 15:30:08 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C36EB3A6999 for ; Tue, 2 Feb 2010 15:30:08 -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 5F21D40332 for ; Tue, 2 Feb 2010 16:30:48 -0700 (MST) Message-ID: <4B68B5A7.4070109@stpeter.im> Date: Tue, 02 Feb 2010 16:30:47 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 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="------------ms020309060207090008010600" Subject: [OAUTH-WG] agenda for second 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: Tue, 02 Feb 2010 23:30:09 -0000 This is a cryptographically signed message in MIME format. --------------ms020309060207090008010600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alexa, the OAuth WG's second interim meeting is this Thursday, February 4, at 20:00 UTC. But it seems that I never received the invitation for forwarding to the WG. Am I missing something? Like, perhaps, my mind? :) I *am* able to view the meeting details here: https://workgreen.webex.com/workgreen/j.php?ED=3D131551047 Thanks! Peter P.S. Is there a better person to contact about these trivialities? --------------ms020309060207090008010600 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 hvcNAQkFMQ8XDTEwMDIwMjIzMzA0N1owIwYJKoZIhvcNAQkEMRYEFCboPRZ3Iq4z8Vw7jhGs cDREdYBCMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAX5X2r5x+8Uc1hgkcjHpVD9gjFWR7qUL09aD/nRQJ 8/ppZsXv/fyJI2gqM229gIcmWvmmkheZPYLoJ1rdQcCWhccs8ID31DfdSwQQfcUSERPvycLe jsP696zZSye32Su9wJZ9SRSDyFpndpXwOzCapCjQZLpFv/Zqk1MgJnNDWYpV9u10Exvd/Aso 4KfNkEdBJz01nLLbm91/BDOp+9WukdRVjx+CIh52aopz7Y9LYvaDR8x727Am4HaUCJWgXaeR dCRqlwntwKVkU8ZjKxoG4Dt9zib9kC/Euez6J45XtMTQkQ5njvfVfElzNYoZrYAbuWaeamTv oT68SAuZqqmAqwAAAAAAAA== --------------ms020309060207090008010600-- From stpeter@stpeter.im Tue Feb 2 15:30:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8573D3A6B91 for ; Tue, 2 Feb 2010 15:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.682 X-Spam-Level: X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[AWL=0.917, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwj6EnTMyv6U for ; Tue, 2 Feb 2010 15:30:42 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9DE4C3A6999 for ; Tue, 2 Feb 2010 15:30:42 -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 58AE440332 for ; Tue, 2 Feb 2010 16:31:22 -0700 (MST) Message-ID: <4B68B5C9.7030305@stpeter.im> Date: Tue, 02 Feb 2010 16:31:21 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <4B68B5A7.4070109@stpeter.im> In-Reply-To: <4B68B5A7.4070109@stpeter.im> 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="------------ms070100010705070205070005" Subject: Re: [OAUTH-WG] agenda for second 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: Tue, 02 Feb 2010 23:30:43 -0000 This is a cryptographically signed message in MIME format. --------------ms070100010705070205070005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oops, wrong addressee. :) On 2/2/10 4:30 PM, Peter Saint-Andre wrote: > Hi Alexa, the OAuth WG's second interim meeting is this Thursday, > February 4, at 20:00 UTC. But it seems that I never received the > invitation for forwarding to the WG. Am I missing something? Like, > perhaps, my mind? :) >=20 > I *am* able to view the meeting details here: >=20 > https://workgreen.webex.com/workgreen/j.php?ED=3D131551047 >=20 > Thanks! >=20 > Peter >=20 > P.S. Is there a better person to contact about these trivialities? >=20 --------------ms070100010705070205070005 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 hvcNAQkFMQ8XDTEwMDIwMjIzMzEyMVowIwYJKoZIhvcNAQkEMRYEFC1yzxYuUELCtohfafDp tND4dK82MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAlmOdJ2dEx4s7FEdzd+Okn3WQ95FjerEJ7qzjsd1/ 4SanDcdjtwsZjiOmri2KBhoFAkN0LLumN4Axi9Z1HOlIsf31o+nVxjQZrWVRBydttsVfXcWf hAEKAtp/FMsLOa8aNWUubfMIUDRpdRyQ13eTs7gFXTy2lP7EmWnsLEw2ckSGb3JJi2pBRcuy Z9B3Mx7w15Wa8qA9TIrEJCiAvocW4hgq9tplTCctxvxJrhD7tWha0gB2thfRb9EqmkJAu8tj ChAydq4dJ8mQJu6oeAAjROwi0vTOWY2BwAJBgiL7Pf1y4BJ4tNBpSErBafydXO1yrpV9IN7V NW7BSD9ypAk4rAAAAAAAAA== --------------ms070100010705070205070005-- From stpeter@stpeter.im Tue Feb 2 15:37:09 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B9528C101 for ; Tue, 2 Feb 2010 15:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.753 X-Spam-Level: X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 CUGOpqotsnOs for ; Tue, 2 Feb 2010 15:37:08 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 25DF03A68DB for ; Tue, 2 Feb 2010 15:37:08 -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 75F3240332 for ; Tue, 2 Feb 2010 16:37:47 -0700 (MST) Message-ID: <4B68B74A.8040100@stpeter.im> Date: Tue, 02 Feb 2010 16:37: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.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <4B68B5A7.4070109@stpeter.im> <4B68B5C9.7030305@stpeter.im> In-Reply-To: <4B68B5C9.7030305@stpeter.im> 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="------------ms070805080807010509010602" Subject: Re: [OAUTH-WG] agenda for second 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: Tue, 02 Feb 2010 23:37:09 -0000 This is a cryptographically signed message in MIME format. --------------ms070805080807010509010602 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/2/10 4:31 PM, Peter Saint-Andre wrote: > Oops, wrong addressee. :) However, I will send out a draft agenda tonight (yes, the chairs were supposed to do that last week). Because we never finished the agenda from the first meeting, I'd propose that we discuss the next item on that agenda, which was authentication, including Eran's I-D and related open issues. More detail tonight. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms070805080807010509010602 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 hvcNAQkFMQ8XDTEwMDIwMjIzMzc0NlowIwYJKoZIhvcNAQkEMRYEFJB8leAHH/em4uluY5Xc q8SnXFVJMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAeRwVjKDwJ9TW4+vB7PoM/CUmIQuRIPnfKm4fJ8tx 07e/W52ohemva66zsAFIFTY3tMMNtbug1eqhiFmHhIZsapju3mjNMIVvl4uZm7kSJWFmQ1Y6 On2zEZXLTR+8uDavxbiF0g2DD/FDhIc0fVquMUAf0vHe4n5NXGERNdsLxVi4Ukk517bHRLbE l3YKfPUAl8bFW1kUd/SfWOwsTjpYjbwDKxNfJPWQnrz0Ma9Ej/TEIz8lCzYGo8VIH3mHsFeW 7I0qsFt8kCkpgo13tm4GGcCWYjb2/Loi3LWFoqRr5CGkONI4aiCQwYhmYRM1pKUp59TyR7Av rdle1i5aRg+wjAAAAAAAAA== --------------ms070805080807010509010602-- From stpeter@stpeter.im Tue Feb 2 21:05:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D423A680A for ; Tue, 2 Feb 2010 21:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xn8QRt4EYvEn for ; Tue, 2 Feb 2010 21:05:30 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7EE733A69F0 for ; Tue, 2 Feb 2010 21:05:30 -0800 (PST) Received: from squire.local (dsl-251-115.dynamic-dsl.frii.net [216.17.251.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 897AC40332 for ; Tue, 2 Feb 2010 22:06:10 -0700 (MST) Message-ID: <4B690441.1020901@stpeter.im> Date: Tue, 02 Feb 2010 22:06:09 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 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="------------ms030701070702030901010802" Subject: [OAUTH-WG] logistics for second 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: Wed, 03 Feb 2010 05:05:31 -0000 This is a cryptographically signed message in MIME format. --------------ms030701070702030901010802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI. > *From: *IETF Secretariat > > *Date: *January 25, 2010 8:11:50 AM PST > *To: *amorris@amsl.com > *Subject: **(Forward to attendees): OAUTH WG Virtual Meeting* > *Reply-To: *amorris@amsl.com > > **** You can forward this email invitation to attendees **** > > Hello , > > Topic: OAUTH WG Virtual Meeting > Date: Thursday, February 4, 2010 > Time: 7:00 pm, GMT Time (London, GMT) > Meeting Number: 961 754 259 > Meeting Password: OAUTH > > > ------------------------------------------------------- > To join the online meeting (Now from iPhones too!) > ------------------------------------------------------- > 1. Go to > https://workgreen.webex.com/workgreen/j.php?ED=3D131551047&UID=3D0&PW=3D= NMmIzYmQyYTgx&RT=3DMiMyMQ%3D%3D > > > 2. Enter your name and email address. > 3. Enter the meeting password: OAUTH > 4. Click "Join Now". > 5. Follow the instructions that appear on your screen. > > To view in other time zones or languages, please click the link: > https://workgreen.webex.com/workgreen/j.php?ED=3D131551047&UID=3D0&PW=3D= NMmIzYmQyYTgx&ORT=3DMiMyMQ%3D%3D > > > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > To receive a call back, provide your phone number when you join the > meeting, or call the number below and enter the access code. > Call-in toll number (US/Canada): 1-408-792-6300 > Global call-in numbers: > https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC= &ED=3D131551047&tollFree=3D0 > > > > Access code:961 754 259 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > amorris@amsl.com > 1-510-492-4081 > > To update this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://workgreen.webex.com/workgreen/j.php?ED=3D131551047&UID=3D0&ICS=3D= UMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DUxFrI0FsRGVMzWTWPThUKCa9cjtjKH5QB8brhaSha= lk=3D&RT=3DMiMyMQ%3D%3D > > > > > WebEx will automatically setup Meeting Manager for Windows the first > time you join a meeting. To save time, you can setup prior to the > meeting by clicking this link: > https://workgreen.webex.com/workgreen/meetingcenter/mcsetup.php > > > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in > the meeting, please check whether you have the players installed on > your computer by going to > https://workgreen.webex.com/workgreen/systemdiagnosis.php > > http://www.webex.com > > > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. By joining this session, you automatically > consent to such recordings. If you do not consent to the recording, do > not join the session. --------------ms030701070702030901010802 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 hvcNAQkFMQ8XDTEwMDIwMzA1MDYwOVowIwYJKoZIhvcNAQkEMRYEFBM2d3som3rBUF5709dV 5jqEhOo0MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAekSiQWuUzBuD9sNaYeC6xvgZYWu3d9EC9Zde/xWy AEsygjFs7T9fx38E5IrAzUdyrlt37VzUDcbPbUYvuhLiDHNqXr6JLl45QrI3R0AkPPRyXO8j vMXmSb7x2BWFeSlGMmMg1CHbnyp0pVtC2ZJ7Gbu+XygU/Li8HbiNoa9KenaRn52uBfekoor1 D4w63DijMlvX1G2ZXU1IXXMhK/btPVILyg+uNLRPeSbmHbJjd6HNYnaYndqXhAdtZZLOkg60 +bxEORpuBTVMNmCcfH+7HrzfqlZeAvGCCBN1Gb7ZsYMaqoqzfnZaNP4du9I6TDGYPkrY+uCh dYxj7+hS4c/NmgAAAAAAAA== --------------ms030701070702030901010802-- From stpeter@stpeter.im Tue Feb 2 21:14:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7373A680A for ; Tue, 2 Feb 2010 21:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 GRIHfQUFjpA7 for ; Tue, 2 Feb 2010 21:14:47 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 65FD83A62C1 for ; Tue, 2 Feb 2010 21:14:47 -0800 (PST) Received: from squire.local (dsl-251-115.dynamic-dsl.frii.net [216.17.251.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DB98E40332 for ; Tue, 2 Feb 2010 22:15:26 -0700 (MST) Message-ID: <4B69066C.5050809@stpeter.im> Date: Tue, 02 Feb 2010 22:15:24 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 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="------------ms070507050203030001090108" Subject: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 05:14:48 -0000 This is a cryptographically signed message in MIME format. --------------ms070507050203030001090108 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable At the first interim meeting, we didn't get through our agenda: http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html Therefore I propose that this time we focus on some unfinished business, starting with the topic of authentication. I have reviewed all of the related threads on the list and have come up with the following *rough* agenda. Your feedback is welcome to improve this (a.k.a. "agenda bashing") either on the list or during the meeting. For logistics information, see here: http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html ****** AGENDA Base proposal: draft-ietf-oauth-authentication-01 Eran had hoped to push out a new version in time for our meeting, but hasn't been able to get to it yet. However, I think we can continue to move forward with discussion. Feedback is welcome on the general approach, as well as specific open issues. Open issues.... Issue #1: Request Signing vs. API Signing vs. Message Signing http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html 1a. Seeming consensus for message signing. 1b. No consensus yet on message format. - JSON and textual key-value seem to be the leading candidates. 1c. Seeming consensus for multiple/extensible signature algorithms. - HMAC-SHA1 - HMAC-SHA256 - RSASSA-PKCS1-v1.5-SHA256 - PLAIN over SSL/TLS But: which of these are Mandatory-to-Implement? Issue #2: Include the Normalized Request with the Request? http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html Seeming consensus to not include the normalized request (e.g., signature string). Issue #3: Allow Secrets in Cleartext, or Require Channel Encryption? http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html Seeming consensus that channel encryption is must-implement (which does not necessarily mean must-deploy). Issue #4: Authentication Challenges http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html If an authentication (access) request is unacceptable, how does the server tell the client how it can provide proper credentials (e.g., by using a different algorithm)? Possible other topics: - Mutual auth? http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html - Resource authorization? http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html ****** /psa --------------ms070507050203030001090108 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 hvcNAQkFMQ8XDTEwMDIwMzA1MTUyNFowIwYJKoZIhvcNAQkEMRYEFNGGCrXSwXyNIlUD+tI5 0ahYgnX7MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAklud4iH1NRr3BNI+nT+6eWe2Gp4jfDeEzAhcuCY9 H5Cbq4MxLk0sKunVZdCLNy7h181q+ehYQBmpS00Dv3Vbb0QtH4I7H3rbdsL+op/U2ZGCoaA3 8evx1UVwXDvDnY7cEDSVzu29gBIWz1Z9uTx/UUhTVJvGhm8/2qanDHOqdrEf6Xi3ojN4kZVS efqK1SjWjPG75Y7b1/WA5K47u3RXSpOTagwlFyJvBT+Mhzg4or4dtwGLjqPqvdckT2aLG5pX as6FjfPk0RZ8oC1iBpkjNmYmIIWuWrOVUhWke9mSyOw/UgyaQPnRdn94nvKfwv1D4lhLfxEe eBVsPmSbThy+IQAAAAAAAA== --------------ms070507050203030001090108-- From eran@hueniverse.com Tue Feb 2 23:24:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00883A67E5 for ; Tue, 2 Feb 2010 23:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 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 1Dd7AYEWXc87 for ; Tue, 2 Feb 2010 23:24:34 -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 AA89F3A6838 for ; Tue, 2 Feb 2010 23:24:34 -0800 (PST) Received: (qmail 28476 invoked from network); 3 Feb 2010 07:25:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Feb 2010 07:25:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 3 Feb 2010 00:25:08 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre , OAuth WG Date: Wed, 3 Feb 2010 00:24:46 -0700 Thread-Topic: [OAUTH-WG] proposed agenda for second interim meeting Thread-Index: Acqkj+a9lzJH3q1LRSyqGkSaQ530hQAEQ2XQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B69066C.5050809@stpeter.im> In-Reply-To: <4B69066C.5050809@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 07:24:35 -0000 UGxlYXNlIGFkZDoNCg0KLSBEaXNjdXNzIEFkb2JlJ3MgcmVjZW50IHJlcXVlc3QgdG8gYWxsb3cg ZXhjbHVkaW5nIHRoZSBob3N0L3BvcnQgZnJvbSB0aGUgc2lnbmVkIG1lc3NhZ2UuDQoNCi0gV2l0 aCByZWdhcmRzIHRvICM0LCBob3cgc2hvdWxkIHRoZSBjaGFsbGVuZ2UgaWRlbnRpZnkgdGhlIHRv a2VuIHRvIGJlIHVzZWQgKHJlYWxtIGNvbWVzIGZyZWUsIGRvIHdlIG5lZWQgYW5vdGhlcik/DQoN Ci0gU2hvdWxkIGEgc2luZ2xlIHRva2VuIHN1cHBvcnQgbXVsdGlwbGUgc2lnbmF0dXJlIGFsZ29y aXRobXM/IFRoaXMgaGFzIGltcGxpY2F0aW9ucyBhcyB0byB0aGUgaW5mb3JtYXRpb24gdGhlIGNs aWVudCBoYXMgdG8gaW5jbHVkZSB3aXRoIHRoZSByZXF1ZXN0ICh0aGUgYWxnb3JpdGhtIHVzZWQs IGV0Yy4pLg0KDQotIFdoZXJlIHNob3VsZCB0aGUgdG9rZW4gc3RydWN0dXJlIGxpdmU/IE9BdXRo IDEuMCBpbmNsdWRlcyB0d28gcmVzcG9uc2UgcGFyYW1ldGVycyAodG9rZW4gYW5kIHRva2VuX3Nl Y3JldCkuIEhvd2V2ZXIsIHNpbmNlIHdlIGFyZSBub3cgbW92aW5nIHRvd2FyZHMgaGF2aW5nIHRo ZSBhbGdvcml0aG0gcGFydCBvZiB0aGUgdG9rZW4gZGVmaW5pdGlvbiwgYXMgd2VsbCBhcyBkdXJh dGlvbiBhbmQgb3RoZXIgYXR0cmlidXRlcywgdGhlIHNlcnZlciB3aWxsIG5lZWQgdG8gcHJvdmlk ZSB0aGlzIGluZm9ybWF0aW9uIHRvIHRoZSBjbGllbnQuIFRoaXMgY2FsbHMgZm9yIGEgc2ltcGxl IHNjaGVtYSAoY2FuIGJlIGFueSBmb3JtYXQgYnV0IG5lZWQgdG8gYWdyZWUgdG8gY29uc2lzdGVu dCBuYW1lcykuIEl0IGlzIGN1cnJlbnRseSBwYXJ0IG9mIHRoZSBhdXRob3JpemF0aW9uL2RlbGVn YXRpb24gZHJhZnQgKGltcGxpY2l0bHkpLCBidXQgd2Ugc2hvdWxkIGRpc2N1c3MgbW92aW5nIGl0 IHRvIHRoZSBhdXRoZW50aWNhdGlvbiBkcmFmdCBzaW5jZSB0aGF0J3Mgd2hlcmUgaXQgaXMgdXNl ZCAodGhlIGF1dGhvcml6YXRpb24gZHJhZnQgc2ltcGx5IGhhbmRzIHRob3NlICJ0aGluZ3MiIG91 dCkuDQoNCkVITA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG9hdXRo LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYNCj4gT2YgUGV0ZXIgU2FpbnQtQW5kcmUNCj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDIs IDIwMTAgOToxNSBQTQ0KPiBUbzogT0F1dGggV0cNCj4gU3ViamVjdDogW09BVVRILVdHXSBwcm9w b3NlZCBhZ2VuZGEgZm9yIHNlY29uZCBpbnRlcmltIG1lZXRpbmcNCj4gDQo+IDxoYXQgdHlwZT0n Y2hhaXInLz4NCj4gDQo+IEF0IHRoZSBmaXJzdCBpbnRlcmltIG1lZXRpbmcsIHdlIGRpZG4ndCBn ZXQgdGhyb3VnaCBvdXIgYWdlbmRhOg0KPiANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDEwMTMuaHRtbA0KPiANCj4gVGhlcmVmb3JlIEkg cHJvcG9zZSB0aGF0IHRoaXMgdGltZSB3ZSBmb2N1cyBvbiBzb21lIHVuZmluaXNoZWQgYnVzaW5l c3MsDQo+IHN0YXJ0aW5nIHdpdGggdGhlIHRvcGljIG9mIGF1dGhlbnRpY2F0aW9uLiBJIGhhdmUg cmV2aWV3ZWQgYWxsIG9mIHRoZSByZWxhdGVkDQo+IHRocmVhZHMgb24gdGhlIGxpc3QgYW5kIGhh dmUgY29tZSB1cCB3aXRoIHRoZSBmb2xsb3dpbmcgKnJvdWdoKiBhZ2VuZGEuDQo+IFlvdXIgZmVl ZGJhY2sgaXMgd2VsY29tZSB0byBpbXByb3ZlIHRoaXMgKGEuay5hLiAiYWdlbmRhDQo+IGJhc2hp bmciKSBlaXRoZXIgb24gdGhlIGxpc3Qgb3IgZHVyaW5nIHRoZSBtZWV0aW5nLg0KPiANCj4gRm9y IGxvZ2lzdGljcyBpbmZvcm1hdGlvbiwgc2VlIGhlcmU6DQo+IA0KPiBodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwMTA4NS5odG1sDQo+IA0KPiAq KioqKioNCj4gDQo+IEFHRU5EQQ0KPiANCj4gQmFzZSBwcm9wb3NhbDogZHJhZnQtaWV0Zi1vYXV0 aC1hdXRoZW50aWNhdGlvbi0wMQ0KPiANCj4gRXJhbiBoYWQgaG9wZWQgdG8gcHVzaCBvdXQgYSBu ZXcgdmVyc2lvbiBpbiB0aW1lIGZvciBvdXIgbWVldGluZywgYnV0IGhhc24ndA0KPiBiZWVuIGFi bGUgdG8gZ2V0IHRvIGl0IHlldC4gSG93ZXZlciwgSSB0aGluayB3ZSBjYW4gY29udGludWUgdG8g bW92ZSBmb3J3YXJkDQo+IHdpdGggZGlzY3Vzc2lvbi4gRmVlZGJhY2sgaXMgd2VsY29tZSBvbiB0 aGUgZ2VuZXJhbCBhcHByb2FjaCwgYXMgd2VsbCBhcw0KPiBzcGVjaWZpYyBvcGVuIGlzc3Vlcy4N Cj4gDQo+IE9wZW4gaXNzdWVzLi4uLg0KPiANCj4gSXNzdWUgIzE6IFJlcXVlc3QgU2lnbmluZyB2 cy4gQVBJIFNpZ25pbmcgdnMuIE1lc3NhZ2UgU2lnbmluZw0KPiBodHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwMDk2MS5odG1sDQo+IA0KPiAxYS4g U2VlbWluZyBjb25zZW5zdXMgZm9yIG1lc3NhZ2Ugc2lnbmluZy4NCj4gDQo+IDFiLiBObyBjb25z ZW5zdXMgeWV0IG9uIG1lc3NhZ2UgZm9ybWF0Lg0KPiAgICAgLSBKU09OIGFuZCB0ZXh0dWFsIGtl eS12YWx1ZSBzZWVtIHRvIGJlIHRoZSBsZWFkaW5nIGNhbmRpZGF0ZXMuDQo+IA0KPiAxYy4gU2Vl bWluZyBjb25zZW5zdXMgZm9yIG11bHRpcGxlL2V4dGVuc2libGUgc2lnbmF0dXJlIGFsZ29yaXRo bXMuDQo+ICAgICAtIEhNQUMtU0hBMQ0KPiAgICAgLSBITUFDLVNIQTI1Ng0KPiAgICAgLSBSU0FT U0EtUEtDUzEtdjEuNS1TSEEyNTYNCj4gICAgIC0gUExBSU4gb3ZlciBTU0wvVExTDQo+IA0KPiBC dXQ6IHdoaWNoIG9mIHRoZXNlIGFyZSBNYW5kYXRvcnktdG8tSW1wbGVtZW50Pw0KPiANCj4gSXNz dWUgIzI6IEluY2x1ZGUgdGhlIE5vcm1hbGl6ZWQgUmVxdWVzdCB3aXRoIHRoZSBSZXF1ZXN0Pw0K PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cw MDk2Mi5odG1sDQo+IA0KPiBTZWVtaW5nIGNvbnNlbnN1cyB0byBub3QgaW5jbHVkZSB0aGUgbm9y bWFsaXplZCByZXF1ZXN0IChlLmcuLCBzaWduYXR1cmUNCj4gc3RyaW5nKS4NCj4gDQo+IElzc3Vl ICMzOiBBbGxvdyBTZWNyZXRzIGluIENsZWFydGV4dCwgb3IgUmVxdWlyZSBDaGFubmVsIEVuY3J5 cHRpb24/DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJy ZW50L21zZzAwOTYzLmh0bWwNCj4gDQo+IFNlZW1pbmcgY29uc2Vuc3VzIHRoYXQgY2hhbm5lbCBl bmNyeXB0aW9uIGlzIG11c3QtaW1wbGVtZW50ICh3aGljaCBkb2VzDQo+IG5vdCBuZWNlc3Nhcmls eSBtZWFuIG11c3QtZGVwbG95KS4NCj4gDQo+IElzc3VlICM0OiBBdXRoZW50aWNhdGlvbiBDaGFs bGVuZ2VzDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJy ZW50L21zZzAxMDM5Lmh0bWwNCj4gDQo+IElmIGFuIGF1dGhlbnRpY2F0aW9uIChhY2Nlc3MpIHJl cXVlc3QgaXMgdW5hY2NlcHRhYmxlLCBob3cgZG9lcyB0aGUgc2VydmVyDQo+IHRlbGwgdGhlIGNs aWVudCBob3cgaXQgY2FuIHByb3ZpZGUgcHJvcGVyIGNyZWRlbnRpYWxzIChlLmcuLCBieSB1c2lu ZyBhIGRpZmZlcmVudA0KPiBhbGdvcml0aG0pPw0KPiANCj4gUG9zc2libGUgb3RoZXIgdG9waWNz Og0KPiANCj4gLSBNdXR1YWwgYXV0aD8NCj4gICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwMDkzNS5odG1sDQo+IA0KPiAtIFJlc291cmNlIGF1 dGhvcml6YXRpb24/DQo+ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29h dXRoL2N1cnJlbnQvbXNnMDEwMzMuaHRtbA0KPiANCj4gKioqKioqDQo+IA0KPiAvcHNhDQo+IA0K DQo= From recordond@gmail.com Wed Feb 3 00:29:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47CAF3A6A6C for ; Wed, 3 Feb 2010 00:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.344, 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 65JsSioVi+lZ for ; Wed, 3 Feb 2010 00:29:38 -0800 (PST) Received: from mail-iw0-f176.google.com (mail-iw0-f176.google.com [209.85.223.176]) by core3.amsl.com (Postfix) with ESMTP id 614A33A69FA for ; Wed, 3 Feb 2010 00:29:38 -0800 (PST) Received: by iwn6 with SMTP id 6so1135529iwn.15 for ; Wed, 03 Feb 2010 00:30:14 -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=EdtXST1l927t0jzJRHDcWIpArjrLTRJV/x4YLPzOWvM=; b=VqH+qtZQhiq4xJ4Vx2FIqVZD+XiG+4NjR1IV1xcbpmmxm0fPRjoLu1MM+Z2gCVpMxl 4rSVlTRMqAo76vABRDRqBXVk2Z1cwBujDYxSrEdDiazpkvUgEvXVtFC78PTZ2Ww0U+yY MYBuHOAQI1GB6bTI9cVlVFQjiIKJo1czQVZBM= 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=Axx5oxrvRIpKD/SAsPXUbMyCvv6chzQvLZKWISkrvd6twzjh4ozHIsVi06+Ouq+Ea7 Xfz/kqrutulovlOEEmzx4CnMeaJiuiTMwLdn7l7Bt2z1ippYTt7gQhIVwjy3VXtOP8NQ 1ZNx/xCDgAG7jrWHedHovQafTjdXL+fz5/Y4k= MIME-Version: 1.0 Received: by 10.231.151.197 with SMTP id d5mr6057720ibw.73.1265185813884; Wed, 03 Feb 2010 00:30:13 -0800 (PST) In-Reply-To: <4B68A258.3070908@stpeter.im> References: <4B61AFF0.6060302@stpeter.im> <4B68A258.3070908@stpeter.im> Date: Wed, 3 Feb 2010 00:30:13 -0800 Message-ID: From: David Recordon To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=0016e68ea020032193047eae07de 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: Wed, 03 Feb 2010 08:29:39 -0000 --0016e68ea020032193047eae07de Content-Type: text/plain; charset=ISO-8859-1 Looks like http://spreadsheets.google.com/ccc?key=0AjpBrc9X0st3dFBNQUpnZzFJbmFGOTkxZUVNdGdxMmc&hl=enis actually public. On Tue, Feb 2, 2010 at 2:08 PM, Peter Saint-Andre wrote: > On 1/28/10 11:35 PM, David Recordon wrote: > > Hey Peter, > > Luke put together a spreadsheet comparing the terminology across five or > > six different protocols. Hopefully he'll share it. :) > > That would be great. I'll ping him off-list, or he can just attach it to > http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthTerms by first > provisioning an account at http://tools.ietf.org/newlogin :) > > > I have a pretty strong preference of sticking with OAuth 1.0 terminology > > as much as possible. > > Agreed. > > --0016e68ea020032193047eae07de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Looks like=A0http://spreadsheets.google.= com/ccc?key=3D0AjpBrc9X0st3dFBNQUpnZzFJbmFGOTkxZUVNdGdxMmc&hl=3Den = is actually public.

On Tue, Feb 2, 2010 at 2:08 PM, Peter Saint-= Andre <stpeter@s= tpeter.im> wrote:
On 1/28/10 11:35 PM, David Recordon wrote:
> Hey Peter,
> Luke put together a spreadsheet comparing the terminology across five = or
> six different protocols. =A0Hopefully he'll share it. :)

That would be great. I'll ping him off-list, or he can just attac= h it to
http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthTerms by= first
provisioning an account at http://tools.ietf.org/newlogin :)

> I have a pretty strong preference of sticking with OAuth 1.0 terminolo= gy
> as much as possible.

Agreed.


--0016e68ea020032193047eae07de-- From stpeter@stpeter.im Wed Feb 3 05:02: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 99A9E3A6884 for ; Wed, 3 Feb 2010 05:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 AojlGBl4EfzN for ; Wed, 3 Feb 2010 05:01:59 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A33F83A68F6 for ; Wed, 3 Feb 2010 05:01:59 -0800 (PST) Received: from squire.local (dsl-251-115.dynamic-dsl.frii.net [216.17.251.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C167A40332; Wed, 3 Feb 2010 06:02:40 -0700 (MST) Message-ID: <4B6973EF.20507@stpeter.im> Date: Wed, 03 Feb 2010 06:02:39 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: David Recordon References: <4B61AFF0.6060302@stpeter.im> <4B68A258.3070908@stpeter.im> 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="------------ms080501020901050107010200" 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: Wed, 03 Feb 2010 13:02:00 -0000 This is a cryptographically signed message in MIME format. --------------ms080501020901050107010200 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, that is quite helpful. Thanks! On 2/3/10 1:30 AM, David Recordon wrote: > Looks > like http://spreadsheets.google.com/ccc?key=3D0AjpBrc9X0st3dFBNQUpnZzFJ= bmFGOTkxZUVNdGdxMmc&hl=3Den > > is actually public. >=20 > On Tue, Feb 2, 2010 at 2:08 PM, Peter Saint-Andre > wrote: >=20 > On 1/28/10 11:35 PM, David Recordon wrote: > > Hey Peter, > > Luke put together a spreadsheet comparing the terminology across > five or > > six different protocols. Hopefully he'll share it. :) >=20 > That would be great. I'll ping him off-list, or he can just attach = it to > http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthTerms by first > provisioning an account at http://tools.ietf.org/newlogin :) >=20 > > I have a pretty strong preference of sticking with OAuth 1.0 > terminology > > as much as possible. >=20 > Agreed. >=20 --------------ms080501020901050107010200 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 hvcNAQkFMQ8XDTEwMDIwMzEzMDIzOVowIwYJKoZIhvcNAQkEMRYEFPcTaKT9qOXlPsUGgF0O qew1Pcc+MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAIxIG1Ym2dkXMeWulgT7nerP3VUdDEd6MqJeYeOjI vYpp98shnrIClw2NzNc6AjKDQsvHD9haIAdpG0PnVSiF3dyPfW8ya/FA2nbOQCBu2sfpMjmF XAaCE3eLqDDadJdq6XATp0mCElaPyo29iDfR4akS3huISeWy6KYYLG/6qR9d3/3SzRcfqFM3 DX8QkXYftLGPcSGQTxo1VkcCrGCNevVOgJytT7Z+nijnBE3cAkrQYeqcvURX2EHcnS6mPxK9 MVAqj1Uh/E77nm7oRoo2JxVrn9Aq9oNd6e5oLK/CObDeG8NYGcemsAc1GL887o0KdPZKVhwu EMTI9bYBdQC9XwAAAAAAAA== --------------ms080501020901050107010200-- From James.H.Manger@team.telstra.com Wed Feb 3 05:13:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA5328C16D for ; Wed, 3 Feb 2010 05:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUuj4uplqDdl for ; Wed, 3 Feb 2010 05:13:33 -0800 (PST) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id A09C13A683A for ; Wed, 3 Feb 2010 05:13:32 -0800 (PST) Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipbi.ntcif.telstra.com.au with ESMTP; 04 Feb 2010 00:14:11 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 74A4BFF82 for ; Thu, 4 Feb 2010 00:14:11 +1100 (EST) Received: from wsmsg3707.srv.dir.telstra.com (wsmsg3707.srv.dir.telstra.com [172.49.40.81]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id A554541D32 for ; Thu, 4 Feb 2010 00:13:41 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Wed, 3 Feb 2010 23:14:10 +1000 From: "Manger, James H" To: "OAuth WG (oauth@ietf.org)" Date: Wed, 3 Feb 2010 23:14:09 +1000 Thread-Topic: Token Access Authentication Scheme Draft Thread-Index: Acp3Fy41mhoVRFEVTsOZ4fl/+l3K7wAKRu2w Message-ID: <255B9BB34FB7D647A506DC292726F6E112503E4234@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 13:13:39 -0000 SGVsbG8gT0F1dGhlcnMsDQoNCkkgaGF2ZSBhIGNvdXBsZSBvZiBjb21tZW50cyBvbiB0aGUgIlRv a2VuIEFjY2VzcyBBdXRoIiBkcmFmdC4NCg0KSW5pdGlhbCBpbXByZXNzaW9uIChhcyBFcmFuIGFz a2VkIGZvcik6IFl1Y2suDQpOb3cgSSB3aWxsIHRyeSB0byBiZSBhIGJpdCBtb3JlIGNvbnN0cnVj dGl2ZS4NCg0KVGhpcyBhdXRoZW50aWNhdGlvbiBkcmFmdCBicmVha3MgdGhlIGV4aXN0aW5nIG1v ZGVsIG9mIEhUVFAgYXV0aGVudGljYXRpb24gdG9vIG11Y2guIEl0IHB1dHMgYSBidW5jaCBvZiB2 ZXJ5IGRpZmZlcmVudCBtZWNoYW5pc21zIChiZWFyZXIsIHNoYXJlZCBzZWNyZXQsIGFuZCBwdWJs aWMga2V5IGNyeXB0bykgaW50byBhIHNpbmdsZSAiVG9rZW4iIHNjaGVtZS4gV2Ugc2hvdWxkLCBp bnN0ZWFkLCBoYXZlIDEgc2NoZW1lIHBlciBtZWNoYW5pc20sIHdoaWNoIGlzIGhvdyBIVFRQIGF1 dGggaGFzIGJlZW4gZGVzaWduZWQuDQpJIGFncmVlIHdpdGggRGFuIFdpbnNoaXAgW2VtYWlsIDIw MDktMTItMDldIHRoYXQgYSBtZXRhLXNjaGVtZSAoIlRva2VuIikgd2l0aCBtdWx0aXBsZSBzdWIt c2NoZW1lcyB3aWxsIG5vdCB3b3JrIHdlbGwgd2l0aCBleGlzdGluZyBjb2RlIGFyY2hpdGVjdHVy ZXMsIHdoaWNoIG9mZmVyIGV4dGVuc2liaWxpdHkgYmFzZWQgb24gc2NoZW1lcywgbm90IGJhc2Vk IG9uIGFueSBvdGhlciBwYXJ0cyBvZiBhIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVyLg0KDQoNCkl0 IGxvb2tzIGxpa2UgJ3JlYWxtJyBoYXMgYmVlbiByZXBsYWNlZCBieSAnY2xhc3MnLiBUaGlzIGlz IHdvcmtpbmcgYWdhaW5zdCB0aGUgZXhpc3RpbmcgbW9kZWwgZm9yIEhUVFAgYXV0aCwgd2l0aG91 dCBhIGNvbXBlbGxpbmcgcmVhc29uLg0KDQoNCkEgbWFqb3IgcmF0aW9uYWwgZm9yIHNlcGFyYXRp bmcgT0F1dGggaW50byBEZWxlZ2F0aW9uIGFuZCBBdXRoZW50aWNhdGlvbiBkb2N1bWVudHMgd2Fz IHRvIHJlY29nbml6ZSB0aGF0IHRoZXkgYXJlIGxvZ2ljYWxseSBpbmRlcGVuZGVudC4gQXV0aGVu dGljYXRpb24gbmVlZHMgYW4gaWQgKGVnIGEgdG9rZW4gb3IgdXNlci1pZCkgYW5kLCBvcHRpb25h bGx5LCBhIGtleSAtLSBidXQgaGFzIG5vIGRlcGVuZGVuY2Ugb24gZGVsZWdhdGlvbi4gSWRlYWxs eSwgYXV0aGVudGljYXRpb24gc3BlY3Mgd291bGQgbm90IG1lbnRpb24gKE9BdXRoLXN0eWxlKSBk ZWxlZ2F0aW9uIGF0IGFsbC4NClRoZSBhdXRoZW50aWNhdGlvbiBkcmFmdCBpcyB0b28gc3Ryb25n bHkgYm91bmQgdG8gZGVsZWdhdGlvbiBieSB0cnlpbmcgdG8gcGFja2FnZSBhbGwgYXV0aGVudGlj YXRpb24gbWVjaGFuaXNtcyB0aGF0IGNhbiBiZSB1c2VkIHdpdGggZGVsZWdhdGlvbiB1bmRlciBh IHNpbmdsZSBzY2hlbWUuIFRoaXMgY2Fubm90IHdvcmsuDQpUaGVyZSB3aWxsIGJlIG90aGVyIHNj aGVtZXM6IGF0IGxvd2VyIGxheWVycywgc2lnbmF0dXJlIGluIHRoZSBVUkksIHNpZ25pbmcgZXhj bHVkaW5nIHRoZSBob3N0IG5hbWUsIHVzaW5nIHBhc3N3b3JkLWJhc2VkIGtleSBhZ3JlZW1lbnQs IHVzaW5nIG11bHRpcGxlIHJvdW5kLXRyaXBzLCBub24taHR0cCBwcm90b2NvbHMgZXRjLg0KDQoN CkkgYW0gbm90IGFnYWluc3QgZGV2ZWxvcGluZyBhIG1lY2hhbmlzbSB0byBzaWduIEhUVFAgcmVx dWVzdHMgd2l0aCBhIHNoYXJlZCBzZWNyZXQuIEkgdGhpbmsgaXQgaXMgZmFyIGxlc3MgaW1wb3J0 YW50IGZvciB0aGUgT0F1dGggd29ya2luZyBncm91cCB0aGFuIHNwZWNpZnlpbmcgdGhlIGRlbGVn YXRpb24gZmxvd3MsIGFuZCBzaWduYWxsaW5nLg0KDQoNCk15IHN1Z2dlc3Rpb25zOg0KDQoxLiBE ZWZpbmUgMSB2ZXJ5IHNpbXBsZSBiZWFyZXIgc2NoZW1lIC0tIHdpdGggbm8gbWVudGlvbiBvZiBk ZWxlZ2F0aW9uLiBEb24ndCBpbmNsdWRlIHJlcXVlc3Qgc2lnbmluZyBpbiB0aGUgc2FtZSBkb2N1 bWVudC4NCiAgRWcgIEF1dGhvcml6YXRpb246IElEIGE9PGF1dGhvcml6YXRpb24taWQ+DQogICh1 c2UgIldSQVAiIGFuZCAid3JhcF9hY2Nlc3NfdG9rZW4iIGFzIGxhYmVscyBpZiB5b3UgbXVzdCkN Cg0KMi4gT3B0aW9uYWxseSwgd29yayBvbiBhIG1lY2hhbmlzbSB0byBzaWduIGFuIEhUVFAgcmVx dWVzdCB3aXRoIGEgc2hhcmVkIHNlY3JldCB3aXRob3V0IG5lZWRpbmcgdG8gZXhjaGFuZ2UgbXVs dGlwbGUgbWVzc2FnZXMgd2l0aCB0aGUgc2VydmVyLiBFbnN1cmUgdGhlIG1lY2hhbmlzbSBjYW4g aW5jbHVkZSAyIGlkcyAoYXV0aGVudGljYXRpb24gaWQgYW5kIGF1dGhvcml6YXRpb24gaWQpLCBh bmQgYSBjaGFubmVsIGJpbmRpbmcgcGFyYW1ldGVyLg0KDQpQbHVzIHRoZSBtYWluIHBhcnQgb2Yg dGhlIFdHIHdvcms6IG9uIGRlbGVnYXRpb24gZmxvd3M7IHNlcnZlci10by1jbGllbnQgc2lnbmFs bGluZyBhYm91dCBob3cgdG8gZG8gZGVsZWdhdGlvbiAoZWcgcHJvdmlkaW5nIFVSSSB0byByZWRp cmVjdCB1c2VyIHRvKTsgc3RhdGluZyB3aGljaCBob3N0cyBhbmQvb3IgVVJJcyBhIHRva2VuIChh bmQgb3B0aW9uYWwgc2VjcmV0KSBjYW4gYmUgdXNlZCBhdDsgd29ya2luZyBvdXQgaG93IHBlcmlv ZGljYWxseSByZWZyZXNoaW5nIGNyZWRlbnRpYWxzIGZpdHMgYXJjaGl0ZWN0dXJhbGx5Lg0KDQoN Ci0tIA0KSmFtZXMgTWFuZ2VyDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmDQo+IE9mIEVyYW4gSGFtbWVyLUxhaGF2DQo+IFNlbnQ6IE1vbmRheSwgNyBE ZWNlbWJlciAyMDA5IDc6MjggUE0NCj4gVG86IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNCj4g U3ViamVjdDogW09BVVRILVdHXSBUb2tlbiBBY2Nlc3MgQXV0aGVudGljYXRpb24gU2NoZW1lIERy YWZ0DQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWhhbW1lci1odHRwLXRva2Vu LWF1dGgtMDAudHh0DQo+IA0KPiBUaGlzIGRyYWZ0IGlzIG15IGZpcnN0IGF0dGVtcHQgYXQgZGVm aW5pbmcgYSBnZW5lcmFsIHB1cnBvc2UNCj4gYXV0aGVudGljYXRpb24gc2NoZW1lIHRvIGZ1bGZp bGwgdGhlIFdHIHJlcXVpcmVtZW50IHRvIHByb2R1Y2UgYSBzY2hlbWUNCj4gc3VpdGFibGUgZm9y IDItbGVnZ2VkIGF1dGhlbnRpY2F0aW9uLiBJdCBhbHNvIHN1cHBvcnRzIHRoZSBPQXV0aCAzLQ0K PiBsZWdnZWQgdXNlIGNhc2VzIGFzIGRpc2N1c3NlZCBvbiB0aGUgbGlzdC4gVGhpcyBkcmFmdCBp cyBpbiB2ZXJ5IGVhcmx5DQo+IHN0YWdlIGFuZCBoYXMgYmVlbiBzdWJtaXR0ZWQgZWFybHkgdG8g aGVscCBiZXR0ZXIgZmFjaWxpdGF0ZSB0aGUNCj4gY29udmVyc2F0aW9uLg0KPiANCj4gSXQgaGFz IGJlZW4gaGFyZCBmb3IgdXMgdG8gZGlzY3VzcyBpZGVhcyB3aXRob3V0IGEgY29uY3JldGUgcHJv cG9zYWwuIEkNCj4gaG9wZSB0aGlzIHdpbGwgaGVscCBhbmQgbW90aXZhdGUgcGVvcGxlIHRvIHBh cnRpY2lwYXRlIGFuZCBwcm92aWRlDQo+IGZlZWRiYWNrIGFuZCBuZXcgaWRlYXMuIFdoaWxlIHRo ZXJlIGFyZSBtYW55IGhvbGVzIGluIHRoZSBkcmFmdCwgaXQNCj4gc2hvdWxkIGJlIHByZXR0eSBl YXN5IHRvIGZvbGxvdyBpdC4NCj4gDQo+IE1ham9yIGNoYW5nZXMgZnJvbSBPQXV0aCAxLjA6DQo+ IA0KPiAqIE5ldyBhdXRoIHNjaGVtZSB3aXRoIG5ldyBwYXJhbWV0ZXIgbmFtZXMNCj4gKiBTaWdu YXR1cmUgYmFzZSBzdHJpbmcgcmVwbGFjZWQgd2l0aCBub3JtYWxpemVkIHJlcXVlc3Qgc3RyaW5n LCBhbmQNCj4gbm93IGRvZXMgbm90IHJlcXVpcmUgKmFueSogZW5jb2RpbmcNCj4gKiBTdXBwb3J0 cyBtdWx0aXBsZSB0b2tlbiBjbGFzc2VzLCBhdXRoZW50aWNhdGlvbiBtZXRob2RzLCBhbmQgY292 ZXJhZ2UNCj4gc2NvcGUNCj4gDQo+IE1haW4gZmVlZGJhY2sgcmVxdWVzdGVkOg0KPiANCj4gKiBJ bml0aWFsIGltcHJlc3Npb25zIC0gdGhpcyBpcyBwYXJ0aWN1bGFybHkgaW1wb3J0YW50IHRvIGdl dC4gRG9lcyB0aGUNCj4gZHJhZnQgbWFrZSBzZW5zZT8NCj4gKiBGdW5jdGlvbmFsaXR5IC0gZG9l cyBpdCBpbmNsdWRlIGFsbCB0aGUgcmVxdWVzdGVkL3JlcXVpcmVkDQo+IGZ1bmN0aW9uYWxpdHk/ DQo+ICogQWJzdHJhY3Rpb24gbGV2ZWwgLSBkbyB0aGUgYXR0cmlidXRlcyBwcm92aWRlIHRoZSBy aWdodCBsZXZlbCBvZg0KPiBjb25maWd1cmF0aW9uIGFuZCBjaG9pY2U/DQo+IA0KPiBQbGVhc2Ug cmVmcmFpbiBmcm9tIGVkaXRvcmlhbCBmZWVkYmFjayBhdCB0aGlzIHBvaW50IChncmFtbWFyLCB0 eXBvcywNCj4gZXRjLiksIGJ1dCBkbyBwcm92aWRlIHN0cnVjdHVyYWwgZmVlZGJhY2suDQo+IA0K PiBJIHBsYW4gdG8gcHVzaCBhbiB1cGRhdGVkIHZlcnNpb24gYnkgV2VkIHdoaWNoIHdpbGwgaW5j b3Jwb3JhdGUgYXMgbXVjaA0KPiBmZWVkYmFjayBhcyBJIGNhbi4gSSBwbGFuIHRvIGFzayBmb3Ig dGhlIFdHIHRvIHByb21vdGUgdGhpcyBkcmFmdCB0byBhDQo+IFdHIGl0ZW0gd2l0aGluIDIgd2Vl a3MuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiBFSEwNCg0K From James.H.Manger@team.telstra.com Wed Feb 3 05:38: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 2C2E83A6858 for ; Wed, 3 Feb 2010 05:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_53=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 HFD9SMRrMNyh for ; Wed, 3 Feb 2010 05:38:14 -0800 (PST) Received: from mailipao.vtcif.telstra.com.au (mailipao.vtcif.telstra.com.au [202.12.144.27]) by core3.amsl.com (Postfix) with ESMTP id 006BF3A683A for ; Wed, 3 Feb 2010 05:38:13 -0800 (PST) Received: from maili.vtcif.telstra.com.au (HELO mailai.vtcif.telstra.com.au) ([202.12.142.17]) by mailipai.vtcif.telstra.com.au with ESMTP; 04 Feb 2010 00:37:53 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id 7C17E1DA81; Thu, 4 Feb 2010 00:37:53 +1100 (EST) Received: from WSMSG3753.srv.dir.telstra.com (wsmsg3753.srv.dir.telstra.com [172.49.40.174]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id AAA06637; Thu, 4 Feb 2010 00:37:53 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Thu, 4 Feb 2010 00:37:52 +1100 From: "Manger, James H" To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Thu, 4 Feb 2010 00:37:51 +1100 Thread-Topic: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge? Thread-Index: Acqfx6ayNhU2VNG/Qvi8Kw+JpK0C4gFDD9bg Message-ID: <255B9BB34FB7D647A506DC292726F6E112503E4238@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723437899D22BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437899D22BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge? X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Feb 2010 13:38:15 -0000 QW4gYXV0aGVudGljYXRpb24gY2hhbGxlbmdlIChXV1ctQXV0aGVudGljYXRlIGhlYWRlcikgZGVm aW5lZCBpbiBhIHNwZWMgZm9yIGFuIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBzaG91bGQgYmUg cHJlc2VudCwgYnV0IG9ubHkgd2l0aCBkZXRhaWxzIHNwZWNpZmljIHRvIHRoYXQgbWVjaGFuaXNt IChlZyBsaXN0IG9mIE1BQyBhbGdvcml0aG1zKS4NCg0KSSB0aGluayB0aGVyZSBzaG91bGQgYmUg YSB0b3RhbGx5IHNlcGFyYXRlIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVyIHNwZWNpZmljYWxseSBz YXlpbmcgImEgZGVsZWdhdGlvbiBmbG93IGNhbiBiZSB1c2VkIHRvIGFjY2VzcyB0aGlzIHJlc291 cmNlIi4gSXQgc2hvdWxkIGluY2x1ZGUgZGV0YWlscyBzdWNoIGFzIHRoZSBVUkkgdG8gcmVkaXJl Y3QgdGhlIHVzZXIgdG8uDQoNCldlIHJlYWxseSBuZWVkIHRoaXMgaWYgd2Ugd2FudCB0byBvZmZl ciBhIHdlYi1zdHlsZSBwcm90b2NvbCB3aXRoIGFueSBzZW1ibGFuY2Ugb2YgaW50ZXJvcGVyYWJp bGl0eS4gSWYgd2Ugb21pdCBpdCBiZWNhdXNlICJjbGllbnRzIG5lZWQgdG8ga25vdyBsb3RzIG9m IG90aGVyIEFQSS1zcGVjaWZpYyBkZXRhaWxzIGFueXdheSIgdGhlbiB3ZSB3b250IGhhdmUgYSBw YXRoIHRvIGdldCBwYXN0IHRoYXQgbGltaXRhdGlvbiBpbiBmdXR1cmUuDQoNCg0KLS0gDQpKYW1l cyBNYW5nZXINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvYXV0aC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm DQo+IE9mIEVyYW4gSGFtbWVyLUxhaGF2DQo+IFNlbnQ6IFRodXJzZGF5LCAyOCBKYW51YXJ5IDIw MTAgMjoxMiBQTQ0KPiBUbzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KPiBTdWJqZWN0OiBb T0FVVEgtV0ddIFdoYXQgYXJlIHRoZSBwcmltYXJ5IGNyaXRlcmlhIGluIGlzc3VpbmcgYW4NCj4g YXV0aGVudGljYXRpb24gY2hhbGxlbmdlPw0KPiANCj4gQW4gYXV0aGVudGljYXRpb24gY2hhbGxl bmdlICh0byBtYWtlIHN1cmUgd2UgYXJlIGFsbCBvbiB0aGUgc2FtZSBwYWdlKQ0KPiBpcyBzb21l dGhpbmcgdGhlIHNlcnZlciBzZW5kcyB0byB0aGUgY2xpZW50IHdoZW4gZGVueWluZyBhY2Nlc3Mg dG8gYQ0KPiBwcm90ZWN0ZWQgcmVzb3VyY2UuIFRoZSBjaGFsbGVuZ2UgY2FuIGJlIGFzIHNpbXBs ZSBhcyAidXNlIEJhc2ljIiwgb3INCj4gY29tcGxleCBhcyAidXNlIERpZ2VzdCB3aXRoIHRoZSBm b2xsb3dpbmcgcGFyYW1ldGVycyIuIE9BdXRoIDEuMA0KPiBkb2Vzbid0IHJlYWxseSB1c2UgYSBj aGFsbGVuZ2UgYmVjYXVzZSBpdCB3YXMgY3JlYXRlZCBmb3IgY2FzZXMgd2hlcmUNCj4gdGhlIEFQ SSBjYWxscyBhcmUgcHJlY29uZmlndXJlZCBhbmQgaGFyZGNvZGVkIGludG8gdGhlIGNsaWVudC4g VGhlDQo+IGNsaWVudCBzaG91bGQgbmV2ZXIgcmVjZWl2ZSBhbiBPQXV0aCBjaGFsbGVuZ2UgdGhl IHdheSB0aGUgcHJvdG9jb2wgd2FzDQo+IG9yaWdpbmFsbHkgZGVzaWduZWQuDQo+IA0KPiBJbiBt eSB0b2tlbiBhdXRoZW50aWNhdGlvbiBkcmFmdCBJIHRyaWVkIHRvIHByb3Bvc2UgbXVsdGlwbGUg bWVjaGFuaXNtcw0KPiAobm90IGZ1bGx5IGJha2VkIHlldCkgZm9yIGlzc3VpbmcgYSBjaGFsbGVu Z2UgYW5kIGFsbG93aW5nIHRoZSBjbGllbnQNCj4gdG8gZmlndXJlIG91dCB3aGF0IHRvIGRvIG5l eHQuIEJlZm9yZSBwcm9kdWNpbmcgYW5vdGhlciBkcmFmdCwgaXQgaXMNCj4gaW1wb3J0YW50IHRv IGZpZ3VyZSBvdXQgd2hhdCBjaGFsbGVuZ2UgbW9kZWwgd2Ugd2FudCB0byB1c2UuIEhlcmUgYXJl DQo+IHRoZSBnZW5lcmFsIG9wdGlvbnMgSSBjYW1lIHVwIHdpdGg6DQo+IA0KPiAxLiBCYXNpYyAv IE9BdXRoIDEuMCBzdHlsZSAtIFNpbXBseSBzYXkgInVzZSBUb2tlbiIuIFRoZSBjbGllbnQgaXMg bGVmdA0KPiBvbiBpdHMgb3duIHRvIGZpZ3VyZSBvdXQgd2hhdCB0byBkbyBuZXh0Lg0KPiANCj4g Mi4gQmFzaWMgLyBPQXV0aCAxLjAgKyBzaW1wbGUgZGlzY292ZXJ5IC0gU2F5ICJ1c2UgVG9rZW4g YW5kIGlmIHlvdQ0KPiBuZWVkIGEgbmV3IHRva2VuIGdvIHRoZXJlIi4gSXQgaXMgc3RpbGwgbm90 IGNsZWFyIGhvdyB0aGlzIHdpbGwgaGVscA0KPiB0aGUgY2xpZW50IGdpdmVuIHRoYXQgZ2V0dGlu ZyBhIHRva2VuIGlzIGxpa2VseSBpdCBpbmNsdWRlIG1hbnkNCj4gZGlmZmVyZW50IG9wdGlvbnMs IGFuZCB0byBmdWxseSBhZGRyZXNzIHRoaXMgd2UgbmVlZCB0byBkaWcgZGVlcCBpbnRvDQo+IGRp c2NvdmVyeSB3aGljaCB3YXMgbGVmdCBvdXQgb2Ygc2NvcGUuDQo+IA0KPiAzLiBUb2tlbiBhdHRy aWJ1dGVzIC0gdGhlIHNlcnZlciBpbmZvcm1zIHRoZSBjbGllbnQgb2YgdGhlIGtpbmQgb2YNCj4g dG9rZW5zIGFjY2VwdGVkIChiYXNlZCBvbiB0aGVpciBjcnlwdG9ncmFwaGljIHByb3BlcnRpZXMg b3IgdGhlDQo+IHJlc291cmNlLXNldC9yZWFsbSB0aGV5IGFyZSBnb29kIGZvcikuIFRoaXMgaXMg anVzdCBsaWtlICMyIGJ1dCB3aXRoDQo+IHRoZSBhYmlsaXR5IGZvciB0aGUgc2VydmVyIHRvIHN1 cHBvcnQgbW9yZSB0aGFuIG9uZSB0b2tlbiB0eXBlIHBlcg0KPiByZXNvdXJjZS4NCj4gDQo+IFF1 ZXN0aW9uOiBJcyB0aGUgYWJpbGl0eSBmb3IgYSBzaW5nbGUgdG9rZW4tcHJvdGVjdGVkIHJlc291 cmNlIHRvDQo+IHN1cHBvcnQgbW9yZSB0aGFuIG9uZSB0b2tlbiB0eXBlIChzYXkgUGxhaW4rU1NM ICphbmQqIEhNQUMtMjU2KSBwYXJ0IG9mDQo+IG91ciByZXF1aXJlbWVudHM/IElmIG5vdCwgdGhl cmUgaXMgbm8gcmVhc29uIGF0IGFsbCBmb3IgdGhlIGNoYWxsZW5nZQ0KPiB0byBpbmNsdWRlIGFu eXRoaW5nIG90aGVyIHRoYW4gIzEgb3IgIzIgKHByb2JhYmx5IGRlZmluZWQgYXMgYSBmdXR1cmUN Cj4gZXh0ZW5zaW9uKS4NCj4gDQo+IEVITA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== From dick.hardt@gmail.com Wed Feb 3 07:01: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 60C663A6AFD for ; Wed, 3 Feb 2010 07:01:15 -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 AZK-yjKYgSEX for ; Wed, 3 Feb 2010 07:01:14 -0800 (PST) Received: from mail-pz0-f179.google.com (mail-pz0-f179.google.com [209.85.222.179]) by core3.amsl.com (Postfix) with ESMTP id 74BC73A6A15 for ; Wed, 3 Feb 2010 07:01:10 -0800 (PST) Received: by pzk9 with SMTP id 9so1636668pzk.31 for ; Wed, 03 Feb 2010 07:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=KQZ8j2moL6V6eLHfgyyRmY8ziNuFH8uYUl9duEEOYoE=; b=YSjO38a6hNgqbTM/lzfhQEMVGIZU1VoGgbIbNnp7s2MQPwAq6Xm63C2HaoqrsDEGtP ZhUobrT75E55ZWF4nu0TpaZG5mbbN4tb9IYQ4Ec6ZOqgqFUXBmC8bwe+q3FI0B5DsAmw SlcsiI2TLWBgNgxyK1F/FsQAcPibAlI9wD2mA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ru+tGDg2Vg6R3w+NiX5H7UaTQPoBcleMBIJODPsZbUPUpcsbSt2Je8J8AnfvejNECR 8P0IFFwwN6xvmgSs74u+GQKvbU1RBXOt+TRyVL6Ap7BOPxKMH4XwtGeapgwwQTNkdk0x dDR9uBE+8A9bDSCfWoGmENcAnB7aacjkqBgpI= Received: by 10.141.14.15 with SMTP id r15mr5284036rvi.29.1265209310422; Wed, 03 Feb 2010 07:01:50 -0800 (PST) Received: from ?192.168.1.236? (c-24-17-212-68.hsd1.wa.comcast.net [24.17.212.68]) by mx.google.com with ESMTPS id 23sm6495522pzk.8.2010.02.03.07.01.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 07:01:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 3 Feb 2010 07:01:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 15:01:15 -0000 Hi Eran I think it is a little early in our phone discussions to get into = technical details. The next step according to the last call was to = gather and review use cases. Without rough consensus on what problem we = are solving, your points below (which all do need to be discussed at = some point) is just moving around deck chairs on the Titanic. -- Dick On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: > Please add: >=20 > - Discuss Adobe's recent request to allow excluding the host/port from = the signed message. >=20 > - With regards to #4, how should the challenge identify the token to = be used (realm comes free, do we need another)? >=20 > - Should a single token support multiple signature algorithms? This = has implications as to the information the client has to include with = the request (the algorithm used, etc.). >=20 > - Where should the token structure live? OAuth 1.0 includes two = response parameters (token and token_secret). However, since we are now = moving towards having the algorithm part of the token definition, as = well as duration and other attributes, the server will need to provide = this information to the client. This calls for a simple schema (can be = any format but need to agree to consistent names). It is currently part = of the authorization/delegation draft (implicitly), but we should = discuss moving it to the authentication draft since that's where it is = used (the authorization draft simply hands those "things" out). >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Peter Saint-Andre >> Sent: Tuesday, February 02, 2010 9:15 PM >> To: OAuth WG >> Subject: [OAUTH-WG] proposed agenda for second interim meeting >>=20 >> >>=20 >> At the first interim meeting, we didn't get through our agenda: >>=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html >>=20 >> Therefore I propose that this time we focus on some unfinished = business, >> starting with the topic of authentication. I have reviewed all of the = related >> threads on the list and have come up with the following *rough* = agenda. >> Your feedback is welcome to improve this (a.k.a. "agenda >> bashing") either on the list or during the meeting. >>=20 >> For logistics information, see here: >>=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html >>=20 >> ****** >>=20 >> AGENDA >>=20 >> Base proposal: draft-ietf-oauth-authentication-01 >>=20 >> Eran had hoped to push out a new version in time for our meeting, but = hasn't >> been able to get to it yet. However, I think we can continue to move = forward >> with discussion. Feedback is welcome on the general approach, as well = as >> specific open issues. >>=20 >> Open issues.... >>=20 >> Issue #1: Request Signing vs. API Signing vs. Message Signing >> http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html >>=20 >> 1a. Seeming consensus for message signing. >>=20 >> 1b. No consensus yet on message format. >> - JSON and textual key-value seem to be the leading candidates. >>=20 >> 1c. Seeming consensus for multiple/extensible signature algorithms. >> - HMAC-SHA1 >> - HMAC-SHA256 >> - RSASSA-PKCS1-v1.5-SHA256 >> - PLAIN over SSL/TLS >>=20 >> But: which of these are Mandatory-to-Implement? >>=20 >> Issue #2: Include the Normalized Request with the Request? >> http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html >>=20 >> Seeming consensus to not include the normalized request (e.g., = signature >> string). >>=20 >> Issue #3: Allow Secrets in Cleartext, or Require Channel Encryption? >> http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html >>=20 >> Seeming consensus that channel encryption is must-implement (which = does >> not necessarily mean must-deploy). >>=20 >> Issue #4: Authentication Challenges >> http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html >>=20 >> If an authentication (access) request is unacceptable, how does the = server >> tell the client how it can provide proper credentials (e.g., by using = a different >> algorithm)? >>=20 >> Possible other topics: >>=20 >> - Mutual auth? >> http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html >>=20 >> - Resource authorization? >> http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html >>=20 >> ****** >>=20 >> /psa >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Feb 3 08:26: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 44F5A28C169 for ; Wed, 3 Feb 2010 08:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 Fk+plaOMBgH0 for ; Wed, 3 Feb 2010 08:26:33 -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 222FD28C0F6 for ; Wed, 3 Feb 2010 08:26:33 -0800 (PST) Received: (qmail 30574 invoked from network); 3 Feb 2010 16:27:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2010 16:27:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 3 Feb 2010 09:27:05 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "OAuth WG (oauth@ietf.org)" Date: Wed, 3 Feb 2010 09:26:45 -0700 Thread-Topic: Token Access Authentication Scheme Draft Thread-Index: Acp3Fy41mhoVRFEVTsOZ4fl/+l3K7wAKRu2wC2slyvA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112503E4234@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112503E4234@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 16:26:34 -0000 Thanks James. Your feedback is a bit late as the draft I am working on how drops the chal= lenge details completely, leaving only the indication that the server suppo= rts the Token scheme and using a realm to help the client figure out which = token to use (if they have more than one suitable for this resource). The reason why it makes little sense to have different schemes for differen= t types of tokens is that it is not the protected resource's job to say whi= ch algorithm should be used, but the server when issuing the token for that= resource. The draft did a poor job at separating the role of the server is= suing the tokens from the role of the server providing access to resources. As a side note, 'class' was my placeholder parameter for replacing 'realm' = (or at least suggesting that we take a look at that). Given the strong feel= ing here that there isn't really a current use case for servers issuing mul= tiple tokens (of different properties) for a single realm and then allowing= individual resources to reduce it to a smaller number of token types, ther= e is no reason to go beyond 'realm'. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Wednesday, February 03, 2010 5:14 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft >=20 > Hello OAuthers, >=20 > I have a couple of comments on the "Token Access Auth" draft. >=20 > Initial impression (as Eran asked for): Yuck. > Now I will try to be a bit more constructive. >=20 > This authentication draft breaks the existing model of HTTP authenticatio= n > too much. It puts a bunch of very different mechanisms (bearer, shared > secret, and public key crypto) into a single "Token" scheme. We should, > instead, have 1 scheme per mechanism, which is how HTTP auth has been > designed. > I agree with Dan Winship [email 2009-12-09] that a meta-scheme ("Token") > with multiple sub-schemes will not work well with existing code > architectures, which offer extensibility based on schemes, not based on a= ny > other parts of a WWW-Authenticate header. >=20 >=20 > It looks like 'realm' has been replaced by 'class'. This is working again= st the > existing model for HTTP auth, without a compelling reason. >=20 >=20 > A major rational for separating OAuth into Delegation and Authentication > documents was to recognize that they are logically independent. > Authentication needs an id (eg a token or user-id) and, optionally, a key= -- > but has no dependence on delegation. Ideally, authentication specs would > not mention (OAuth-style) delegation at all. > The authentication draft is too strongly bound to delegation by trying to > package all authentication mechanisms that can be used with delegation > under a single scheme. This cannot work. > There will be other schemes: at lower layers, signature in the URI, signi= ng > excluding the host name, using password-based key agreement, using > multiple round-trips, non-http protocols etc. >=20 >=20 > I am not against developing a mechanism to sign HTTP requests with a shar= ed > secret. I think it is far less important for the OAuth working group than > specifying the delegation flows, and signalling. >=20 >=20 > My suggestions: >=20 > 1. Define 1 very simple bearer scheme -- with no mention of delegation. > Don't include request signing in the same document. > Eg Authorization: ID a=3D > (use "WRAP" and "wrap_access_token" as labels if you must) >=20 > 2. Optionally, work on a mechanism to sign an HTTP request with a shared > secret without needing to exchange multiple messages with the server. > Ensure the mechanism can include 2 ids (authentication id and authorizati= on > id), and a channel binding parameter. >=20 > Plus the main part of the WG work: on delegation flows; server-to-client > signalling about how to do delegation (eg providing URI to redirect user = to); > stating which hosts and/or URIs a token (and optional secret) can be used= at; > working out how periodically refreshing credentials fits architecturally. >=20 >=20 > -- > James Manger >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Monday, 7 December 2009 7:28 PM > > To: OAuth WG (oauth@ietf.org) > > Subject: [OAUTH-WG] Token Access Authentication Scheme Draft > > > > http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt > > > > This draft is my first attempt at defining a general purpose > > authentication scheme to fulfill the WG requirement to produce a scheme > > suitable for 2-legged authentication. It also supports the OAuth 3- > > legged use cases as discussed on the list. This draft is in very early > > stage and has been submitted early to help better facilitate the > > conversation. > > > > It has been hard for us to discuss ideas without a concrete proposal. I > > hope this will help and motivate people to participate and provide > > feedback and new ideas. While there are many holes in the draft, it > > should be pretty easy to follow it. > > > > Major changes from OAuth 1.0: > > > > * New auth scheme with new parameter names > > * Signature base string replaced with normalized request string, and > > now does not require *any* encoding > > * Supports multiple token classes, authentication methods, and coverage > > scope > > > > Main feedback requested: > > > > * Initial impressions - this is particularly important to get. Does the > > draft make sense? > > * Functionality - does it include all the requested/required > > functionality? > > * Abstraction level - do the attributes provide the right level of > > configuration and choice? > > > > Please refrain from editorial feedback at this point (grammar, typos, > > etc.), but do provide structural feedback. > > > > I plan to push an updated version by Wed which will incorporate as much > > feedback as I can. I plan to ask for the WG to promote this draft to a > > WG item within 2 weeks. > > > > Thanks, > > > > EHL >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Feb 3 08:41:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA713A6C75 for ; Wed, 3 Feb 2010 08:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 xOuZw-PmZJ3R for ; Wed, 3 Feb 2010 08:41:00 -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 544B73A6C68 for ; Wed, 3 Feb 2010 08:41:00 -0800 (PST) Received: (qmail 9105 invoked from network); 3 Feb 2010 16:41:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2010 16:41:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 3 Feb 2010 09:41:16 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Wed, 3 Feb 2010 09:40:55 -0700 Thread-Topic: [OAUTH-WG] proposed agenda for second interim meeting Thread-Index: Acqk4c0Wgr8hiOUoTAyGjwakt8fvGwADBNDA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> In-Reply-To: <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 16:41:01 -0000 Has anyone gathered and reviewed use cases? I haven't seen much of that sho= wing up on the list. From my experience, asking people for use cases rarely= works, unless someone is willing to do the work and collect them (and so f= ar I haven't heard from such volunteer). I much prefer the process in which= we produce a technical document based on OAuth 1.0 and the new requirement= s as defined by WRAP, and discuss use cases as a property of the technical = attributes of this draft. Of course, you don't have to agree with me, but that puts the burden of pro= ducing use cases documentation on you and others interested in taking that = approach. We certainly have room for both, and keep in mind that my token d= raft is not (yet) a working group item. The indication I received from many of the active members of this list is t= hat we have a strong desire to show up at Anaheim with two stable drafts. I= think we are very close to getting the authentication piece done following= much of OAuth 1.0 functionality (only cleaner and better structures), as w= ell as treating bearer tokens as first class citizens. Given that no one ha= s started a discussion about the delegation flows to include, I doubt we wi= ll have a stable second draft, but I plan on getting the authentication pie= ce stable in time. It has also been my experience over the past two years that the biggest cha= llenge is to figure out the authentication piece. The 'go get a token' piec= e tends to be much easier to agree on. If we get the authentication draft t= o a stable place, my intention is to leave it there and focus on the second= part and come back to it as the delegation requirements become clearer (if= changes are needed). But at least it gives us something stable to build up= on. EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Wednesday, February 03, 2010 7:02 AM > To: Eran Hammer-Lahav > Cc: Peter Saint-Andre; OAuth WG > Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >=20 > Hi Eran >=20 > I think it is a little early in our phone discussions to get into technic= al details. > The next step according to the last call was to gather and review use cas= es. > Without rough consensus on what problem we are solving, your points > below (which all do need to be discussed at some point) is just moving > around deck chairs on the Titanic. >=20 > -- Dick >=20 > On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: >=20 > > Please add: > > > > - Discuss Adobe's recent request to allow excluding the host/port from = the > signed message. > > > > - With regards to #4, how should the challenge identify the token to be > used (realm comes free, do we need another)? > > > > - Should a single token support multiple signature algorithms? This has > implications as to the information the client has to include with the req= uest > (the algorithm used, etc.). > > > > - Where should the token structure live? OAuth 1.0 includes two respons= e > parameters (token and token_secret). However, since we are now moving > towards having the algorithm part of the token definition, as well as dur= ation > and other attributes, the server will need to provide this information to= the > client. This calls for a simple schema (can be any format but need to agr= ee to > consistent names). It is currently part of the authorization/delegation d= raft > (implicitly), but we should discuss moving it to the authentication draft= since > that's where it is used (the authorization draft simply hands those "thin= gs" > out). > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Peter Saint-Andre > >> Sent: Tuesday, February 02, 2010 9:15 PM > >> To: OAuth WG > >> Subject: [OAUTH-WG] proposed agenda for second interim meeting > >> > >> > >> > >> At the first interim meeting, we didn't get through our agenda: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html > >> > >> Therefore I propose that this time we focus on some unfinished > >> business, starting with the topic of authentication. I have reviewed > >> all of the related threads on the list and have come up with the follo= wing > *rough* agenda. > >> Your feedback is welcome to improve this (a.k.a. "agenda > >> bashing") either on the list or during the meeting. > >> > >> For logistics information, see here: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html > >> > >> ****** > >> > >> AGENDA > >> > >> Base proposal: draft-ietf-oauth-authentication-01 > >> > >> Eran had hoped to push out a new version in time for our meeting, but > >> hasn't been able to get to it yet. However, I think we can continue > >> to move forward with discussion. Feedback is welcome on the general > >> approach, as well as specific open issues. > >> > >> Open issues.... > >> > >> Issue #1: Request Signing vs. API Signing vs. Message Signing > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html > >> > >> 1a. Seeming consensus for message signing. > >> > >> 1b. No consensus yet on message format. > >> - JSON and textual key-value seem to be the leading candidates. > >> > >> 1c. Seeming consensus for multiple/extensible signature algorithms. > >> - HMAC-SHA1 > >> - HMAC-SHA256 > >> - RSASSA-PKCS1-v1.5-SHA256 > >> - PLAIN over SSL/TLS > >> > >> But: which of these are Mandatory-to-Implement? > >> > >> Issue #2: Include the Normalized Request with the Request? > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html > >> > >> Seeming consensus to not include the normalized request (e.g., > >> signature string). > >> > >> Issue #3: Allow Secrets in Cleartext, or Require Channel Encryption? > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html > >> > >> Seeming consensus that channel encryption is must-implement (which > >> does not necessarily mean must-deploy). > >> > >> Issue #4: Authentication Challenges > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html > >> > >> If an authentication (access) request is unacceptable, how does the > >> server tell the client how it can provide proper credentials (e.g., > >> by using a different algorithm)? > >> > >> Possible other topics: > >> > >> - Mutual auth? > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html > >> > >> - Resource authorization? > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html > >> > >> ****** > >> > >> /psa > >> > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Feb 3 08:45: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 CF22528C0DE for ; Wed, 3 Feb 2010 08:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_53=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 tSknNU0HBAa0 for ; Wed, 3 Feb 2010 08:45:58 -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 D663B28C0ED for ; Wed, 3 Feb 2010 08:45:54 -0800 (PST) Received: (qmail 13858 invoked from network); 3 Feb 2010 16:46:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2010 16:46:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 3 Feb 2010 09:46:31 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "OAuth WG (oauth@ietf.org)" Date: Wed, 3 Feb 2010 09:46:06 -0700 Thread-Topic: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge? Thread-Index: Acqfx6ayNhU2VNG/Qvi8Kw+JpK0C4gFDD9bgAAb25NA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B7E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437899D22BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112503E4238@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112503E4238@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge? X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Feb 2010 16:45:59 -0000 SXQgZG9lc24ndCBmZWVsIGxpa2Ugd2UgaGF2ZSBtdWNoIGludGVyZXN0IGF0IHRoaXMgbGV2ZWwg b2YgaW50ZXJvcGVyYWJpbGl0eSBhdCB0aGlzIHBvaW50Lg0KDQpFSEwNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1lcy5I Lk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDAz LCAyMDEwIDU6MzggQU0NCj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRyAob2F1dGhA aWV0Zi5vcmcpDQo+IFN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIFdoYXQgYXJlIHRoZSBwcmltYXJ5 IGNyaXRlcmlhIGluIGlzc3VpbmcgYW4NCj4gYXV0aGVudGljYXRpb24gY2hhbGxlbmdlPw0KPiAN Cj4gQW4gYXV0aGVudGljYXRpb24gY2hhbGxlbmdlIChXV1ctQXV0aGVudGljYXRlIGhlYWRlcikg ZGVmaW5lZCBpbiBhIHNwZWMNCj4gZm9yIGFuIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBzaG91 bGQgYmUgcHJlc2VudCwgYnV0IG9ubHkgd2l0aCBkZXRhaWxzDQo+IHNwZWNpZmljIHRvIHRoYXQg bWVjaGFuaXNtIChlZyBsaXN0IG9mIE1BQyBhbGdvcml0aG1zKS4NCj4gDQo+IEkgdGhpbmsgdGhl cmUgc2hvdWxkIGJlIGEgdG90YWxseSBzZXBhcmF0ZSBXV1ctQXV0aGVudGljYXRlIGhlYWRlcg0K PiBzcGVjaWZpY2FsbHkgc2F5aW5nICJhIGRlbGVnYXRpb24gZmxvdyBjYW4gYmUgdXNlZCB0byBh Y2Nlc3MgdGhpcyByZXNvdXJjZSIuIEl0DQo+IHNob3VsZCBpbmNsdWRlIGRldGFpbHMgc3VjaCBh cyB0aGUgVVJJIHRvIHJlZGlyZWN0IHRoZSB1c2VyIHRvLg0KPiANCj4gV2UgcmVhbGx5IG5lZWQg dGhpcyBpZiB3ZSB3YW50IHRvIG9mZmVyIGEgd2ViLXN0eWxlIHByb3RvY29sIHdpdGggYW55DQo+ IHNlbWJsYW5jZSBvZiBpbnRlcm9wZXJhYmlsaXR5LiBJZiB3ZSBvbWl0IGl0IGJlY2F1c2UgImNs aWVudHMgbmVlZCB0byBrbm93DQo+IGxvdHMgb2Ygb3RoZXIgQVBJLXNwZWNpZmljIGRldGFpbHMg YW55d2F5IiB0aGVuIHdlIHdvbnQgaGF2ZSBhIHBhdGggdG8gZ2V0DQo+IHBhc3QgdGhhdCBsaW1p dGF0aW9uIGluIGZ1dHVyZS4NCj4gDQo+IA0KPiAtLQ0KPiBKYW1lcyBNYW5nZXINCj4gDQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ID4gT2YgRXJh biBIYW1tZXItTGFoYXYNCj4gPiBTZW50OiBUaHVyc2RheSwgMjggSmFudWFyeSAyMDEwIDI6MTIg UE0NCj4gPiBUbzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KPiA+IFN1YmplY3Q6IFtPQVVU SC1XR10gV2hhdCBhcmUgdGhlIHByaW1hcnkgY3JpdGVyaWEgaW4gaXNzdWluZyBhbg0KPiA+IGF1 dGhlbnRpY2F0aW9uIGNoYWxsZW5nZT8NCj4gPg0KPiA+IEFuIGF1dGhlbnRpY2F0aW9uIGNoYWxs ZW5nZSAodG8gbWFrZSBzdXJlIHdlIGFyZSBhbGwgb24gdGhlIHNhbWUgcGFnZSkNCj4gPiBpcyBz b21ldGhpbmcgdGhlIHNlcnZlciBzZW5kcyB0byB0aGUgY2xpZW50IHdoZW4gZGVueWluZyBhY2Nl c3MgdG8gYQ0KPiA+IHByb3RlY3RlZCByZXNvdXJjZS4gVGhlIGNoYWxsZW5nZSBjYW4gYmUgYXMg c2ltcGxlIGFzICJ1c2UgQmFzaWMiLCBvcg0KPiA+IGNvbXBsZXggYXMgInVzZSBEaWdlc3Qgd2l0 aCB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMiLiBPQXV0aCAxLjANCj4gPiBkb2Vzbid0IHJlYWxs eSB1c2UgYSBjaGFsbGVuZ2UgYmVjYXVzZSBpdCB3YXMgY3JlYXRlZCBmb3IgY2FzZXMgd2hlcmUN Cj4gPiB0aGUgQVBJIGNhbGxzIGFyZSBwcmVjb25maWd1cmVkIGFuZCBoYXJkY29kZWQgaW50byB0 aGUgY2xpZW50LiBUaGUNCj4gPiBjbGllbnQgc2hvdWxkIG5ldmVyIHJlY2VpdmUgYW4gT0F1dGgg Y2hhbGxlbmdlIHRoZSB3YXkgdGhlIHByb3RvY29sDQo+ID4gd2FzIG9yaWdpbmFsbHkgZGVzaWdu ZWQuDQo+ID4NCj4gPiBJbiBteSB0b2tlbiBhdXRoZW50aWNhdGlvbiBkcmFmdCBJIHRyaWVkIHRv IHByb3Bvc2UgbXVsdGlwbGUNCj4gPiBtZWNoYW5pc21zIChub3QgZnVsbHkgYmFrZWQgeWV0KSBm b3IgaXNzdWluZyBhIGNoYWxsZW5nZSBhbmQgYWxsb3dpbmcNCj4gPiB0aGUgY2xpZW50IHRvIGZp Z3VyZSBvdXQgd2hhdCB0byBkbyBuZXh0LiBCZWZvcmUgcHJvZHVjaW5nIGFub3RoZXINCj4gPiBk cmFmdCwgaXQgaXMgaW1wb3J0YW50IHRvIGZpZ3VyZSBvdXQgd2hhdCBjaGFsbGVuZ2UgbW9kZWwg d2Ugd2FudCB0bw0KPiA+IHVzZS4gSGVyZSBhcmUgdGhlIGdlbmVyYWwgb3B0aW9ucyBJIGNhbWUg dXAgd2l0aDoNCj4gPg0KPiA+IDEuIEJhc2ljIC8gT0F1dGggMS4wIHN0eWxlIC0gU2ltcGx5IHNh eSAidXNlIFRva2VuIi4gVGhlIGNsaWVudCBpcw0KPiA+IGxlZnQgb24gaXRzIG93biB0byBmaWd1 cmUgb3V0IHdoYXQgdG8gZG8gbmV4dC4NCj4gPg0KPiA+IDIuIEJhc2ljIC8gT0F1dGggMS4wICsg c2ltcGxlIGRpc2NvdmVyeSAtIFNheSAidXNlIFRva2VuIGFuZCBpZiB5b3UNCj4gPiBuZWVkIGEg bmV3IHRva2VuIGdvIHRoZXJlIi4gSXQgaXMgc3RpbGwgbm90IGNsZWFyIGhvdyB0aGlzIHdpbGwg aGVscA0KPiA+IHRoZSBjbGllbnQgZ2l2ZW4gdGhhdCBnZXR0aW5nIGEgdG9rZW4gaXMgbGlrZWx5 IGl0IGluY2x1ZGUgbWFueQ0KPiA+IGRpZmZlcmVudCBvcHRpb25zLCBhbmQgdG8gZnVsbHkgYWRk cmVzcyB0aGlzIHdlIG5lZWQgdG8gZGlnIGRlZXAgaW50bw0KPiA+IGRpc2NvdmVyeSB3aGljaCB3 YXMgbGVmdCBvdXQgb2Ygc2NvcGUuDQo+ID4NCj4gPiAzLiBUb2tlbiBhdHRyaWJ1dGVzIC0gdGhl IHNlcnZlciBpbmZvcm1zIHRoZSBjbGllbnQgb2YgdGhlIGtpbmQgb2YNCj4gPiB0b2tlbnMgYWNj ZXB0ZWQgKGJhc2VkIG9uIHRoZWlyIGNyeXB0b2dyYXBoaWMgcHJvcGVydGllcyBvciB0aGUNCj4g PiByZXNvdXJjZS1zZXQvcmVhbG0gdGhleSBhcmUgZ29vZCBmb3IpLiBUaGlzIGlzIGp1c3QgbGlr ZSAjMiBidXQgd2l0aA0KPiA+IHRoZSBhYmlsaXR5IGZvciB0aGUgc2VydmVyIHRvIHN1cHBvcnQg bW9yZSB0aGFuIG9uZSB0b2tlbiB0eXBlIHBlcg0KPiA+IHJlc291cmNlLg0KPiA+DQo+ID4gUXVl c3Rpb246IElzIHRoZSBhYmlsaXR5IGZvciBhIHNpbmdsZSB0b2tlbi1wcm90ZWN0ZWQgcmVzb3Vy Y2UgdG8NCj4gPiBzdXBwb3J0IG1vcmUgdGhhbiBvbmUgdG9rZW4gdHlwZSAoc2F5IFBsYWluK1NT TCAqYW5kKiBITUFDLTI1NikgcGFydA0KPiA+IG9mIG91ciByZXF1aXJlbWVudHM/IElmIG5vdCwg dGhlcmUgaXMgbm8gcmVhc29uIGF0IGFsbCBmb3IgdGhlDQo+ID4gY2hhbGxlbmdlIHRvIGluY2x1 ZGUgYW55dGhpbmcgb3RoZXIgdGhhbiAjMSBvciAjMiAocHJvYmFibHkgZGVmaW5lZCBhcw0KPiA+ IGEgZnV0dXJlIGV4dGVuc2lvbikuDQo+ID4NCj4gPiBFSEwNCj4gPg0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBs aXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQo= From tonynad@microsoft.com Wed Feb 3 09:00: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 B09523A68F1 for ; Wed, 3 Feb 2010 09:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gns7kj5F9mVN for ; Wed, 3 Feb 2010 09:00:58 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 8A9CB3A6C86 for ; Wed, 3 Feb 2010 09:00:58 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 3 Feb 2010 09:01:41 -0800 Received: from TK5EX14MBXC103.redmond.corp.microsoft.com ([169.254.3.76]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Wed, 3 Feb 2010 09:01:40 -0800 From: Anthony Nadalin To: Eran Hammer-Lahav , Dick Hardt Thread-Topic: [OAUTH-WG] proposed agenda for second interim meeting Thread-Index: AQHKpJAFV4XrqQSG9EylclhoFpDFl5G0gOgAgAB/sgCAABuxgP//fmNg Date: Wed, 3 Feb 2010 17:01:38 +0000 Message-ID: References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 17:00:59 -0000 I would tend to agree with Dick based upon the last call and where that was= heading. I believe that Eve had some use cases to share around UMA -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Wednesday, February 03, 2010 8:41 AM To: Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting Has anyone gathered and reviewed use cases? I haven't seen much of that sho= wing up on the list. From my experience, asking people for use cases rarely= works, unless someone is willing to do the work and collect them (and so f= ar I haven't heard from such volunteer). I much prefer the process in which= we produce a technical document based on OAuth 1.0 and the new requirement= s as defined by WRAP, and discuss use cases as a property of the technical = attributes of this draft. Of course, you don't have to agree with me, but that puts the burden of pro= ducing use cases documentation on you and others interested in taking that = approach. We certainly have room for both, and keep in mind that my token d= raft is not (yet) a working group item. The indication I received from many of the active members of this list is t= hat we have a strong desire to show up at Anaheim with two stable drafts. I= think we are very close to getting the authentication piece done following= much of OAuth 1.0 functionality (only cleaner and better structures), as w= ell as treating bearer tokens as first class citizens. Given that no one ha= s started a discussion about the delegation flows to include, I doubt we wi= ll have a stable second draft, but I plan on getting the authentication pie= ce stable in time. It has also been my experience over the past two years that the biggest cha= llenge is to figure out the authentication piece. The 'go get a token' piec= e tends to be much easier to agree on. If we get the authentication draft t= o a stable place, my intention is to leave it there and focus on the second= part and come back to it as the delegation requirements become clearer (if= changes are needed). But at least it gives us something stable to build up= on. EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Wednesday, February 03, 2010 7:02 AM > To: Eran Hammer-Lahav > Cc: Peter Saint-Andre; OAuth WG > Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >=20 > Hi Eran >=20 > I think it is a little early in our phone discussions to get into technic= al details. > The next step according to the last call was to gather and review use cas= es. > Without rough consensus on what problem we are solving, your points=20 > below (which all do need to be discussed at some point) is just moving=20 > around deck chairs on the Titanic. >=20 > -- Dick >=20 > On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: >=20 > > Please add: > > > > - Discuss Adobe's recent request to allow excluding the host/port=20 > > from the > signed message. > > > > - With regards to #4, how should the challenge identify the token to=20 > > be > used (realm comes free, do we need another)? > > > > - Should a single token support multiple signature algorithms? This=20 > > has > implications as to the information the client has to include with the=20 > request (the algorithm used, etc.). > > > > - Where should the token structure live? OAuth 1.0 includes two=20 > > response > parameters (token and token_secret). However, since we are now moving=20 > towards having the algorithm part of the token definition, as well as=20 > duration and other attributes, the server will need to provide this=20 > information to the client. This calls for a simple schema (can be any=20 > format but need to agree to consistent names). It is currently part of=20 > the authorization/delegation draft (implicitly), but we should discuss=20 > moving it to the authentication draft since that's where it is used (the = authorization draft simply hands those "things" > out). > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > >> Behalf Of Peter Saint-Andre > >> Sent: Tuesday, February 02, 2010 9:15 PM > >> To: OAuth WG > >> Subject: [OAUTH-WG] proposed agenda for second interim meeting > >> > >> > >> > >> At the first interim meeting, we didn't get through our agenda: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html > >> > >> Therefore I propose that this time we focus on some unfinished=20 > >> business, starting with the topic of authentication. I have=20 > >> reviewed all of the related threads on the list and have come up=20 > >> with the following > *rough* agenda. > >> Your feedback is welcome to improve this (a.k.a. "agenda > >> bashing") either on the list or during the meeting. > >> > >> For logistics information, see here: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html > >> > >> ****** > >> > >> AGENDA > >> > >> Base proposal: draft-ietf-oauth-authentication-01 > >> > >> Eran had hoped to push out a new version in time for our meeting,=20 > >> but hasn't been able to get to it yet. However, I think we can=20 > >> continue to move forward with discussion. Feedback is welcome on=20 > >> the general approach, as well as specific open issues. > >> > >> Open issues.... > >> > >> Issue #1: Request Signing vs. API Signing vs. Message Signing=20 > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html > >> > >> 1a. Seeming consensus for message signing. > >> > >> 1b. No consensus yet on message format. > >> - JSON and textual key-value seem to be the leading candidates. > >> > >> 1c. Seeming consensus for multiple/extensible signature algorithms. > >> - HMAC-SHA1 > >> - HMAC-SHA256 > >> - RSASSA-PKCS1-v1.5-SHA256 > >> - PLAIN over SSL/TLS > >> > >> But: which of these are Mandatory-to-Implement? > >> > >> Issue #2: Include the Normalized Request with the Request? > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html > >> > >> Seeming consensus to not include the normalized request (e.g.,=20 > >> signature string). > >> > >> Issue #3: Allow Secrets in Cleartext, or Require Channel Encryption? > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html > >> > >> Seeming consensus that channel encryption is must-implement (which=20 > >> does not necessarily mean must-deploy). > >> > >> Issue #4: Authentication Challenges=20 > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html > >> > >> If an authentication (access) request is unacceptable, how does the=20 > >> server tell the client how it can provide proper credentials (e.g.,=20 > >> by using a different algorithm)? > >> > >> Possible other topics: > >> > >> - Mutual auth? > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html > >> > >> - Resource authorization? > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html > >> > >> ****** > >> > >> /psa > >> > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Feb 3 09:34:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9413A6898 for ; Wed, 3 Feb 2010 09:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 PNkhi1ccLX3R for ; Wed, 3 Feb 2010 09:34:13 -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 7EB1B3A6882 for ; Wed, 3 Feb 2010 09:34:13 -0800 (PST) Received: (qmail 14342 invoked from network); 3 Feb 2010 17:34:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2010 17:34:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 3 Feb 2010 10:34:28 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin Date: Wed, 3 Feb 2010 10:34:07 -0700 Thread-Topic: [OAUTH-WG] proposed agenda for second interim meeting Thread-Index: AQHKpJAFV4XrqQSG9EylclhoFpDFl5G0gOgAgAB/sgCAABuxgP//fmNggAAG8sA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 17:34:14 -0000 Hi Anthony, The problem with this approach is that it hasn't worked (multiple times) be= fore because no one ever wants to do the work of collecting and writing the= use cases. What we get instead are short cryptic lists and pointers to edg= e cases. We have a good grasp on how OAuth 1.0 is used and its limitations = as addressed by the WRAP draft. The best use of my time is to continue working on the drafts and asking tec= hnical questions whenever a decision is needed. If and when someone writes = use cases, I will review those and see if they are supported by the drafts. =20 I will leave it up to the chairs to decide how they want to guide the worki= ng group. EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Wednesday, February 03, 2010 9:02 AM > To: Eran Hammer-Lahav; Dick Hardt > Cc: OAuth WG > Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting >=20 > I would tend to agree with Dick based upon the last call and where that w= as > heading. I believe that Eve had some use cases to share around UMA >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Wednesday, February 03, 2010 8:41 AM > To: Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >=20 > Has anyone gathered and reviewed use cases? I haven't seen much of that > showing up on the list. From my experience, asking people for use cases > rarely works, unless someone is willing to do the work and collect them (= and > so far I haven't heard from such volunteer). I much prefer the process in > which we produce a technical document based on OAuth 1.0 and the new > requirements as defined by WRAP, and discuss use cases as a property of t= he > technical attributes of this draft. >=20 > Of course, you don't have to agree with me, but that puts the burden of > producing use cases documentation on you and others interested in taking > that approach. We certainly have room for both, and keep in mind that my > token draft is not (yet) a working group item. >=20 > The indication I received from many of the active members of this list is= that > we have a strong desire to show up at Anaheim with two stable drafts. I t= hink > we are very close to getting the authentication piece done following much= of > OAuth 1.0 functionality (only cleaner and better structures), as well as > treating bearer tokens as first class citizens. Given that no one has sta= rted a > discussion about the delegation flows to include, I doubt we will have a > stable second draft, but I plan on getting the authentication piece stabl= e in > time. >=20 > It has also been my experience over the past two years that the biggest > challenge is to figure out the authentication piece. The 'go get a token'= piece > tends to be much easier to agree on. If we get the authentication draft t= o a > stable place, my intention is to leave it there and focus on the second p= art > and come back to it as the delegation requirements become clearer (if > changes are needed). But at least it gives us something stable to build u= pon. >=20 > EHL >=20 > > -----Original Message----- > > From: Dick Hardt [mailto:dick.hardt@gmail.com] > > Sent: Wednesday, February 03, 2010 7:02 AM > > To: Eran Hammer-Lahav > > Cc: Peter Saint-Andre; OAuth WG > > Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting > > > > Hi Eran > > > > I think it is a little early in our phone discussions to get into techn= ical details. > > The next step according to the last call was to gather and review use c= ases. > > Without rough consensus on what problem we are solving, your points > > below (which all do need to be discussed at some point) is just moving > > around deck chairs on the Titanic. > > > > -- Dick > > > > On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: > > > > > Please add: > > > > > > - Discuss Adobe's recent request to allow excluding the host/port > > > from the > > signed message. > > > > > > - With regards to #4, how should the challenge identify the token to > > > be > > used (realm comes free, do we need another)? > > > > > > - Should a single token support multiple signature algorithms? This > > > has > > implications as to the information the client has to include with the > > request (the algorithm used, etc.). > > > > > > - Where should the token structure live? OAuth 1.0 includes two > > > response > > parameters (token and token_secret). However, since we are now moving > > towards having the algorithm part of the token definition, as well as > > duration and other attributes, the server will need to provide this > > information to the client. This calls for a simple schema (can be any > > format but need to agree to consistent names). It is currently part of > > the authorization/delegation draft (implicitly), but we should discuss > > moving it to the authentication draft since that's where it is used (th= e > authorization draft simply hands those "things" > > out). > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > >> Behalf Of Peter Saint-Andre > > >> Sent: Tuesday, February 02, 2010 9:15 PM > > >> To: OAuth WG > > >> Subject: [OAUTH-WG] proposed agenda for second interim meeting > > >> > > >> > > >> > > >> At the first interim meeting, we didn't get through our agenda: > > >> > > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html > > >> > > >> Therefore I propose that this time we focus on some unfinished > > >> business, starting with the topic of authentication. I have > > >> reviewed all of the related threads on the list and have come up > > >> with the following > > *rough* agenda. > > >> Your feedback is welcome to improve this (a.k.a. "agenda > > >> bashing") either on the list or during the meeting. > > >> > > >> For logistics information, see here: > > >> > > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html > > >> > > >> ****** > > >> > > >> AGENDA > > >> > > >> Base proposal: draft-ietf-oauth-authentication-01 > > >> > > >> Eran had hoped to push out a new version in time for our meeting, > > >> but hasn't been able to get to it yet. However, I think we can > > >> continue to move forward with discussion. Feedback is welcome on > > >> the general approach, as well as specific open issues. > > >> > > >> Open issues.... > > >> > > >> Issue #1: Request Signing vs. API Signing vs. Message Signing > > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html > > >> > > >> 1a. Seeming consensus for message signing. > > >> > > >> 1b. No consensus yet on message format. > > >> - JSON and textual key-value seem to be the leading candidates. > > >> > > >> 1c. Seeming consensus for multiple/extensible signature algorithms. > > >> - HMAC-SHA1 > > >> - HMAC-SHA256 > > >> - RSASSA-PKCS1-v1.5-SHA256 > > >> - PLAIN over SSL/TLS > > >> > > >> But: which of these are Mandatory-to-Implement? > > >> > > >> Issue #2: Include the Normalized Request with the Request? > > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html > > >> > > >> Seeming consensus to not include the normalized request (e.g., > > >> signature string). > > >> > > >> Issue #3: Allow Secrets in Cleartext, or Require Channel Encryption? > > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html > > >> > > >> Seeming consensus that channel encryption is must-implement (which > > >> does not necessarily mean must-deploy). > > >> > > >> Issue #4: Authentication Challenges > > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html > > >> > > >> If an authentication (access) request is unacceptable, how does the > > >> server tell the client how it can provide proper credentials (e.g., > > >> by using a different algorithm)? > > >> > > >> Possible other topics: > > >> > > >> - Mutual auth? > > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html > > >> > > >> - Resource authorization? > > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html > > >> > > >> ****** > > >> > > >> /psa > > >> > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Wed Feb 3 09:42:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8059E3A6C80 for ; Wed, 3 Feb 2010 09:42:54 -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 ZWdTbQBWH2FT for ; Wed, 3 Feb 2010 09:42:53 -0800 (PST) Received: from mail1.sxip.com (nvg-01-e0.yvr.sxip.com [72.15.146.183]) by core3.amsl.com (Postfix) with ESMTP id 922AF3A6898 for ; Wed, 3 Feb 2010 09:42:52 -0800 (PST) Received: from [192.168.1.243] (c-24-17-212-68.hsd1.wa.comcast.net [24.17.212.68]) (authenticated bits=0) by mail1.sxip.com (8.13.8/8.13.8) with ESMTP id o13HhOLU022485 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Feb 2010 09:43:24 -0800 (PST) (envelope-from dick.hardt@gmail.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 3 Feb 2010 09:43:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) X-Scanned-By: MIMEDefang 2.63 on 172.16.6.3 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 17:42:54 -0000 Eran,=20 Both Tony and I are explaining to you what happened on the call. If you = had been on the call, you could have presented your view on how to = proceed with the calls.=20 While you may have a different opinion on how to proceed (which I am NOT = arguing with), arguing with us on what happened on the call seems = pointless. -- Dick On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote: > Hi Anthony, >=20 > The problem with this approach is that it hasn't worked (multiple = times) before because no one ever wants to do the work of collecting and = writing the use cases. What we get instead are short cryptic lists and = pointers to edge cases. We have a good grasp on how OAuth 1.0 is used = and its limitations as addressed by the WRAP draft. >=20 > The best use of my time is to continue working on the drafts and = asking technical questions whenever a decision is needed. If and when = someone writes use cases, I will review those and see if they are = supported by the drafts. >=20 > I will leave it up to the chairs to decide how they want to guide the = working group. >=20 > EHL >=20 >> -----Original Message----- >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] >> Sent: Wednesday, February 03, 2010 9:02 AM >> To: Eran Hammer-Lahav; Dick Hardt >> Cc: OAuth WG >> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting >>=20 >> I would tend to agree with Dick based upon the last call and where = that was >> heading. I believe that Eve had some use cases to share around UMA >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Eran Hammer-Lahav >> Sent: Wednesday, February 03, 2010 8:41 AM >> To: Dick Hardt >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >>=20 >> Has anyone gathered and reviewed use cases? I haven't seen much of = that >> showing up on the list. =46rom my experience, asking people for use = cases >> rarely works, unless someone is willing to do the work and collect = them (and >> so far I haven't heard from such volunteer). I much prefer the = process in >> which we produce a technical document based on OAuth 1.0 and the new >> requirements as defined by WRAP, and discuss use cases as a property = of the >> technical attributes of this draft. >>=20 >> Of course, you don't have to agree with me, but that puts the burden = of >> producing use cases documentation on you and others interested in = taking >> that approach. We certainly have room for both, and keep in mind that = my >> token draft is not (yet) a working group item. >>=20 >> The indication I received from many of the active members of this = list is that >> we have a strong desire to show up at Anaheim with two stable drafts. = I think >> we are very close to getting the authentication piece done following = much of >> OAuth 1.0 functionality (only cleaner and better structures), as well = as >> treating bearer tokens as first class citizens. Given that no one has = started a >> discussion about the delegation flows to include, I doubt we will = have a >> stable second draft, but I plan on getting the authentication piece = stable in >> time. >>=20 >> It has also been my experience over the past two years that the = biggest >> challenge is to figure out the authentication piece. The 'go get a = token' piece >> tends to be much easier to agree on. If we get the authentication = draft to a >> stable place, my intention is to leave it there and focus on the = second part >> and come back to it as the delegation requirements become clearer (if >> changes are needed). But at least it gives us something stable to = build upon. >>=20 >> EHL >>=20 >>> -----Original Message----- >>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>> Sent: Wednesday, February 03, 2010 7:02 AM >>> To: Eran Hammer-Lahav >>> Cc: Peter Saint-Andre; OAuth WG >>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >>>=20 >>> Hi Eran >>>=20 >>> I think it is a little early in our phone discussions to get into = technical details. >>> The next step according to the last call was to gather and review = use cases. >>> Without rough consensus on what problem we are solving, your points >>> below (which all do need to be discussed at some point) is just = moving >>> around deck chairs on the Titanic. >>>=20 >>> -- Dick >>>=20 >>> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: >>>=20 >>>> Please add: >>>>=20 >>>> - Discuss Adobe's recent request to allow excluding the host/port >>>> from the >>> signed message. >>>>=20 >>>> - With regards to #4, how should the challenge identify the token = to >>>> be >>> used (realm comes free, do we need another)? >>>>=20 >>>> - Should a single token support multiple signature algorithms? This >>>> has >>> implications as to the information the client has to include with = the >>> request (the algorithm used, etc.). >>>>=20 >>>> - Where should the token structure live? OAuth 1.0 includes two >>>> response >>> parameters (token and token_secret). However, since we are now = moving >>> towards having the algorithm part of the token definition, as well = as >>> duration and other attributes, the server will need to provide this >>> information to the client. This calls for a simple schema (can be = any >>> format but need to agree to consistent names). It is currently part = of >>> the authorization/delegation draft (implicitly), but we should = discuss >>> moving it to the authentication draft since that's where it is used = (the >> authorization draft simply hands those "things" >>> out). >>>>=20 >>>> EHL >>>>=20 >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>> Behalf Of Peter Saint-Andre >>>>> Sent: Tuesday, February 02, 2010 9:15 PM >>>>> To: OAuth WG >>>>> Subject: [OAUTH-WG] proposed agenda for second interim meeting >>>>>=20 >>>>> >>>>>=20 >>>>> At the first interim meeting, we didn't get through our agenda: >>>>>=20 >>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html >>>>>=20 >>>>> Therefore I propose that this time we focus on some unfinished >>>>> business, starting with the topic of authentication. I have >>>>> reviewed all of the related threads on the list and have come up >>>>> with the following >>> *rough* agenda. >>>>> Your feedback is welcome to improve this (a.k.a. "agenda >>>>> bashing") either on the list or during the meeting. >>>>>=20 >>>>> For logistics information, see here: >>>>>=20 >>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html >>>>>=20 >>>>> ****** >>>>>=20 >>>>> AGENDA >>>>>=20 >>>>> Base proposal: draft-ietf-oauth-authentication-01 >>>>>=20 >>>>> Eran had hoped to push out a new version in time for our meeting, >>>>> but hasn't been able to get to it yet. However, I think we can >>>>> continue to move forward with discussion. Feedback is welcome on >>>>> the general approach, as well as specific open issues. >>>>>=20 >>>>> Open issues.... >>>>>=20 >>>>> Issue #1: Request Signing vs. API Signing vs. Message Signing >>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html >>>>>=20 >>>>> 1a. Seeming consensus for message signing. >>>>>=20 >>>>> 1b. No consensus yet on message format. >>>>> - JSON and textual key-value seem to be the leading candidates. >>>>>=20 >>>>> 1c. Seeming consensus for multiple/extensible signature = algorithms. >>>>> - HMAC-SHA1 >>>>> - HMAC-SHA256 >>>>> - RSASSA-PKCS1-v1.5-SHA256 >>>>> - PLAIN over SSL/TLS >>>>>=20 >>>>> But: which of these are Mandatory-to-Implement? >>>>>=20 >>>>> Issue #2: Include the Normalized Request with the Request? >>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html >>>>>=20 >>>>> Seeming consensus to not include the normalized request (e.g., >>>>> signature string). >>>>>=20 >>>>> Issue #3: Allow Secrets in Cleartext, or Require Channel = Encryption? >>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html >>>>>=20 >>>>> Seeming consensus that channel encryption is must-implement (which >>>>> does not necessarily mean must-deploy). >>>>>=20 >>>>> Issue #4: Authentication Challenges >>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html >>>>>=20 >>>>> If an authentication (access) request is unacceptable, how does = the >>>>> server tell the client how it can provide proper credentials = (e.g., >>>>> by using a different algorithm)? >>>>>=20 >>>>> Possible other topics: >>>>>=20 >>>>> - Mutual auth? >>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html >>>>>=20 >>>>> - Resource authorization? >>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html >>>>>=20 >>>>> ****** >>>>>=20 >>>>> /psa >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Feb 3 09:59:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B253A6C8D for ; Wed, 3 Feb 2010 09:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 N92kzjMS5kQk for ; Wed, 3 Feb 2010 09:59: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 B0E553A6845 for ; Wed, 3 Feb 2010 09:59:37 -0800 (PST) Received: (qmail 30752 invoked from network); 3 Feb 2010 18:00:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2010 18:00:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 3 Feb 2010 10:59:51 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Wed, 3 Feb 2010 10:59:36 -0700 Thread-Topic: [OAUTH-WG] proposed agenda for second interim meeting Thread-Index: Acqk+GTD3Fgg3tIrSti5TxHikacRXQAALyMA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> In-Reply-To: <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 17:59:39 -0000 I read the minutes. I don't need to be on the call to present my views on how to proceed. That'= s not how the IETF operates. I have been expressing my views for the past y= ear, right here on the list. I didn't see any consensus call from the chair= s about taking this approach (instead of others). I also noticed the lack of follow up since the call with any kind of discus= sion on use cases. I have asked the chairs to provide a place to discuss technical issues and = that is what this second call is about. Unless the chairs decide to change = it. EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Wednesday, February 03, 2010 9:43 AM > To: Eran Hammer-Lahav > Cc: Anthony Nadalin; OAuth WG > Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >=20 > Eran, >=20 > Both Tony and I are explaining to you what happened on the call. If you h= ad > been on the call, you could have presented your view on how to proceed > with the calls. > While you may have a different opinion on how to proceed (which I am NOT > arguing with), arguing with us on what happened on the call seems pointle= ss. >=20 > -- Dick >=20 > On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote: >=20 > > Hi Anthony, > > > > The problem with this approach is that it hasn't worked (multiple times= ) > before because no one ever wants to do the work of collecting and writing > the use cases. What we get instead are short cryptic lists and pointers t= o > edge cases. We have a good grasp on how OAuth 1.0 is used and its > limitations as addressed by the WRAP draft. > > > > The best use of my time is to continue working on the drafts and asking > technical questions whenever a decision is needed. If and when someone > writes use cases, I will review those and see if they are supported by th= e > drafts. > > > > I will leave it up to the chairs to decide how they want to guide the w= orking > group. > > > > EHL > > > >> -----Original Message----- > >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] > >> Sent: Wednesday, February 03, 2010 9:02 AM > >> To: Eran Hammer-Lahav; Dick Hardt > >> Cc: OAuth WG > >> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting > >> > >> I would tend to agree with Dick based upon the last call and where > >> that was heading. I believe that Eve had some use cases to share > >> around UMA > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Eran Hammer-Lahav > >> Sent: Wednesday, February 03, 2010 8:41 AM > >> To: Dick Hardt > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting > >> > >> Has anyone gathered and reviewed use cases? I haven't seen much of > >> that showing up on the list. From my experience, asking people for > >> use cases rarely works, unless someone is willing to do the work and > >> collect them (and so far I haven't heard from such volunteer). I much > >> prefer the process in which we produce a technical document based on > >> OAuth 1.0 and the new requirements as defined by WRAP, and discuss > >> use cases as a property of the technical attributes of this draft. > >> > >> Of course, you don't have to agree with me, but that puts the burden > >> of producing use cases documentation on you and others interested in > >> taking that approach. We certainly have room for both, and keep in > >> mind that my token draft is not (yet) a working group item. > >> > >> The indication I received from many of the active members of this > >> list is that we have a strong desire to show up at Anaheim with two > >> stable drafts. I think we are very close to getting the > >> authentication piece done following much of OAuth 1.0 functionality > >> (only cleaner and better structures), as well as treating bearer > >> tokens as first class citizens. Given that no one has started a > >> discussion about the delegation flows to include, I doubt we will > >> have a stable second draft, but I plan on getting the authentication p= iece > stable in time. > >> > >> It has also been my experience over the past two years that the > >> biggest challenge is to figure out the authentication piece. The 'go > >> get a token' piece tends to be much easier to agree on. If we get the > >> authentication draft to a stable place, my intention is to leave it > >> there and focus on the second part and come back to it as the > >> delegation requirements become clearer (if changes are needed). But at > least it gives us something stable to build upon. > >> > >> EHL > >> > >>> -----Original Message----- > >>> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >>> Sent: Wednesday, February 03, 2010 7:02 AM > >>> To: Eran Hammer-Lahav > >>> Cc: Peter Saint-Andre; OAuth WG > >>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting > >>> > >>> Hi Eran > >>> > >>> I think it is a little early in our phone discussions to get into tec= hnical > details. > >>> The next step according to the last call was to gather and review use > cases. > >>> Without rough consensus on what problem we are solving, your points > >>> below (which all do need to be discussed at some point) is just > >>> moving around deck chairs on the Titanic. > >>> > >>> -- Dick > >>> > >>> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: > >>> > >>>> Please add: > >>>> > >>>> - Discuss Adobe's recent request to allow excluding the host/port > >>>> from the > >>> signed message. > >>>> > >>>> - With regards to #4, how should the challenge identify the token > >>>> to be > >>> used (realm comes free, do we need another)? > >>>> > >>>> - Should a single token support multiple signature algorithms? This > >>>> has > >>> implications as to the information the client has to include with > >>> the request (the algorithm used, etc.). > >>>> > >>>> - Where should the token structure live? OAuth 1.0 includes two > >>>> response > >>> parameters (token and token_secret). However, since we are now > >>> moving towards having the algorithm part of the token definition, as > >>> well as duration and other attributes, the server will need to > >>> provide this information to the client. This calls for a simple > >>> schema (can be any format but need to agree to consistent names). It > >>> is currently part of the authorization/delegation draft > >>> (implicitly), but we should discuss moving it to the authentication > >>> draft since that's where it is used (the > >> authorization draft simply hands those "things" > >>> out). > >>>> > >>>> EHL > >>>> > >>>>> -----Original Message----- > >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>>> Behalf Of Peter Saint-Andre > >>>>> Sent: Tuesday, February 02, 2010 9:15 PM > >>>>> To: OAuth WG > >>>>> Subject: [OAUTH-WG] proposed agenda for second interim meeting > >>>>> > >>>>> > >>>>> > >>>>> At the first interim meeting, we didn't get through our agenda: > >>>>> > >>>>> http://www.ietf.org/mail- > archive/web/oauth/current/msg01013.html > >>>>> > >>>>> Therefore I propose that this time we focus on some unfinished > >>>>> business, starting with the topic of authentication. I have > >>>>> reviewed all of the related threads on the list and have come up > >>>>> with the following > >>> *rough* agenda. > >>>>> Your feedback is welcome to improve this (a.k.a. "agenda > >>>>> bashing") either on the list or during the meeting. > >>>>> > >>>>> For logistics information, see here: > >>>>> > >>>>> http://www.ietf.org/mail- > archive/web/oauth/current/msg01085.html > >>>>> > >>>>> ****** > >>>>> > >>>>> AGENDA > >>>>> > >>>>> Base proposal: draft-ietf-oauth-authentication-01 > >>>>> > >>>>> Eran had hoped to push out a new version in time for our meeting, > >>>>> but hasn't been able to get to it yet. However, I think we can > >>>>> continue to move forward with discussion. Feedback is welcome on > >>>>> the general approach, as well as specific open issues. > >>>>> > >>>>> Open issues.... > >>>>> > >>>>> Issue #1: Request Signing vs. API Signing vs. Message Signing > >>>>> http://www.ietf.org/mail- > archive/web/oauth/current/msg00961.html > >>>>> > >>>>> 1a. Seeming consensus for message signing. > >>>>> > >>>>> 1b. No consensus yet on message format. > >>>>> - JSON and textual key-value seem to be the leading candidates. > >>>>> > >>>>> 1c. Seeming consensus for multiple/extensible signature algorithms. > >>>>> - HMAC-SHA1 > >>>>> - HMAC-SHA256 > >>>>> - RSASSA-PKCS1-v1.5-SHA256 > >>>>> - PLAIN over SSL/TLS > >>>>> > >>>>> But: which of these are Mandatory-to-Implement? > >>>>> > >>>>> Issue #2: Include the Normalized Request with the Request? > >>>>> http://www.ietf.org/mail- > archive/web/oauth/current/msg00962.html > >>>>> > >>>>> Seeming consensus to not include the normalized request (e.g., > >>>>> signature string). > >>>>> > >>>>> Issue #3: Allow Secrets in Cleartext, or Require Channel Encryption= ? > >>>>> http://www.ietf.org/mail- > archive/web/oauth/current/msg00963.html > >>>>> > >>>>> Seeming consensus that channel encryption is must-implement > (which > >>>>> does not necessarily mean must-deploy). > >>>>> > >>>>> Issue #4: Authentication Challenges > >>>>> http://www.ietf.org/mail- > archive/web/oauth/current/msg01039.html > >>>>> > >>>>> If an authentication (access) request is unacceptable, how does > >>>>> the server tell the client how it can provide proper credentials > >>>>> (e.g., by using a different algorithm)? > >>>>> > >>>>> Possible other topics: > >>>>> > >>>>> - Mutual auth? > >>>>> http://www.ietf.org/mail- > archive/web/oauth/current/msg00935.html > >>>>> > >>>>> - Resource authorization? > >>>>> http://www.ietf.org/mail- > archive/web/oauth/current/msg01033.html > >>>>> > >>>>> ****** > >>>>> > >>>>> /psa > >>>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From romeda@gmail.com Wed Feb 3 10:14: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 EC5C83A6C9F for ; Wed, 3 Feb 2010 10:14:57 -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 nZV+gfYPZf7Y for ; Wed, 3 Feb 2010 10:14:56 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.187]) by core3.amsl.com (Postfix) with ESMTP id 04F7928C170 for ; Wed, 3 Feb 2010 10:14:55 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id l14so106512gvf.15 for ; Wed, 03 Feb 2010 10:15:35 -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=FXRePVwkAkn+QMa4BtIfhidPsZfjXdx5xQoBIBlhcTg=; b=hfHlJHQiUd/cLANL2H79xn3FKj1a8h1q1wP7ueWebaZvmL58qQ3s+TvWiXy0T3sSrJ kFK+QaJlaCQSXqm58CKMCGXShG2g2MmApm61Cbfu29ZnmVPKU2z3g0zqyeZrqchG6guf cz4k9IAmU0IfOw6028PwWvIEoDOe0Kuhxfj70= 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=dxIHM3tM63zu6s4w0G0+CcXkFKY3fyKIyxOlLPw5J8pjP3qYr/Axu/1dWH2fzkumnt qCPHRS5+TmH8qh5gfFRO6cXQElL66Otp44eUCuaDNAJoLZnH3CetwHdcbE1jHRJZ6/5/ DpBJJFyzp5cw6CU7FbDEOWZdwo+8tIxdDNsZY= MIME-Version: 1.0 Received: by 10.103.76.22 with SMTP id d22mr1843723mul.79.1265220935283; Wed, 03 Feb 2010 10:15:35 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Blaine Cook Date: Wed, 3 Feb 2010 18:15:15 +0000 Message-ID: To: OAuth WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 18:14:58 -0000 I've started a wiki page here: http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthFeatureMatrix to pull in the features people think are important, and give us both some way of collecting that data over time and expressing what's present or missing from each protocol & proposal. Despite being called FeatureMatrix, please treat it as a Use Case Matrix. If people don't want to go in and edit the wiki table (I don't blame you) please send your use cases to me (romeda@gmail.com) and I will fill them out on the wiki for you. If you have blog posts or links to pre-existing use cases or features, please include those as they will help clarify the features. b. ps. the wiki won't let me put in a bookmarklet to make the text entry not suck (i.e., use a fixed-width font), so here's one in case you do decide to edit the wiki: javascript:document.getElementById('text').style.fontFamily=3D'courier' On 3 February 2010 17:59, Eran Hammer-Lahav wrote: > I read the minutes. > > I don't need to be on the call to present my views on how to proceed. Tha= t's not how the IETF operates. I have been expressing my views for the past= year, right here on the list. I didn't see any consensus call from the cha= irs about taking this approach (instead of others). > > I also noticed the lack of follow up since the call with any kind of disc= ussion on use cases. > > I have asked the chairs to provide a place to discuss technical issues an= d that is what this second call is about. Unless the chairs decide to chang= e it. > > EHL > >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Wednesday, February 03, 2010 9:43 AM >> To: Eran Hammer-Lahav >> Cc: Anthony Nadalin; OAuth WG >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >> >> Eran, >> >> Both Tony and I are explaining to you what happened on the call. If you = had >> been on the call, you could have presented your view on how to proceed >> with the calls. >> While you may have a different opinion on how to proceed (which I am NOT >> arguing with), arguing with us on what happened on the call seems pointl= ess. >> >> -- Dick >> >> On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote: >> >> > Hi Anthony, >> > >> > The problem with this approach is that it hasn't worked (multiple time= s) >> before because no one ever wants to do the work of collecting and writin= g >> the use cases. What we get instead are short cryptic lists and pointers = to >> edge cases. We have a good grasp on how OAuth 1.0 is used and its >> limitations as addressed by the WRAP draft. >> > >> > The best use of my time is to continue working on the drafts and askin= g >> technical questions whenever a decision is needed. If and when someone >> writes use cases, I will review those and see if they are supported by t= he >> drafts. >> > >> > I will leave it up to the chairs to decide how they want to guide the = working >> group. >> > >> > EHL >> > >> >> -----Original Message----- >> >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] >> >> Sent: Wednesday, February 03, 2010 9:02 AM >> >> To: Eran Hammer-Lahav; Dick Hardt >> >> Cc: OAuth WG >> >> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting >> >> >> >> I would tend to agree with Dick based upon the last call and where >> >> that was heading. I believe that Eve had some use cases to share >> >> around UMA >> >> >> >> -----Original Message----- >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >> Behalf Of Eran Hammer-Lahav >> >> Sent: Wednesday, February 03, 2010 8:41 AM >> >> To: Dick Hardt >> >> Cc: OAuth WG >> >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >> >> >> >> Has anyone gathered and reviewed use cases? I haven't seen much of >> >> that showing up on the list. From my experience, asking people for >> >> use cases rarely works, unless someone is willing to do the work and >> >> collect them (and so far I haven't heard from such volunteer). I much >> >> prefer the process in which we produce a technical document based on >> >> OAuth 1.0 and the new requirements as defined by WRAP, and discuss >> >> use cases as a property of the technical attributes of this draft. >> >> >> >> Of course, you don't have to agree with me, but that puts the burden >> >> of producing use cases documentation on you and others interested in >> >> taking that approach. We certainly have room for both, and keep in >> >> mind that my token draft is not (yet) a working group item. >> >> >> >> The indication I received from many of the active members of this >> >> list is that we have a strong desire to show up at Anaheim with two >> >> stable drafts. I think we are very close to getting the >> >> authentication piece done following much of OAuth 1.0 functionality >> >> (only cleaner and better structures), as well as treating bearer >> >> tokens as first class citizens. Given that no one has started a >> >> discussion about the delegation flows to include, I doubt we will >> >> have a stable second draft, but I plan on getting the authentication = piece >> stable in time. >> >> >> >> It has also been my experience over the past two years that the >> >> biggest challenge is to figure out the authentication piece. The 'go >> >> get a token' piece tends to be much easier to agree on. If we get the >> >> authentication draft to a stable place, my intention is to leave it >> >> there and focus on the second part and come back to it as the >> >> delegation requirements become clearer (if changes are needed). But a= t >> least it gives us something stable to build upon. >> >> >> >> EHL >> >> >> >>> -----Original Message----- >> >>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> >>> Sent: Wednesday, February 03, 2010 7:02 AM >> >>> To: Eran Hammer-Lahav >> >>> Cc: Peter Saint-Andre; OAuth WG >> >>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >> >>> >> >>> Hi Eran >> >>> >> >>> I think it is a little early in our phone discussions to get into te= chnical >> details. >> >>> The next step according to the last call was to gather and review us= e >> cases. >> >>> Without rough consensus on what problem we are solving, your points >> >>> below (which all do need to be discussed at some point) is just >> >>> moving around deck chairs on the Titanic. >> >>> >> >>> -- Dick >> >>> >> >>> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: >> >>> >> >>>> Please add: >> >>>> >> >>>> - Discuss Adobe's recent request to allow excluding the host/port >> >>>> from the >> >>> signed message. >> >>>> >> >>>> - With regards to #4, how should the challenge identify the token >> >>>> to be >> >>> used (realm comes free, do we need another)? >> >>>> >> >>>> - Should a single token support multiple signature algorithms? This >> >>>> has >> >>> implications as to the information the client has to include with >> >>> the request (the algorithm used, etc.). >> >>>> >> >>>> - Where should the token structure live? OAuth 1.0 includes two >> >>>> response >> >>> parameters (token and token_secret). However, since we are now >> >>> moving towards having the algorithm part of the token definition, as >> >>> well as duration and other attributes, the server will need to >> >>> provide this information to the client. This calls for a simple >> >>> schema (can be any format but need to agree to consistent names). It >> >>> is currently part of the authorization/delegation draft >> >>> (implicitly), but we should discuss moving it to the authentication >> >>> draft since that's where it is used (the >> >> authorization draft simply hands those "things" >> >>> out). >> >>>> >> >>>> EHL >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >>>>> Behalf Of Peter Saint-Andre >> >>>>> Sent: Tuesday, February 02, 2010 9:15 PM >> >>>>> To: OAuth WG >> >>>>> Subject: [OAUTH-WG] proposed agenda for second interim meeting >> >>>>> >> >>>>> >> >>>>> >> >>>>> At the first interim meeting, we didn't get through our agenda: >> >>>>> >> >>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg01013.html >> >>>>> >> >>>>> Therefore I propose that this time we focus on some unfinished >> >>>>> business, starting with the topic of authentication. I have >> >>>>> reviewed all of the related threads on the list and have come up >> >>>>> with the following >> >>> *rough* agenda. >> >>>>> Your feedback is welcome to improve this (a.k.a. "agenda >> >>>>> bashing") either on the list or during the meeting. >> >>>>> >> >>>>> For logistics information, see here: >> >>>>> >> >>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg01085.html >> >>>>> >> >>>>> ****** >> >>>>> >> >>>>> AGENDA >> >>>>> >> >>>>> Base proposal: draft-ietf-oauth-authentication-01 >> >>>>> >> >>>>> Eran had hoped to push out a new version in time for our meeting, >> >>>>> but hasn't been able to get to it yet. However, I think we can >> >>>>> continue to move forward with discussion. Feedback is welcome on >> >>>>> the general approach, as well as specific open issues. >> >>>>> >> >>>>> Open issues.... >> >>>>> >> >>>>> Issue #1: Request Signing vs. API Signing vs. Message Signing >> >>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg00961.html >> >>>>> >> >>>>> 1a. Seeming consensus for message signing. >> >>>>> >> >>>>> 1b. No consensus yet on message format. >> >>>>> =C2=A0 - JSON and textual key-value seem to be the leading candida= tes. >> >>>>> >> >>>>> 1c. Seeming consensus for multiple/extensible signature algorithms= . >> >>>>> =C2=A0 - HMAC-SHA1 >> >>>>> =C2=A0 - HMAC-SHA256 >> >>>>> =C2=A0 - RSASSA-PKCS1-v1.5-SHA256 >> >>>>> =C2=A0 - PLAIN over SSL/TLS >> >>>>> >> >>>>> But: which of these are Mandatory-to-Implement? >> >>>>> >> >>>>> Issue #2: Include the Normalized Request with the Request? >> >>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg00962.html >> >>>>> >> >>>>> Seeming consensus to not include the normalized request (e.g., >> >>>>> signature string). >> >>>>> >> >>>>> Issue #3: Allow Secrets in Cleartext, or Require Channel Encryptio= n? >> >>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg00963.html >> >>>>> >> >>>>> Seeming consensus that channel encryption is must-implement >> (which >> >>>>> does not necessarily mean must-deploy). >> >>>>> >> >>>>> Issue #4: Authentication Challenges >> >>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg01039.html >> >>>>> >> >>>>> If an authentication (access) request is unacceptable, how does >> >>>>> the server tell the client how it can provide proper credentials >> >>>>> (e.g., by using a different algorithm)? >> >>>>> >> >>>>> Possible other topics: >> >>>>> >> >>>>> - Mutual auth? >> >>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg00935.html >> >>>>> >> >>>>> - Resource authorization? >> >>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg01033.html >> >>>>> >> >>>>> ****** >> >>>>> >> >>>>> /psa >> >>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> OAuth mailing list >> >>>> OAuth@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eve@xmlgrrl.com Wed Feb 3 11:02: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 A2EE43A6827 for ; Wed, 3 Feb 2010 11:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.358 X-Spam-Level: * X-Spam-Status: No, score=1.358 tagged_above=-999 required=5 tests=[AWL=-0.350, 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, 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 lzOFmkGTdTIR for ; Wed, 3 Feb 2010 11:02:01 -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 A5FE228C2AA for ; Wed, 3 Feb 2010 10:53:54 -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 o13IsEDf018027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Feb 2010 10:54:37 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 3 Feb 2010 10:54:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: OAuth WG X-Mailer: Apple Mail (2.1077) Subject: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second 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: Wed, 03 Feb 2010 19:02:02 -0000 Sorry for the delay, and thanks for the push. In scrambling to approve = a passel of scenarios and produce our webinar last week, we got a bit = behind. (By the way, complete recordings are now available. Their = quality is not perfect, but should suffice. Please see = http://kantarainitiative.org/confluence/display/uma/UMA+Explained for = recordings, overview slides, protocol explanation slides, and example = wireframes.) In order to inform the OAuth V2.0 effort, here is some information about = key User-Managed Access (UMA) use cases and needs. The wiki home is at = http://kantarainitiative.org/confluence/display/uma/Home , and the = sidebar on the right has links to all the available materials. The focus of UMA is to externalize authorization decisions currently = performed by OAuth SPs/servers into a fourth distinct entity we call an = "authorization manager" or AM. Protected resources are hosted at = endpoints called "hosts" and the endpoints seeking data/service access = are called "requesters". An application embodying the AM endpoint can = help the "authorizing user" globally manage what otherwise might be a = complicated authorization picture among all the services accessing and = sharing data about her, including letting her dictate policies for = access authorization that the AM enforces. (If you're familiar with = classic access management technology, the AM serves as a policy decision = point and the hosts are policy enforcement points.) An AM provides the = user with the ability to apply discretionary access controls for his/her = resources.=20 The extensive information available about UMA includes a Scenarios and = Use Cases document: = http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+= Cases Here are summaries of two of the group's approved scenarios. Calendaring: Online calendars, whose content is volatile, are valuable = to share on an ongoing/"feed" basis. In somewhat the same fashion that = people today share online calendars selectively with other people, a = user can share a calendar with a vendor for various purposes. Prior to = allowing the access, she might use UMA to require the requester to = assure her they will not misuse or further share her information. = Having authorized access to a particular resource, the user can then = examine all the connections forged to all her shared resources in = similar fashion, from a single console. Personal Loan: A user applies for a loan online, and the loan = application site requires him to provide certain third-party-attested = information, such as his salary, bank account, and credit score. This = information is best hosted directly out of the (several) authoritative = sites for it, but the user is able to package up references to all of it = and point the loan site to the package; the loan site can then become a = requester of each relevant resource. The user can see, from a single = place, whether the information has been successfully received, and can = keep a record of its access. (The webinar wireframes show how this = packaging might be achieved, along with illustrating other potential = parts of the user experience.) UMA currently solves its use cases, in part, with a composition of three = instances of OAuth (along with using XRD metadata and LRDD discovery = methods). The user introduces each host to the AM with so-called = "three-legged" (authn plus web delegation) OAuth as a preface to other = interactions. Each requester later dynamically introduces itself to a = host with the option of using "two-legged" (authn only) OAuth, and then = introduces itself to the AM using two-legged OAuth -- we think of these = as "automated self-registration" of the services. The draft spec can be = found here: = http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol A few key points: - UMA wants to give users an opportunity, not just to set unilateral = policy (how long access is allowed over time, whether the user should be = asked for real-time consent in some fashion when access is attempted, = and so on), but also to set terms which the requester must meet. This = gives users new tools for control, and also enables some interesting = high-value use cases, involving requests for access on the basis of = third-party-attested claims. - There is a conceptual similarity between the UMA and WRAP entities, = but our analysis so far shows it to be shallow in spots. For example, = WRAP's "protected resource" maps fairly well to an UMA "host" (which may = host any number of protected resources), and WRAP's and OAuth's = "client"/"consumer" maps to an UMA "requester". However, it seems that = a WRAP authorization server is assumed to be in the same domain as a = protected resource, allowing for implicit rather than explicit scoping = of resources. The UMA authorization manager and any one host may be in = entirely separate domains, and introductions between them are intended = to be user-driven. Eve On 3 Feb 2010, at 9:34 AM, Eran Hammer-Lahav wrote: > Hi Anthony, >=20 > The problem with this approach is that it hasn't worked (multiple = times) before because no one ever wants to do the work of collecting and = writing the use cases. What we get instead are short cryptic lists and = pointers to edge cases. We have a good grasp on how OAuth 1.0 is used = and its limitations as addressed by the WRAP draft. >=20 > The best use of my time is to continue working on the drafts and = asking technical questions whenever a decision is needed. If and when = someone writes use cases, I will review those and see if they are = supported by the drafts. >=20 > I will leave it up to the chairs to decide how they want to guide the = working group. >=20 > EHL >=20 >> -----Original Message----- >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] >> Sent: Wednesday, February 03, 2010 9:02 AM >> To: Eran Hammer-Lahav; Dick Hardt >> Cc: OAuth WG >> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting >>=20 >> I would tend to agree with Dick based upon the last call and where = that was >> heading. I believe that Eve had some use cases to share around UMA >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Eran Hammer-Lahav >> Sent: Wednesday, February 03, 2010 8:41 AM >> To: Dick Hardt >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >>=20 >> Has anyone gathered and reviewed use cases? I haven't seen much of = that >> showing up on the list. =46rom my experience, asking people for use = cases >> rarely works, unless someone is willing to do the work and collect = them (and >> so far I haven't heard from such volunteer). I much prefer the = process in >> which we produce a technical document based on OAuth 1.0 and the new >> requirements as defined by WRAP, and discuss use cases as a property = of the >> technical attributes of this draft. >>=20 >> Of course, you don't have to agree with me, but that puts the burden = of >> producing use cases documentation on you and others interested in = taking >> that approach. We certainly have room for both, and keep in mind that = my >> token draft is not (yet) a working group item. >>=20 >> The indication I received from many of the active members of this = list is that >> we have a strong desire to show up at Anaheim with two stable drafts. = I think >> we are very close to getting the authentication piece done following = much of >> OAuth 1.0 functionality (only cleaner and better structures), as well = as >> treating bearer tokens as first class citizens. Given that no one has = started a >> discussion about the delegation flows to include, I doubt we will = have a >> stable second draft, but I plan on getting the authentication piece = stable in >> time. >>=20 >> It has also been my experience over the past two years that the = biggest >> challenge is to figure out the authentication piece. The 'go get a = token' piece >> tends to be much easier to agree on. If we get the authentication = draft to a >> stable place, my intention is to leave it there and focus on the = second part >> and come back to it as the delegation requirements become clearer (if >> changes are needed). But at least it gives us something stable to = build upon. >>=20 >> EHL >>=20 >>> -----Original Message----- >>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>> Sent: Wednesday, February 03, 2010 7:02 AM >>> To: Eran Hammer-Lahav >>> Cc: Peter Saint-Andre; OAuth WG >>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >>>=20 >>> Hi Eran >>>=20 >>> I think it is a little early in our phone discussions to get into = technical details. >>> The next step according to the last call was to gather and review = use cases. >>> Without rough consensus on what problem we are solving, your points >>> below (which all do need to be discussed at some point) is just = moving >>> around deck chairs on the Titanic. >>>=20 >>> -- Dick >>>=20 >>> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: >>>=20 >>>> Please add: >>>>=20 >>>> - Discuss Adobe's recent request to allow excluding the host/port >>>> from the >>> signed message. >>>>=20 >>>> - With regards to #4, how should the challenge identify the token = to >>>> be >>> used (realm comes free, do we need another)? >>>>=20 >>>> - Should a single token support multiple signature algorithms? This >>>> has >>> implications as to the information the client has to include with = the >>> request (the algorithm used, etc.). >>>>=20 >>>> - Where should the token structure live? OAuth 1.0 includes two >>>> response >>> parameters (token and token_secret). However, since we are now = moving >>> towards having the algorithm part of the token definition, as well = as >>> duration and other attributes, the server will need to provide this >>> information to the client. This calls for a simple schema (can be = any >>> format but need to agree to consistent names). It is currently part = of >>> the authorization/delegation draft (implicitly), but we should = discuss >>> moving it to the authentication draft since that's where it is used = (the >> authorization draft simply hands those "things" >>> out). >>>>=20 >>>> EHL Eve Maler eve@xmlgrrl.com http://www.xmlgrrl.com/blog From dick.hardt@gmail.com Wed Feb 3 11:02:05 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D1A28C289 for ; Wed, 3 Feb 2010 11:02:05 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+56z3yphnN5 for ; Wed, 3 Feb 2010 11:02:03 -0800 (PST) Received: from mail1.sxip.com (nvg-01-e0.yvr.sxip.com [72.15.146.183]) by core3.amsl.com (Postfix) with ESMTP id 7A42D28C2B4 for ; Wed, 3 Feb 2010 10:54:45 -0800 (PST) Received: from [192.168.1.243] (c-24-17-212-68.hsd1.wa.comcast.net [24.17.212.68]) (authenticated bits=0) by mail1.sxip.com (8.13.8/8.13.8) with ESMTP id o13ItLxx027962 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Feb 2010 10:55:21 -0800 (PST) (envelope-from dick.hardt@gmail.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 3 Feb 2010 10:55:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) X-Scanned-By: MIMEDefang 2.63 on 172.16.6.3 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 19:02:05 -0000 I recall from the call that Peter did ask if there was consensus on the = approach of gathering use cases. There seemed consensus that the WG = might not fully understand the problem and that this made sense. I don't = see that clearly captured in the minutes, hence me communicating to you = what had occurred on the call.=20 FWIW: II had intended my email to be useful, non-confrontational = feedback on your agenda proposal. I am finding your responses to be = abrasive. Have I offended you in some way? If you have suggestions for = what I can do to be more productive in communicating to you, I would = welcome them. -- Dick On 2010-02-03, at 9:59 AM, Eran Hammer-Lahav wrote: > I read the minutes. >=20 > I don't need to be on the call to present my views on how to proceed. = That's not how the IETF operates. I have been expressing my views for = the past year, right here on the list. I didn't see any consensus call = from the chairs about taking this approach (instead of others). >=20 > I also noticed the lack of follow up since the call with any kind of = discussion on use cases. >=20 > I have asked the chairs to provide a place to discuss technical issues = and that is what this second call is about. Unless the chairs decide to = change it. >=20 > EHL >=20 >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Wednesday, February 03, 2010 9:43 AM >> To: Eran Hammer-Lahav >> Cc: Anthony Nadalin; OAuth WG >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >>=20 >> Eran, >>=20 >> Both Tony and I are explaining to you what happened on the call. If = you had >> been on the call, you could have presented your view on how to = proceed >> with the calls. >> While you may have a different opinion on how to proceed (which I am = NOT >> arguing with), arguing with us on what happened on the call seems = pointless. >>=20 >> -- Dick >>=20 >> On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote: >>=20 >>> Hi Anthony, >>>=20 >>> The problem with this approach is that it hasn't worked (multiple = times) >> before because no one ever wants to do the work of collecting and = writing >> the use cases. What we get instead are short cryptic lists and = pointers to >> edge cases. We have a good grasp on how OAuth 1.0 is used and its >> limitations as addressed by the WRAP draft. >>>=20 >>> The best use of my time is to continue working on the drafts and = asking >> technical questions whenever a decision is needed. If and when = someone >> writes use cases, I will review those and see if they are supported = by the >> drafts. >>>=20 >>> I will leave it up to the chairs to decide how they want to guide = the working >> group. >>>=20 >>> EHL >>>=20 >>>> -----Original Message----- >>>> From: Anthony Nadalin [mailto:tonynad@microsoft.com] >>>> Sent: Wednesday, February 03, 2010 9:02 AM >>>> To: Eran Hammer-Lahav; Dick Hardt >>>> Cc: OAuth WG >>>> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting >>>>=20 >>>> I would tend to agree with Dick based upon the last call and where >>>> that was heading. I believe that Eve had some use cases to share >>>> around UMA >>>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf Of Eran Hammer-Lahav >>>> Sent: Wednesday, February 03, 2010 8:41 AM >>>> To: Dick Hardt >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >>>>=20 >>>> Has anyone gathered and reviewed use cases? I haven't seen much of >>>> that showing up on the list. =46rom my experience, asking people = for >>>> use cases rarely works, unless someone is willing to do the work = and >>>> collect them (and so far I haven't heard from such volunteer). I = much >>>> prefer the process in which we produce a technical document based = on >>>> OAuth 1.0 and the new requirements as defined by WRAP, and discuss >>>> use cases as a property of the technical attributes of this draft. >>>>=20 >>>> Of course, you don't have to agree with me, but that puts the = burden >>>> of producing use cases documentation on you and others interested = in >>>> taking that approach. We certainly have room for both, and keep in >>>> mind that my token draft is not (yet) a working group item. >>>>=20 >>>> The indication I received from many of the active members of this >>>> list is that we have a strong desire to show up at Anaheim with two >>>> stable drafts. I think we are very close to getting the >>>> authentication piece done following much of OAuth 1.0 functionality >>>> (only cleaner and better structures), as well as treating bearer >>>> tokens as first class citizens. Given that no one has started a >>>> discussion about the delegation flows to include, I doubt we will >>>> have a stable second draft, but I plan on getting the = authentication piece >> stable in time. >>>>=20 >>>> It has also been my experience over the past two years that the >>>> biggest challenge is to figure out the authentication piece. The = 'go >>>> get a token' piece tends to be much easier to agree on. If we get = the >>>> authentication draft to a stable place, my intention is to leave it >>>> there and focus on the second part and come back to it as the >>>> delegation requirements become clearer (if changes are needed). But = at >> least it gives us something stable to build upon. >>>>=20 >>>> EHL >>>>=20 >>>>> -----Original Message----- >>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>>>> Sent: Wednesday, February 03, 2010 7:02 AM >>>>> To: Eran Hammer-Lahav >>>>> Cc: Peter Saint-Andre; OAuth WG >>>>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >>>>>=20 >>>>> Hi Eran >>>>>=20 >>>>> I think it is a little early in our phone discussions to get into = technical >> details. >>>>> The next step according to the last call was to gather and review = use >> cases. >>>>> Without rough consensus on what problem we are solving, your = points >>>>> below (which all do need to be discussed at some point) is just >>>>> moving around deck chairs on the Titanic. >>>>>=20 >>>>> -- Dick >>>>>=20 >>>>> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: >>>>>=20 >>>>>> Please add: >>>>>>=20 >>>>>> - Discuss Adobe's recent request to allow excluding the host/port >>>>>> from the >>>>> signed message. >>>>>>=20 >>>>>> - With regards to #4, how should the challenge identify the token >>>>>> to be >>>>> used (realm comes free, do we need another)? >>>>>>=20 >>>>>> - Should a single token support multiple signature algorithms? = This >>>>>> has >>>>> implications as to the information the client has to include with >>>>> the request (the algorithm used, etc.). >>>>>>=20 >>>>>> - Where should the token structure live? OAuth 1.0 includes two >>>>>> response >>>>> parameters (token and token_secret). However, since we are now >>>>> moving towards having the algorithm part of the token definition, = as >>>>> well as duration and other attributes, the server will need to >>>>> provide this information to the client. This calls for a simple >>>>> schema (can be any format but need to agree to consistent names). = It >>>>> is currently part of the authorization/delegation draft >>>>> (implicitly), but we should discuss moving it to the = authentication >>>>> draft since that's where it is used (the >>>> authorization draft simply hands those "things" >>>>> out). >>>>>>=20 >>>>>> EHL >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>>> Behalf Of Peter Saint-Andre >>>>>>> Sent: Tuesday, February 02, 2010 9:15 PM >>>>>>> To: OAuth WG >>>>>>> Subject: [OAUTH-WG] proposed agenda for second interim meeting >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>> At the first interim meeting, we didn't get through our agenda: >>>>>>>=20 >>>>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg01013.html >>>>>>>=20 >>>>>>> Therefore I propose that this time we focus on some unfinished >>>>>>> business, starting with the topic of authentication. I have >>>>>>> reviewed all of the related threads on the list and have come up >>>>>>> with the following >>>>> *rough* agenda. >>>>>>> Your feedback is welcome to improve this (a.k.a. "agenda >>>>>>> bashing") either on the list or during the meeting. >>>>>>>=20 >>>>>>> For logistics information, see here: >>>>>>>=20 >>>>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg01085.html >>>>>>>=20 >>>>>>> ****** >>>>>>>=20 >>>>>>> AGENDA >>>>>>>=20 >>>>>>> Base proposal: draft-ietf-oauth-authentication-01 >>>>>>>=20 >>>>>>> Eran had hoped to push out a new version in time for our = meeting, >>>>>>> but hasn't been able to get to it yet. However, I think we can >>>>>>> continue to move forward with discussion. Feedback is welcome on >>>>>>> the general approach, as well as specific open issues. >>>>>>>=20 >>>>>>> Open issues.... >>>>>>>=20 >>>>>>> Issue #1: Request Signing vs. API Signing vs. Message Signing >>>>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg00961.html >>>>>>>=20 >>>>>>> 1a. Seeming consensus for message signing. >>>>>>>=20 >>>>>>> 1b. No consensus yet on message format. >>>>>>> - JSON and textual key-value seem to be the leading candidates. >>>>>>>=20 >>>>>>> 1c. Seeming consensus for multiple/extensible signature = algorithms. >>>>>>> - HMAC-SHA1 >>>>>>> - HMAC-SHA256 >>>>>>> - RSASSA-PKCS1-v1.5-SHA256 >>>>>>> - PLAIN over SSL/TLS >>>>>>>=20 >>>>>>> But: which of these are Mandatory-to-Implement? >>>>>>>=20 >>>>>>> Issue #2: Include the Normalized Request with the Request? >>>>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg00962.html >>>>>>>=20 >>>>>>> Seeming consensus to not include the normalized request (e.g., >>>>>>> signature string). >>>>>>>=20 >>>>>>> Issue #3: Allow Secrets in Cleartext, or Require Channel = Encryption? >>>>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg00963.html >>>>>>>=20 >>>>>>> Seeming consensus that channel encryption is must-implement >> (which >>>>>>> does not necessarily mean must-deploy). >>>>>>>=20 >>>>>>> Issue #4: Authentication Challenges >>>>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg01039.html >>>>>>>=20 >>>>>>> If an authentication (access) request is unacceptable, how does >>>>>>> the server tell the client how it can provide proper credentials >>>>>>> (e.g., by using a different algorithm)? >>>>>>>=20 >>>>>>> Possible other topics: >>>>>>>=20 >>>>>>> - Mutual auth? >>>>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg00935.html >>>>>>>=20 >>>>>>> - Resource authorization? >>>>>>> http://www.ietf.org/mail- >> archive/web/oauth/current/msg01033.html >>>>>>>=20 >>>>>>> ****** >>>>>>>=20 >>>>>>> /psa >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Wed Feb 3 11:19: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 4E4C528C189 for ; Wed, 3 Feb 2010 11:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 xWEcOGBtlWwj for ; Wed, 3 Feb 2010 11:19:36 -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 9AE7F3A6CCB for ; Wed, 3 Feb 2010 11:19:36 -0800 (PST) Received: (qmail 26724 invoked from network); 3 Feb 2010 19:20:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2010 19:20:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 3 Feb 2010 12:19:46 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Wed, 3 Feb 2010 12:19:25 -0700 Thread-Topic: [OAUTH-WG] proposed agenda for second interim meeting Thread-Index: AcqlAm+kKIU+rPFGQ16Z7XWE753KKgAAlRTA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2C32@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 19:19:38 -0000 I did not mean my first reply to you to be abrasive or confrontational, des= pite being told that my work on the drafts is a waste of time ("moving arou= nd deck chairs on the Titanic"). I simply disagreed with your view that it = is too early to dedicate the next call to technical details. I actually too= k the time to articulate an alternative way of moving forward that is more = consistent with my experience here for the past year. It was your later comments (educating me about what took place on that call= , which assumed I didn't bother to read the minutes or listen to the audio)= that I didn't appreciate. Any consensus call must be made on the list and not just on the call or in = a meeting because the list is the only place everyone is guaranteed equal p= articipation. There is nothing more important in the IETF process than cons= ensus calls and I take them very seriously. EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Wednesday, February 03, 2010 10:55 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >=20 > I recall from the call that Peter did ask if there was consensus on the > approach of gathering use cases. There seemed consensus that the WG > might not fully understand the problem and that this made sense. I don't = see > that clearly captured in the minutes, hence me communicating to you what > had occurred on the call. >=20 > FWIW: II had intended my email to be useful, non-confrontational feedback > on your agenda proposal. I am finding your responses to be abrasive. Have= I > offended you in some way? If you have suggestions for what I can do to be > more productive in communicating to you, I would welcome them. >=20 > -- Dick >=20 >=20 > On 2010-02-03, at 9:59 AM, Eran Hammer-Lahav wrote: >=20 > > I read the minutes. > > > > I don't need to be on the call to present my views on how to proceed. > That's not how the IETF operates. I have been expressing my views for the > past year, right here on the list. I didn't see any consensus call from t= he chairs > about taking this approach (instead of others). > > > > I also noticed the lack of follow up since the call with any kind of di= scussion > on use cases. > > > > I have asked the chairs to provide a place to discuss technical issues = and > that is what this second call is about. Unless the chairs decide to chang= e it. > > > > EHL > > > >> -----Original Message----- > >> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >> Sent: Wednesday, February 03, 2010 9:43 AM > >> To: Eran Hammer-Lahav > >> Cc: Anthony Nadalin; OAuth WG > >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting > >> > >> Eran, > >> > >> Both Tony and I are explaining to you what happened on the call. If > >> you had been on the call, you could have presented your view on how > >> to proceed with the calls. > >> While you may have a different opinion on how to proceed (which I am > >> NOT arguing with), arguing with us on what happened on the call seems > pointless. > >> > >> -- Dick > >> > >> On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote: > >> > >>> Hi Anthony, > >>> > >>> The problem with this approach is that it hasn't worked (multiple > >>> times) > >> before because no one ever wants to do the work of collecting and > >> writing the use cases. What we get instead are short cryptic lists > >> and pointers to edge cases. We have a good grasp on how OAuth 1.0 is > >> used and its limitations as addressed by the WRAP draft. > >>> > >>> The best use of my time is to continue working on the drafts and > >>> asking > >> technical questions whenever a decision is needed. If and when > >> someone writes use cases, I will review those and see if they are > >> supported by the drafts. > >>> > >>> I will leave it up to the chairs to decide how they want to guide > >>> the working > >> group. > >>> > >>> EHL > >>> > >>>> -----Original Message----- > >>>> From: Anthony Nadalin [mailto:tonynad@microsoft.com] > >>>> Sent: Wednesday, February 03, 2010 9:02 AM > >>>> To: Eran Hammer-Lahav; Dick Hardt > >>>> Cc: OAuth WG > >>>> Subject: RE: [OAUTH-WG] proposed agenda for second interim > meeting > >>>> > >>>> I would tend to agree with Dick based upon the last call and where > >>>> that was heading. I believe that Eve had some use cases to share > >>>> around UMA > >>>> > >>>> -----Original Message----- > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>> Behalf Of Eran Hammer-Lahav > >>>> Sent: Wednesday, February 03, 2010 8:41 AM > >>>> To: Dick Hardt > >>>> Cc: OAuth WG > >>>> Subject: Re: [OAUTH-WG] proposed agenda for second interim > meeting > >>>> > >>>> Has anyone gathered and reviewed use cases? I haven't seen much of > >>>> that showing up on the list. From my experience, asking people for > >>>> use cases rarely works, unless someone is willing to do the work > >>>> and collect them (and so far I haven't heard from such volunteer). > >>>> I much prefer the process in which we produce a technical document > >>>> based on OAuth 1.0 and the new requirements as defined by WRAP, > and > >>>> discuss use cases as a property of the technical attributes of this = draft. > >>>> > >>>> Of course, you don't have to agree with me, but that puts the > >>>> burden of producing use cases documentation on you and others > >>>> interested in taking that approach. We certainly have room for > >>>> both, and keep in mind that my token draft is not (yet) a working gr= oup > item. > >>>> > >>>> The indication I received from many of the active members of this > >>>> list is that we have a strong desire to show up at Anaheim with two > >>>> stable drafts. I think we are very close to getting the > >>>> authentication piece done following much of OAuth 1.0 functionality > >>>> (only cleaner and better structures), as well as treating bearer > >>>> tokens as first class citizens. Given that no one has started a > >>>> discussion about the delegation flows to include, I doubt we will > >>>> have a stable second draft, but I plan on getting the > >>>> authentication piece > >> stable in time. > >>>> > >>>> It has also been my experience over the past two years that the > >>>> biggest challenge is to figure out the authentication piece. The > >>>> 'go get a token' piece tends to be much easier to agree on. If we > >>>> get the authentication draft to a stable place, my intention is to > >>>> leave it there and focus on the second part and come back to it as > >>>> the delegation requirements become clearer (if changes are needed). > >>>> But at > >> least it gives us something stable to build upon. > >>>> > >>>> EHL > >>>> > >>>>> -----Original Message----- > >>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >>>>> Sent: Wednesday, February 03, 2010 7:02 AM > >>>>> To: Eran Hammer-Lahav > >>>>> Cc: Peter Saint-Andre; OAuth WG > >>>>> Subject: Re: [OAUTH-WG] proposed agenda for second interim > meeting > >>>>> > >>>>> Hi Eran > >>>>> > >>>>> I think it is a little early in our phone discussions to get into > >>>>> technical > >> details. > >>>>> The next step according to the last call was to gather and review > >>>>> use > >> cases. > >>>>> Without rough consensus on what problem we are solving, your > >>>>> points below (which all do need to be discussed at some point) is > >>>>> just moving around deck chairs on the Titanic. > >>>>> > >>>>> -- Dick > >>>>> > >>>>> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: > >>>>> > >>>>>> Please add: > >>>>>> > >>>>>> - Discuss Adobe's recent request to allow excluding the host/port > >>>>>> from the > >>>>> signed message. > >>>>>> > >>>>>> - With regards to #4, how should the challenge identify the token > >>>>>> to be > >>>>> used (realm comes free, do we need another)? > >>>>>> > >>>>>> - Should a single token support multiple signature algorithms? > >>>>>> This has > >>>>> implications as to the information the client has to include with > >>>>> the request (the algorithm used, etc.). > >>>>>> > >>>>>> - Where should the token structure live? OAuth 1.0 includes two > >>>>>> response > >>>>> parameters (token and token_secret). However, since we are now > >>>>> moving towards having the algorithm part of the token definition, > >>>>> as well as duration and other attributes, the server will need to > >>>>> provide this information to the client. This calls for a simple > >>>>> schema (can be any format but need to agree to consistent names). > >>>>> It is currently part of the authorization/delegation draft > >>>>> (implicitly), but we should discuss moving it to the > >>>>> authentication draft since that's where it is used (the > >>>> authorization draft simply hands those "things" > >>>>> out). > >>>>>> > >>>>>> EHL > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > On > >>>>>>> Behalf Of Peter Saint-Andre > >>>>>>> Sent: Tuesday, February 02, 2010 9:15 PM > >>>>>>> To: OAuth WG > >>>>>>> Subject: [OAUTH-WG] proposed agenda for second interim > meeting > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> At the first interim meeting, we didn't get through our agenda: > >>>>>>> > >>>>>>> http://www.ietf.org/mail- > >> archive/web/oauth/current/msg01013.html > >>>>>>> > >>>>>>> Therefore I propose that this time we focus on some unfinished > >>>>>>> business, starting with the topic of authentication. I have > >>>>>>> reviewed all of the related threads on the list and have come up > >>>>>>> with the following > >>>>> *rough* agenda. > >>>>>>> Your feedback is welcome to improve this (a.k.a. "agenda > >>>>>>> bashing") either on the list or during the meeting. > >>>>>>> > >>>>>>> For logistics information, see here: > >>>>>>> > >>>>>>> http://www.ietf.org/mail- > >> archive/web/oauth/current/msg01085.html > >>>>>>> > >>>>>>> ****** > >>>>>>> > >>>>>>> AGENDA > >>>>>>> > >>>>>>> Base proposal: draft-ietf-oauth-authentication-01 > >>>>>>> > >>>>>>> Eran had hoped to push out a new version in time for our > >>>>>>> meeting, but hasn't been able to get to it yet. However, I think > >>>>>>> we can continue to move forward with discussion. Feedback is > >>>>>>> welcome on the general approach, as well as specific open issues. > >>>>>>> > >>>>>>> Open issues.... > >>>>>>> > >>>>>>> Issue #1: Request Signing vs. API Signing vs. Message Signing > >>>>>>> http://www.ietf.org/mail- > >> archive/web/oauth/current/msg00961.html > >>>>>>> > >>>>>>> 1a. Seeming consensus for message signing. > >>>>>>> > >>>>>>> 1b. No consensus yet on message format. > >>>>>>> - JSON and textual key-value seem to be the leading candidates. > >>>>>>> > >>>>>>> 1c. Seeming consensus for multiple/extensible signature > algorithms. > >>>>>>> - HMAC-SHA1 > >>>>>>> - HMAC-SHA256 > >>>>>>> - RSASSA-PKCS1-v1.5-SHA256 > >>>>>>> - PLAIN over SSL/TLS > >>>>>>> > >>>>>>> But: which of these are Mandatory-to-Implement? > >>>>>>> > >>>>>>> Issue #2: Include the Normalized Request with the Request? > >>>>>>> http://www.ietf.org/mail- > >> archive/web/oauth/current/msg00962.html > >>>>>>> > >>>>>>> Seeming consensus to not include the normalized request (e.g., > >>>>>>> signature string). > >>>>>>> > >>>>>>> Issue #3: Allow Secrets in Cleartext, or Require Channel Encrypti= on? > >>>>>>> http://www.ietf.org/mail- > >> archive/web/oauth/current/msg00963.html > >>>>>>> > >>>>>>> Seeming consensus that channel encryption is must-implement > >> (which > >>>>>>> does not necessarily mean must-deploy). > >>>>>>> > >>>>>>> Issue #4: Authentication Challenges > >>>>>>> http://www.ietf.org/mail- > >> archive/web/oauth/current/msg01039.html > >>>>>>> > >>>>>>> If an authentication (access) request is unacceptable, how does > >>>>>>> the server tell the client how it can provide proper credentials > >>>>>>> (e.g., by using a different algorithm)? > >>>>>>> > >>>>>>> Possible other topics: > >>>>>>> > >>>>>>> - Mutual auth? > >>>>>>> http://www.ietf.org/mail- > >> archive/web/oauth/current/msg00935.html > >>>>>>> > >>>>>>> - Resource authorization? > >>>>>>> http://www.ietf.org/mail- > >> archive/web/oauth/current/msg01033.html > >>>>>>> > >>>>>>> ****** > >>>>>>> > >>>>>>> /psa > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Wed Feb 3 11:21: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 169643A6CC6 for ; Wed, 3 Feb 2010 11:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 aCNnVy-xH6ox for ; Wed, 3 Feb 2010 11:21:28 -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 5E5F03A6CC7 for ; Wed, 3 Feb 2010 11:21:28 -0800 (PST) Received: (qmail 18810 invoked from network); 3 Feb 2010 19:22:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Feb 2010 19:22:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 3 Feb 2010 12:22:01 -0700 From: Eran Hammer-Lahav To: Eran Hammer-Lahav , Dick Hardt Date: Wed, 3 Feb 2010 12:21:41 -0700 Thread-Topic: [OAUTH-WG] proposed agenda for second interim meeting Thread-Index: AcqlAm+kKIU+rPFGQ16Z7XWE753KKgAAlRTAAABPnIA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2C36@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2C32@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2C32@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 19:21:29 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Wednesday, February 03, 2010 11:19 AM > To: Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >=20 > I did not mean my first reply to you to be abrasive or confrontational INSERT: and I apologize if it came off that way. EHL =20 From dick.hardt@gmail.com Wed Feb 3 11:45: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 6C49B3A6CD2 for ; Wed, 3 Feb 2010 11:45: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 AS3okMDzEMWG for ; Wed, 3 Feb 2010 11:45:31 -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 ACEE33A6CC4 for ; Wed, 3 Feb 2010 11:45:31 -0800 (PST) Received: by pxi16 with SMTP id 16so662730pxi.29 for ; Wed, 03 Feb 2010 11:46:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=RmYZmDn+nAP2lhhjclY2hhwwYkzwSVgjFJ8CbtA6Xa8=; b=v3dTjHpmquK/HOewfzcWzAiqEMTZNFjR+et5VzHP1tJV84KtyJvZbpazzbhQNKHz8t u1zk0PbG+8+Cga+Ui9cDWR6w76VYpB7ZvcPcZlKwpJJeNH+v2iH8LIjHL/XEtxbeqYLU 1ZL16Op5vdVlIgEv6kw6VzsbFO+ZXh5ARX6vo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=fSt6VV+FhM7rHhLvlfhiL4D/pvf/S3EX4qe17RkMXGmI8xycM6h4zwj1MW79Cf33Y/ XU1DmP7NFGFfUYJOG+R0oifeHlZcRrvNLNdUonLSW+7T0jgWgaq5FyumpAXsF+TiUfxl XTV9D389HbnvDxN009bDdvfMXznbQNFiCbGsA= Received: by 10.142.56.7 with SMTP id e7mr33069wfa.25.1265226372389; Wed, 03 Feb 2010 11:46:12 -0800 (PST) Received: from ?192.168.1.236? (c-24-17-212-68.hsd1.wa.comcast.net [24.17.212.68]) by mx.google.com with ESMTPS id 20sm4089123pzk.1.2010.02.03.11.46.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 11:46:10 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2C32@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 3 Feb 2010 11:46:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <652E65C5-CA92-41AF-B6A1-85A6AC84F54A@gmail.com> References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2C32@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 19:45:32 -0000 On 2010-02-03, at 11:19 AM, Eran Hammer-Lahav wrote: > I did not mean my first reply to you to be abrasive or = confrontational, despite being told that my work on the drafts is a = waste of time ("moving around deck chairs on the Titanic"). I and many others appreciate your work. That was not my intent. Wanting = to discuss technical details when there does not seem to be consensus on = the problem we are solving was my Titanic reference. >=20 > Any consensus call must be made on the list and not just on the call = or in a meeting because the list is the only place everyone is = guaranteed equal participation. There is nothing more important in the = IETF process than consensus calls and I take them very seriously. Thanks for the clarification.= From dick.hardt@gmail.com Wed Feb 3 11:45:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317B53A6CD2 for ; Wed, 3 Feb 2010 11:45:33 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxtQGSs6nHgY for ; Wed, 3 Feb 2010 11:45:32 -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 8B1263A6CC4 for ; Wed, 3 Feb 2010 11:45:32 -0800 (PST) Received: by mail-px0-f186.google.com with SMTP id 16so662730pxi.29 for ; Wed, 03 Feb 2010 11:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=GIFVAZTku0Ruqr8k0CoWX44PPmK2TPR5LtttiKdBcAs=; b=eHjqSeXDiKYc2u7Dc4pWjTOOZsvK8ByKWfRc/yJubFTHoGR5Z0vduhpF9Ul40CoVbH eGMMUGn68Rfax2LkT4IjmT5sgfCVW9YCCz1t2K9z9FIb6C8r5/KY2HLhgXf6ISMWGKvS 12lY4/85MLikjiRYbDYw9Q4v+NRoSC8BCVJmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=fEML1mLmIlAZBYtVWGebNFxpWthFqmFJ2lyPdBVOjgo14eF3/EJke1ch5lVmUUI7R3 kZEW35F1Wk7pcQUjWe8uHZjBuzE0xKUQwa5hD55CBaP37MPAg31R7RwGkuWQqwS1TieC hr/mn4StjhNRL4SD1BAI3JgX+ZHCZVhkq5jls= Received: by 10.114.5.13 with SMTP id 13mr14150wae.222.1265226376057; Wed, 03 Feb 2010 11:46:16 -0800 (PST) Received: from ?192.168.1.236? (c-24-17-212-68.hsd1.wa.comcast.net [24.17.212.68]) by mx.google.com with ESMTPS id 20sm4089123pzk.1.2010.02.03.11.46.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 11:46:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2C36@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 3 Feb 2010 11:46:12 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2C32@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2C36@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 19:45:33 -0000 On 2010-02-03, at 11:21 AM, Eran Hammer-Lahav wrote: >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Eran Hammer-Lahav >> Sent: Wednesday, February 03, 2010 11:19 AM >> To: Dick Hardt >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >> >> I did not mean my first reply to you to be abrasive or confrontational > > INSERT: and I apologize if it came off that way. Thanks. All good on my side. -- Dick From stpeter@stpeter.im Wed Feb 3 12:00:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0EE928C1BB for ; Wed, 3 Feb 2010 12:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=-0.133, 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 iA2ze4E6D+FI for ; Wed, 3 Feb 2010 12:00:35 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9FE2D28C194 for ; Wed, 3 Feb 2010 12:00:24 -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 82A7740332 for ; Wed, 3 Feb 2010 13:01:07 -0700 (MST) Message-ID: <4B69D601.3080209@stpeter.im> Date: Wed, 03 Feb 2010 13:01:05 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2C32@P3PW5EX1MB01.EX1.SECURESERVER.NET> <652E65C5-CA92-41AF-B6A1-85A6AC84F54A@gmail.com> In-Reply-To: <652E65C5-CA92-41AF-B6A1-85A6AC84F54A@gmail.com> 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="------------ms030003040306050704090908" Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 20:00:36 -0000 This is a cryptographically signed message in MIME format. --------------ms030003040306050704090908 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/3/10 12:46 PM, Dick Hardt wrote: > Wanting to discuss technical details when there does not seem to be > consensus on the problem we are solving was my Titanic reference. We have two dangers here: 1. The Scylla of designing technologies before we fully understand the problem space and its associated requirements. 2. The Charybdis of discussing the problem space and its associated requirements but never designing any technologies. We are attempting to steer a safe course between these two dangers. Although I tend to the side of those who fear Scylla more than Charybdis, in my opinion (not consensus that I am declaring as co-chair) we have enough sense of the problem space regarding authentication that we can at least have a productive discussion about draft-ietf-oauth-authentication-01 at tomorrow's interim meeting. However, in parallel I think we need to keep sifting through various use cases, and Blaine's stub of a feature matrix is a good first step that needs more attention before the interim meeting we'll hold two weeks from tomorrow (February 18). Remember, these interim meetings are intended to air open issues and get us closer to agreement on problems, terminology, architecture, use cases, requirements, and possible technical solutions, all as a way of preparing for the in-person meeting in Anaheim. IMHO we need to keep working in several directions at once, so let's keep building out our wiki pages and updating the relevant Internet-Drafts and sifting through use cases and working through open issues on this list. Perhaps that's not a perfect process, but I think it's the best we can do for now. If you disagree, feel free to do so on list or off. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030003040306050704090908 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 hvcNAQkFMQ8XDTEwMDIwMzIwMDEwNVowIwYJKoZIhvcNAQkEMRYEFIA1VuR7GVy18UKc6DG0 /ezL1WFcMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEATafK/HNqPUSfcCwUisFb8pfNZUFiHfyxTxGyXFr3 sBg4ZIXjVRGQV7yMXqlPlnbboUfSW+Xe+jIr3GcBCQljE+EmqpdZF/jKEY/0JM1KKJNsBCC1 H2MheRtoY3DMd4l7ni4tYeK0hvcFzwuHF9E0pfBcadOroVuUoMm13MHTRkbEg4TWxYvuf77i 1ZrccIMwXKHo7cRrZPSKgnQxf2vROMFcgAlu6Jh+6FdwXZyqLpaM0LpU4FUJ4asHK652zDQY Is8VNqHkb/gaU9ngAavnBvX1qA1cprNnUUfYQ+TzgGMtdX6pAVrRtUlb/5CuWVZaJxqlI3Hh eP8O/TBJGZvYRgAAAAAAAA== --------------ms030003040306050704090908-- From dick.hardt@gmail.com Wed Feb 3 14:26: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 B8AA93A6984 for ; Wed, 3 Feb 2010 14:26:08 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-6FTeeVQ33S for ; Wed, 3 Feb 2010 14:26:07 -0800 (PST) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by core3.amsl.com (Postfix) with ESMTP id DDB913A695C for ; Wed, 3 Feb 2010 14:26:07 -0800 (PST) Received: by pzk5 with SMTP id 5so3052386pzk.29 for ; Wed, 03 Feb 2010 14:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=sHe/1mNUkhHKCdn+JajAxmjPa86uUKfBN1oAUILcvto=; b=i3E4X0REIXCycDbhc9u7qoljbCFEbehe4IDm3PC0wQMSXQ71qtb3O/wY/B2IkiLVCJ 4rR+iOU8C/nFy6zFP3FuW0MioCcytAuc5h4RQpdA1J99JGRev6dxoA1/oiUHH1J8sknT TKF4gYQJFBhJSoibw0dGRc5YUiQ+hI3ad0+As= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=omlL1adyB1VysOC9Rx2E5Rm4mqKgPJp0Id+k2+kAvNsZl7QtegQSFxTdQVsaEQ7UUp brc/wnAbcH+QR7xlQh8tfO2TS1NpiJWTvJiToz1gY4INHip2LZuZ2L98P5cWazKlWT9t HgW1/AzrqrqYqaUYwgtoGwPSzDhU2TARJYuc8= Received: by 10.142.8.38 with SMTP id 38mr140054wfh.125.1265236008824; Wed, 03 Feb 2010 14:26:48 -0800 (PST) Received: from ?192.168.1.236? (c-24-17-212-68.hsd1.wa.comcast.net [24.17.212.68]) by mx.google.com with ESMTPS id 20sm4228085pzk.5.2010.02.03.14.26.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 14:26:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <4B69D601.3080209@stpeter.im> Date: Wed, 3 Feb 2010 14:26:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92C608F0-AADF-4A24-AD92-D226B3C8B13B@gmail.com> References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2C32@P3PW5EX1MB01.EX1.SECURESERVER.NET> <652E65C5-CA92-41AF-B6A1-85A6AC84F54A@gmail.com> <4B69D601.3080209@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1077) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] proposed agenda for second 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: Wed, 03 Feb 2010 22:26:08 -0000 On 2010-02-03, at 12:01 PM, Peter Saint-Andre wrote: > >=20 > On 2/3/10 12:46 PM, Dick Hardt wrote: >=20 >> Wanting to discuss technical details when there does not seem to be >> consensus on the problem we are solving was my Titanic reference. >=20 > Remember, these interim meetings are > intended to air open issues and get us closer to agreement on = problems, > terminology, architecture, use cases, requirements, and possible > technical solutions, all as a way of preparing for the in-person = meeting > in Anaheim. That was what I thought the calls were for, which is why I did not think = Eran's desire to add discussion of a specific technical issue was going = to be well received. There are a number of us that are new to the WG and = we likely will make little progress until we are all relatively on the = same page on what problem(s) we are solving. I certainly hope we don't = need to spend much time on these topics, but some time will be = invaluable in my opinion. Speaking for myself, I am still confused why the spec has been broken = into two parts and what is intended in the Authentication document. I am = just now starting to try and grok what the UMA people want to solve. -- Dick From James.H.Manger@team.telstra.com Wed Feb 3 15:22: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 7D21B28C0CF for ; Wed, 3 Feb 2010 15:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_56=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 2f4trBo6YMgg for ; Wed, 3 Feb 2010 15:22:29 -0800 (PST) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id 64F1328B23E for ; Wed, 3 Feb 2010 15:22:29 -0800 (PST) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbi.ntcif.telstra.com.au with ESMTP; 04 Feb 2010 10:23:12 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id B8898FF83; Thu, 4 Feb 2010 10:23:11 +1100 (EST) Received: from wsmsg3707.srv.dir.telstra.com (wsmsg3707.srv.dir.telstra.com [172.49.40.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA03746; Thu, 4 Feb 2010 10:23:11 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 4 Feb 2010 09:23:10 +1000 From: "Manger, James H" To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Thu, 4 Feb 2010 09:23:08 +1000 Thread-Topic: Token Access Authentication Scheme Draft Thread-Index: Acp3Fy41mhoVRFEVTsOZ4fl/+l3K7wAKRu2wC2slyvAAC8H2MA== Message-ID: <255B9BB34FB7D647A506DC292726F6E112503E45AF@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112503E4234@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 23:22:30 -0000 PiBUaGUgcmVhc29uIHdoeSBpdCBtYWtlcyBsaXR0bGUgc2Vuc2UgdG8gaGF2ZSBkaWZmZXJlbnQg c2NoZW1lcyBmb3INCj4gZGlmZmVyZW50IHR5cGVzIG9mIHRva2VucyBpcyB0aGF0IGl0IGlzIG5v dCB0aGUgcHJvdGVjdGVkIHJlc291cmNlJ3MNCj4gam9iIHRvIHNheSB3aGljaCBhbGdvcml0aG0g c2hvdWxkIGJlIHVzZWQsIGJ1dCB0aGUgc2VydmVyIHdoZW4gaXNzdWluZw0KPiB0aGUgdG9rZW4g Zm9yIHRoYXQgcmVzb3VyY2UuIFRoZSBkcmFmdCBkaWQgYSBwb29yIGpvYiBhdCBzZXBhcmF0aW5n IHRoZQ0KPiByb2xlIG9mIHRoZSBzZXJ2ZXIgaXNzdWluZyB0aGUgdG9rZW5zIGZyb20gdGhlIHJv bGUgb2YgdGhlIHNlcnZlcg0KPiBwcm92aWRpbmcgYWNjZXNzIHRvIHJlc291cmNlcy4NCg0KDQpJ dCBpcyBub3QgdGhlIHJvbGUgb2YgYSBzcGVjIGZvciBhbiBIVFRQIGF1dGhlbnRpY2F0aW9uIG1l Y2hhbmlzbSB0byBtYWtlIGFzc3VtcHRpb25zIGFib3V0IGhvdyBjcmVkZW50aWFscyBhcmUgaXNz dWVkLCBvciBhc3N1bXB0aW9ucyBhYm91dCB3aGF0IGFkZGl0aW9uYWwgYXV0aGVudGljYXRpb24g bWVjaGFuaXNtcyBtaWdodCBiZSBzdXBwb3J0ZWQgYnkgYW55IHBhcnRpY3VsYXIgc2VydmVyLiBJ IGhvcGUgYSBIVFRQIHJlcXVlc3Qtc2lnbmluZyBzcGVjIGRvZXMgbm90IG5lZWQgdG8gYXNzdW1l IHRoYXQgYSBzZXBhcmF0ZSBzZWN1cml0eSBzZXJ2ZXIgaXMgaW52b2x2ZWQgdG8gZG8gYWxsIHBv c3NpYmxlIG1lY2hhbmlzbSBuZWdvdGlhdGlvbi4NCg0KDQpJIGFtIHZlcnkgaGFwcHkgZm9yIGEg c2VjdXJpdHkgc2VydmVyIHRvIHNheToNCiAgZWcgInVzZSB0aGlzIHRva2VuK3NlY3JldCB3aXRo IEhNQUMtU0hBMjU2IGF0IGh0dHA6Ly9hcGkuZXhhbXBsZS5vcmcvIGZvciAxMCBtaW51dGVzIg0K QSBzZWN1cml0eSBzZXJ2ZXIgbWF5IHdhbnQgdG8gYmUgYSBsaXR0bGUgbGVzcyBzcGVjaWZpYzoN CiAgZWcgInVzZSB0aGlzIHRva2VuK3NlY3JldCB3aXRoIGFueSBNQUMgYWxnb3JpdGhtIGF0IGh0 dHA6Ly8qLmV4YW1wbGUuY29tLyINCk9yDQogIGVnICJ1c2UgdGhpcyB0b2tlbitzZWNyZXQgd2l0 aCB0aGUgT0F1dGggTUFDIGFsZ3Mgb3IgZHJhZnQtb2l3YS1odHRwLW11dHVhbGF1dGggYXQgeHl6 Ii4NCg0KQSBzdGF0ZW1lbnQgZnJvbSBhIHNlY3VyaXR5IHNlcnZlciBiaW5kaW5nIGEgdG9rZW4r c2VjcmV0IHRvDQogICIxIG9yIG1vcmUgJ21lY2hhbmlzbXMnIG9mIHRoZSAnVG9rZW4nIHNjaGVt ZSINCmlzIG5vIGVhc2llciB0aGFuIGEgc3RhdGVtZW50IGJpbmRpbmcgdGhlbiB0bw0KICAiMSBv ciBtb3JlICdzY2hlbWVzJyIsDQpCaW5kaW5nIHRvICdtZWNoYW5pc21zJyBvZiB0aGUgJ1Rva2Vu JyBzY2hlbWUgaXMgc2lnbmlmaWNhbnRseSB3b3JzZSBhcyBpdCBleGNsdWRlIGEgd2hvbGUgc3dh ZyBvZiBjdXJyZW50IGFuZCBmdXR1cmUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyB0aGF0IGFy ZSBub3Qgd3JpdHRlbiB3aXRoIE9BdXRoIHNwZWNpZmljYWxseSBpbiBtaW5kLg0KDQoNCi0tDQpK YW1lcyBNYW5nZXINCg== From eran@hueniverse.com Wed Feb 3 15:32:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3393A68E1 for ; Wed, 3 Feb 2010 15:32:43 -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.152, BAYES_00=-2.599, J_CHICKENPOX_56=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 reXk2lgpw32w for ; Wed, 3 Feb 2010 15:32:42 -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 8CBB63A69AB for ; Wed, 3 Feb 2010 15:32:42 -0800 (PST) Received: (qmail 5406 invoked from network); 3 Feb 2010 23:33:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2010 23:33:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 3 Feb 2010 16:33:10 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "OAuth WG (oauth@ietf.org)" Date: Wed, 3 Feb 2010 16:32:57 -0700 Thread-Topic: Token Access Authentication Scheme Draft Thread-Index: Acp3Fy41mhoVRFEVTsOZ4fl/+l3K7wAKRu2wC2slyvAAC8H2MAADEOTQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2D3C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112503E4234@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112503E45AF@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112503E45AF@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 23:32:43 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hbmdlciwgSmFtZXMgSCBb bWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb21dDQo+IFNlbnQ6IFdlZG5lc2Rh eSwgRmVicnVhcnkgMDMsIDIwMTAgMzoyMyBQTQ0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXY7IE9B dXRoIFdHIChvYXV0aEBpZXRmLm9yZykNCj4gU3ViamVjdDogUkU6IFRva2VuIEFjY2VzcyBBdXRo ZW50aWNhdGlvbiBTY2hlbWUgRHJhZnQNCj4gDQo+ID4gVGhlIHJlYXNvbiB3aHkgaXQgbWFrZXMg bGl0dGxlIHNlbnNlIHRvIGhhdmUgZGlmZmVyZW50IHNjaGVtZXMgZm9yDQo+ID4gZGlmZmVyZW50 IHR5cGVzIG9mIHRva2VucyBpcyB0aGF0IGl0IGlzIG5vdCB0aGUgcHJvdGVjdGVkIHJlc291cmNl J3MNCj4gPiBqb2IgdG8gc2F5IHdoaWNoIGFsZ29yaXRobSBzaG91bGQgYmUgdXNlZCwgYnV0IHRo ZSBzZXJ2ZXIgd2hlbiBpc3N1aW5nDQo+ID4gdGhlIHRva2VuIGZvciB0aGF0IHJlc291cmNlLiBU aGUgZHJhZnQgZGlkIGEgcG9vciBqb2IgYXQgc2VwYXJhdGluZw0KPiA+IHRoZSByb2xlIG9mIHRo ZSBzZXJ2ZXIgaXNzdWluZyB0aGUgdG9rZW5zIGZyb20gdGhlIHJvbGUgb2YgdGhlIHNlcnZlcg0K PiA+IHByb3ZpZGluZyBhY2Nlc3MgdG8gcmVzb3VyY2VzLg0KPiANCj4gDQo+IEl0IGlzIG5vdCB0 aGUgcm9sZSBvZiBhIHNwZWMgZm9yIGFuIEhUVFAgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIHRv IG1ha2UNCj4gYXNzdW1wdGlvbnMgYWJvdXQgaG93IGNyZWRlbnRpYWxzIGFyZSBpc3N1ZWQsIG9y IGFzc3VtcHRpb25zIGFib3V0IHdoYXQNCj4gYWRkaXRpb25hbCBhdXRoZW50aWNhdGlvbiBtZWNo YW5pc21zIG1pZ2h0IGJlIHN1cHBvcnRlZCBieSBhbnkgcGFydGljdWxhcg0KPiBzZXJ2ZXIuDQoN Ckl0IGRvZXNuJ3QuDQoNCj4gSSBhbSB2ZXJ5IGhhcHB5IGZvciBhIHNlY3VyaXR5IHNlcnZlciB0 byBzYXk6DQo+ICAgZWcgInVzZSB0aGlzIHRva2VuK3NlY3JldCB3aXRoIEhNQUMtU0hBMjU2IGF0 IGh0dHA6Ly9hcGkuZXhhbXBsZS5vcmcvDQo+IGZvciAxMCBtaW51dGVzIg0KPiBBIHNlY3VyaXR5 IHNlcnZlciBtYXkgd2FudCB0byBiZSBhIGxpdHRsZSBsZXNzIHNwZWNpZmljOg0KPiAgIGVnICJ1 c2UgdGhpcyB0b2tlbitzZWNyZXQgd2l0aCBhbnkgTUFDIGFsZ29yaXRobSBhdA0KPiBodHRwOi8v Ki5leGFtcGxlLmNvbS8iDQo+IE9yDQo+ICAgZWcgInVzZSB0aGlzIHRva2VuK3NlY3JldCB3aXRo IHRoZSBPQXV0aCBNQUMgYWxncyBvciBkcmFmdC1vaXdhLWh0dHAtDQo+IG11dHVhbGF1dGggYXQg eHl6Ii4NCg0KVGhpcyBpcyBleGFjdGx5IHdoYXQgdGhlIGN1cnJlbnQgZHJhZnQgcHJvcG9zZXMs IGFzIGxvbmcgYXMgdGhlc2Ugc3RhdGVtZW50cyBhcmUgInNhaWQiIGJ5IHRoZSBzZXJ2ZXIgd2hl biBpc3N1aW5nIHRoZSBjcmVkZW50aWFscywgbm90IHdoZW4gc2VuZGluZyBhIDQwMSByZXNwb25z ZS4NCg0KQWxsIHRoZSBzcGVjIGlzIGRvaW5nIGluIHRoYXQgcmVnYXJkIGlzIGdpdmluZyB0aGVz ZSBzdGF0ZW1lbnRzIGEgY29tbW9uIGxhbmd1YWdlIHRvIGVuYWJsZSBpbnRlcm9wIGZvciBhIGZl dyBtZXRob2RzLg0KIA0KRUhMDQoNCg== From James.H.Manger@team.telstra.com Wed Feb 3 17:02: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 615233A6928 for ; Wed, 3 Feb 2010 17:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 KkKyXkecHMzX for ; Wed, 3 Feb 2010 17:02:07 -0800 (PST) Received: from mailipao.ntcif.telstra.com.au (mailipao.ntcif.telstra.com.au [202.12.233.27]) by core3.amsl.com (Postfix) with ESMTP id A82173A690C for ; Wed, 3 Feb 2010 17:02:06 -0800 (PST) Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipai.ntcif.telstra.com.au with ESMTP; 04 Feb 2010 12:02:50 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 86A1FFF8B for ; Thu, 4 Feb 2010 12:02:49 +1100 (EST) Received: from wsmsg3707.srv.dir.telstra.com (wsmsg3707.srv.dir.telstra.com [172.49.40.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA14427 for ; Thu, 4 Feb 2010 12:02:48 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 4 Feb 2010 11:02:48 +1000 From: "Manger, James H" To: "OAuth WG (oauth@ietf.org)" Date: Thu, 4 Feb 2010 11:02:47 +1000 Thread-Topic: Comment on draft-hammer-http-token-auth-01 Thread-Index: AcqlNcPYYGtgKuxYSvaWZIMKPEOn5g== Message-ID: <255B9BB34FB7D647A506DC292726F6E112503E48B3@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112503E48B3WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] Comment on draft-hammer-http-token-auth-01 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Feb 2010 01:02:08 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112503E48B3WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgb24gZHJhZnQtaGFtbWVyLWh0dHAtdG9rZW4tYXV0aC0wMSAoMyBGZWIgMjAxMCkg YWZ0ZXIgYSBxdWljayByZWFkLg0KDQpbaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aGFtbWVyLWh0dHAtdG9rZW4tYXV0aC0wMV0NCg0KDQoNClRoZSBzaW1wbGUgYmVhcmVyIHRva2Vu IG1vZGUgaXMgc3RpbGwgYnVyaWVkIGFzIGFuIGV4Y2VwdGlvbiB0byB0aGUgcmVxdWVzdCBzaWdu aW5nIHJ1bGVzLiBUaGlzIGp1c3QgaXNu4oCZdCBuZWNlc3NhcnksIGl04oCZcyBhd2Z1bC4NCg0K DQoNCkNob29zaW5nIGEgaGFzaCBhbGdvcml0aG0gaXMgYXNzdW1lZCB0byBiZSBkb25lIHdoZW4g YSBjcmVkZW50aWFsIGlzIGlzc3VlZC4gSXQgaXMgbmljZSBjcnlwdG8taHlnaWVuZSB0byBvbmx5 IHVzZSBhIGdpdmVuIHNlY3JldCB3aXRoIGEgc2luZ2xlIGFsZ29yaXRobSwgYnV0IGl0IGlzIG5v dCBhbHdheXMgc2Vuc2libGUuIE9uZSBhcHAgbWF5IG9ubHkgc3VwcG9ydCBTSEEtMSwgd2hpbGUg YW5vdGhlciBvbmx5IHN1cHBvcnRzIFNIQS0yNTYuIFN0YW5kYXJkIEFQSXMgbWF5IG9ubHkgYWNj ZXB0IGFuIGlkIGFuZCBzZWNyZXQsIGFuZCBhc3N1bWUgdGhhdCBhY2NlcHRhYmxlIGhhc2ggYWxn b3JpdGhtcyBhcmUgY29uZmlndXJlZCBlbHNld2hlcmUgaW4gdGhlIHNvZnR3YXJlLiBIYXZpbmcg dG8gcmVpc3N1ZSBhbGwgY3JlZGVudGlhbHMgdG8gc3RvcCBzdXBwb3J0aW5nIGFuIG9sZCBoYXNo IGFsZ29yaXRobSB3aWxsIG5vdCBhbHdheXMgYmUgcHJhY3RpY2FsLCBhbmQgbG9va3MgbGlrZSBh IHN1YnN0YW50aWFsIGJhcnJpZXIgdG8gcmVtb3Zpbmcgc3VwcG9ydCBmb3IgYWxnb3JpdGhtcyB0 aGF0IGdldCBicm9rZW4uDQoNCg0KDQpJIHdvdWxkIHByZWZlciB0byBzdGljayB3aXRoIG1vcmUg Y29tbW9uIHByYWN0aXNlOiBleHBsaWNpdGx5IGxpc3QgdGhlIE1BQyBhbGdvcml0aG0gaW4gYSBz aWduZWQgcmVxdWVzdDsgYW5kIHN1cHBvcnQgc29tZSBhbGdvcml0aG0gbmVnb3RpYXRpb24gd2hl biBhY2Nlc3NpbmcgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgKGVnIGJ5IHRoZSBzZXJ2ZXIgbGlzdGlu ZyBzdXBwb3J0ZWQgYWxnb3JpdGhtcyBpbiBhIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVyKS4gVGhp cyBkb2VzbuKAmXQgc3RvcCBhIGNyZWRlbnRpYWwtaXNzdWVyIHN0YXRpbmcgdGhhdCBvbmx5IGEg c3BlY2lmaWMgaGFzaCBhbGcgY2FuIGJlIHVzZWQgd2l0aCBhIHNwZWNpZmljIHNlY3JldCwgaXQg anVzdCBkb2VzbuKAmXQgZm9yY2UgdGhpcyBtb2RlLg0KDQoNCg0KVGhlcmUgaXMgb25seSBhIHNw b3QgZm9yIGEgc2luZ2xlIGlkIGluIHRoZSBwcm90b2NvbCwgbm90IHNwb3RzIGZvciBzZXBhcmF0 ZSBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBpZHMuIFRoZSBhYnNlbmNlIG9mIGJv dGggaW4gZXhpc3RpbmcgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyBpcyB0aGUgb25seSByZWFz b24gdGhlcmUgaXMgYW55IGNvbmNlcm4gYWJvdXQgdXNpbmcgdGhvc2UgbWVjaGFuaXNtcyB3aXRo IGNyZWRlbnRpYWxzIGZyb20gZGVsZWdhdGlvbi4NCg0KDQoNClRoZSBleGFtcGxlIHVzZSBhIHBv b3IgY2hvaWNlIG9mIHJlYWxtOiByZWFsbT3igJ1odHRwOi8vZXhhbXBsZS5jb20v4oCdLiBSZWFs bXMgYXJlIG9ubHkgbWVhbmluZ2Z1bCBpbiB0aGUgc2NvcGUgb2YgdGhlIGN1cnJlbnQgc2VydmVy LiBUaGUgZXhhbXBsZSBzdWdnZXN0cyBhbnktb2xkLXNpdGUuY29tIGNhbiByZXR1cm4gcmVhbG09 4oCdaHR0cDovL3lhaG9vLmNvbS/igJ0gYW5kIHRoZSBjbGllbnQgd2lsbCByZXRyeSB0aGUgcmVx dWVzdCBhIHNldCBvZiB0b2tlbiBjcmVkZW50aWFscyBpc3N1ZWQgZm9yIFlhaG9vIHNlcnZpY2Vz LiBZaWtlcyENCg0KDQoNClRoZSAxc3QgcGFyYWdyYXBoIG9mIHRoZSBpbnRyb2R1Y3Rpb24gY29u ZnVzZXMgdGhlIOKAnGNsaWVudOKAnSB0ZXJtaW5vbG9neS4g4oCcQ2xpZW504oCdIGlzIHVzZWQg dG8gbWVhbnMgYW4gT0F1dGgg4oCccmVzb3VyY2Ugb3duZXLigJ0gYW5kIE9BdXRoIOKAnGNsaWVu dOKAnS4NCg0KDQoNCkJyZWFraW5nIHRoZSBleGlzdGluZyBtb2RlbCBvZiBIVFRQIGF1dGhlbnRp Y2F0aW9uICgxIHNjaGVtZSBwZXIgbWVjaGFuaXNtKSBpcyB0aGUgd3JvbmcgYXBwcm9hY2guDQoN Cg0KDQotLQ0KDQpKYW1lcyBNYW5nZXINCg0KDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E112503E48B3WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJ e3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K IDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUFVIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzIG9uIGRyYWZ0LWhhbW1lci1odHRwLXRva2VuLWF1dGgt MDEgKDMgRmViIDIwMTApIGFmdGVyIGEgcXVpY2sgcmVhZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPltodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYW1tZXIt aHR0cC10b2tlbi1hdXRoLTAxXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2ltcGxlIGJl YXJlciB0b2tlbiBtb2RlIGlzIHN0aWxsIGJ1cmllZCBhcyBhbiBleGNlcHRpb24gdG8gdGhlIHJl cXVlc3Qgc2lnbmluZyBydWxlcy4gVGhpcyBqdXN0IGlzbuKAmXQgbmVjZXNzYXJ5LCBpdOKAmXMg YXdmdWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNob29zaW5nIGEgaGFzaCBhbGdvcml0aG0g aXMgYXNzdW1lZCB0byBiZSBkb25lIHdoZW4gYSBjcmVkZW50aWFsIGlzIGlzc3VlZC4gSXQgaXMg bmljZSBjcnlwdG8taHlnaWVuZSB0byBvbmx5IHVzZSBhIGdpdmVuIHNlY3JldCB3aXRoIGEgc2lu Z2xlIGFsZ29yaXRobSwgYnV0IGl0IGlzIG5vdCBhbHdheXMgc2Vuc2libGUuIE9uZSBhcHAgbWF5 IG9ubHkgc3VwcG9ydCBTSEEtMSwgd2hpbGUgYW5vdGhlciBvbmx5DQogc3VwcG9ydHMgU0hBLTI1 Ni4gU3RhbmRhcmQgQVBJcyBtYXkgb25seSBhY2NlcHQgYW4gaWQgYW5kIHNlY3JldCwgYW5kIGFz c3VtZSB0aGF0IGFjY2VwdGFibGUgaGFzaCBhbGdvcml0aG1zIGFyZSBjb25maWd1cmVkIGVsc2V3 aGVyZSBpbiB0aGUgc29mdHdhcmUuIEhhdmluZyB0byByZWlzc3VlIGFsbCBjcmVkZW50aWFscyB0 byBzdG9wIHN1cHBvcnRpbmcgYW4gb2xkIGhhc2ggYWxnb3JpdGhtIHdpbGwgbm90IGFsd2F5cyBi ZSBwcmFjdGljYWwsDQogYW5kIGxvb2tzIGxpa2UgYSBzdWJzdGFudGlhbCBiYXJyaWVyIHRvIHJl bW92aW5nIHN1cHBvcnQgZm9yIGFsZ29yaXRobXMgdGhhdCBnZXQgYnJva2VuLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHdvdWxkIHByZWZlciB0byBzdGljayB3aXRoIG1vcmUgY29tbW9uIHBy YWN0aXNlOiBleHBsaWNpdGx5IGxpc3QgdGhlIE1BQyBhbGdvcml0aG0gaW4gYSBzaWduZWQgcmVx dWVzdDsgYW5kIHN1cHBvcnQgc29tZSBhbGdvcml0aG0gbmVnb3RpYXRpb24gd2hlbiBhY2Nlc3Np bmcgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgKGVnIGJ5IHRoZSBzZXJ2ZXIgbGlzdGluZyBzdXBwb3J0 ZWQgYWxnb3JpdGhtcyBpbiBhIFdXVy1BdXRoZW50aWNhdGUNCiBoZWFkZXIpLiBUaGlzIGRvZXNu 4oCZdCBzdG9wIGEgY3JlZGVudGlhbC1pc3N1ZXIgc3RhdGluZyB0aGF0IG9ubHkgYSBzcGVjaWZp YyBoYXNoIGFsZyBjYW4gYmUgdXNlZCB3aXRoIGEgc3BlY2lmaWMgc2VjcmV0LCBpdCBqdXN0IGRv ZXNu4oCZdCBmb3JjZSB0aGlzIG1vZGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlz IG9ubHkgYSBzcG90IGZvciBhIHNpbmdsZSBpZCBpbiB0aGUgcHJvdG9jb2wsIG5vdCBzcG90cyBm b3Igc2VwYXJhdGUgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gaWRzLiBUaGUgYWJz ZW5jZSBvZiBib3RoIGluIGV4aXN0aW5nIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgaXMgdGhl IG9ubHkgcmVhc29uIHRoZXJlIGlzIGFueSBjb25jZXJuIGFib3V0IHVzaW5nIHRob3NlIG1lY2hh bmlzbXMNCiB3aXRoIGNyZWRlbnRpYWxzIGZyb20gZGVsZWdhdGlvbi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIGV4YW1wbGUgdXNlIGEgcG9vciBjaG9pY2Ugb2YgcmVhbG06IHJlYWxtPeKA nWh0dHA6Ly9leGFtcGxlLmNvbS/igJ0uIFJlYWxtcyBhcmUgb25seSBtZWFuaW5nZnVsIGluIHRo ZSBzY29wZSBvZiB0aGUgY3VycmVudCBzZXJ2ZXIuIFRoZSBleGFtcGxlIHN1Z2dlc3RzIGFueS1v bGQtc2l0ZS5jb20gY2FuIHJldHVybiByZWFsbT3igJ1odHRwOi8veWFob28uY29tL+KAnSBhbmQg dGhlIGNsaWVudCB3aWxsIHJldHJ5IHRoZQ0KIHJlcXVlc3QgYSBzZXQgb2YgdG9rZW4gY3JlZGVu dGlhbHMgaXNzdWVkIGZvciBZYWhvbyBzZXJ2aWNlcy4gWWlrZXMhPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSAxPHN1cD5zdDwvc3VwPiBwYXJhZ3JhcGggb2YgdGhlIGludHJvZHVjdGlvbiBj b25mdXNlcyB0aGUg4oCcY2xpZW504oCdIHRlcm1pbm9sb2d5LiDigJxDbGllbnTigJ0gaXMgdXNl ZCB0byBtZWFucyBhbiBPQXV0aCDigJxyZXNvdXJjZSBvd25lcuKAnSBhbmQgT0F1dGgg4oCcY2xp ZW504oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmVha2luZyB0aGUgZXhpc3RpbmcgbW9k ZWwgb2YgSFRUUCBhdXRoZW50aWNhdGlvbiAoMSBzY2hlbWUgcGVyIG1lY2hhbmlzbSkgaXMgdGhl IHdyb25nIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_255B9BB34FB7D647A506DC292726F6E112503E48B3WSMSG3153Vsrv_-- From josephholsten@gmail.com Wed Feb 3 18:11: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 D09903A69B2 for ; Wed, 3 Feb 2010 18:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=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 tFEmqYC9zNzK for ; Wed, 3 Feb 2010 18:11:05 -0800 (PST) Received: from mail-yw0-f184.google.com (mail-yw0-f184.google.com [209.85.211.184]) by core3.amsl.com (Postfix) with ESMTP id A81923A63EC for ; Wed, 3 Feb 2010 18:11:00 -0800 (PST) Received: by ywh14 with SMTP id 14so2110507ywh.20 for ; Wed, 03 Feb 2010 18:11:42 -0800 (PST) Received: by 10.90.15.14 with SMTP id 14mr732241ago.2.1265249501526; Wed, 03 Feb 2010 18:11:41 -0800 (PST) Received: from ?192.168.1.101? (ip70-189-108-199.ok.ok.cox.net [70.189.108.199]) by mx.google.com with ESMTPS id 20sm2759914ywh.47.2010.02.03.18.11.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 18:11:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Joseph Anthony Pasquale Holsten In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B7E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 3 Feb 2010 20:11:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723437899D22BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112503E4238@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B7E@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: "OAuth WG (oauth@ietf.org)" X-Mailer: Apple Mail (2.1077) Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge? X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Feb 2010 02:11:11 -0000 A self fulfilling prophecy. Who isn't interested? Client authors or service providers with an = incentive to lock people in? If you work at microsoft or google or yahoo = or facebook, you might consider asking people like ping.fm how much they = care about interoperability. And maybe ask why the people who are = supposed to be consuming these services aren't active on these lists. -- j On Feb 3, 2010, at 10:46 AM, Eran Hammer-Lahav wrote: > It doesn't feel like we have much interest at this level of = interoperability at this point. >=20 > EHL >=20 >> -----Original Message----- >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] >> Sent: Wednesday, February 03, 2010 5:38 AM >> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) >> Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an >> authentication challenge? >>=20 >> An authentication challenge (WWW-Authenticate header) defined in a = spec >> for an authentication mechanism should be present, but only with = details >> specific to that mechanism (eg list of MAC algorithms). >>=20 >> I think there should be a totally separate WWW-Authenticate header >> specifically saying "a delegation flow can be used to access this = resource". It >> should include details such as the URI to redirect the user to. >>=20 >> We really need this if we want to offer a web-style protocol with any >> semblance of interoperability. If we omit it because "clients need to = know >> lots of other API-specific details anyway" then we wont have a path = to get >> past that limitation in future. >>=20 >>=20 >> -- >> James Manger >>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >>> Of Eran Hammer-Lahav >>> Sent: Thursday, 28 January 2010 2:12 PM >>> To: OAuth WG (oauth@ietf.org) >>> Subject: [OAUTH-WG] What are the primary criteria in issuing an >>> authentication challenge? >>>=20 >>> An authentication challenge (to make sure we are all on the same = page) >>> is something the server sends to the client when denying access to a >>> protected resource. The challenge can be as simple as "use Basic", = or >>> complex as "use Digest with the following parameters". OAuth 1.0 >>> doesn't really use a challenge because it was created for cases = where >>> the API calls are preconfigured and hardcoded into the client. The >>> client should never receive an OAuth challenge the way the protocol >>> was originally designed. >>>=20 >>> In my token authentication draft I tried to propose multiple >>> mechanisms (not fully baked yet) for issuing a challenge and = allowing >>> the client to figure out what to do next. Before producing another >>> draft, it is important to figure out what challenge model we want to >>> use. Here are the general options I came up with: >>>=20 >>> 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is >>> left on its own to figure out what to do next. >>>=20 >>> 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you >>> need a new token go there". It is still not clear how this will help >>> the client given that getting a token is likely it include many >>> different options, and to fully address this we need to dig deep = into >>> discovery which was left out of scope. >>>=20 >>> 3. Token attributes - the server informs the client of the kind of >>> tokens accepted (based on their cryptographic properties or the >>> resource-set/realm they are good for). This is just like #2 but with >>> the ability for the server to support more than one token type per >>> resource. >>>=20 >>> Question: Is the ability for a single token-protected resource to >>> support more than one token type (say Plain+SSL *and* HMAC-256) part >>> of our requirements? If not, there is no reason at all for the >>> challenge to include anything other than #1 or #2 (probably defined = as >>> a future extension). >>>=20 >>> EHL >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Feb 3 18:16:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D1028C0E7 for ; Wed, 3 Feb 2010 18:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=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 vfCN4ZiwdWjd for ; Wed, 3 Feb 2010 18:16:41 -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 22F1228C0E1 for ; Wed, 3 Feb 2010 18:16:41 -0800 (PST) Received: (qmail 8886 invoked from network); 4 Feb 2010 02:17:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Feb 2010 02:17:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 3 Feb 2010 19:17:08 -0700 From: Eran Hammer-Lahav To: Joseph Anthony Pasquale Holsten , "OAuth WG (oauth@ietf.org)" Date: Wed, 3 Feb 2010 19:16:45 -0700 Thread-Topic: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge? Thread-Index: AcqlP2rIIgo3F9+xQamv5QKns36VZAAAKGzQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2D79@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437899D22BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112503E4238@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B7E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge? X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Feb 2010 02:16:42 -0000 You are going too far. I meant the people on this list. That's the only gro= up that matters. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Joseph Anthony Pasquale Holsten > Sent: Wednesday, February 03, 2010 6:12 PM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an > authentication challenge? >=20 > A self fulfilling prophecy. >=20 > Who isn't interested? Client authors or service providers with an incenti= ve to > lock people in? If you work at microsoft or google or yahoo or facebook, = you > might consider asking people like ping.fm how much they care about > interoperability. And maybe ask why the people who are supposed to be > consuming these services aren't active on these lists. > -- > j >=20 > On Feb 3, 2010, at 10:46 AM, Eran Hammer-Lahav wrote: >=20 > > It doesn't feel like we have much interest at this level of interoperab= ility at > this point. > > > > EHL > > > >> -----Original Message----- > >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > >> Sent: Wednesday, February 03, 2010 5:38 AM > >> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > >> Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an > >> authentication challenge? > >> > >> An authentication challenge (WWW-Authenticate header) defined in a > >> spec for an authentication mechanism should be present, but only with > >> details specific to that mechanism (eg list of MAC algorithms). > >> > >> I think there should be a totally separate WWW-Authenticate header > >> specifically saying "a delegation flow can be used to access this > >> resource". It should include details such as the URI to redirect the u= ser to. > >> > >> We really need this if we want to offer a web-style protocol with any > >> semblance of interoperability. If we omit it because "clients need to > >> know lots of other API-specific details anyway" then we wont have a > >> path to get past that limitation in future. > >> > >> > >> -- > >> James Manger > >> > >>> -----Original Message----- > >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>> Behalf Of Eran Hammer-Lahav > >>> Sent: Thursday, 28 January 2010 2:12 PM > >>> To: OAuth WG (oauth@ietf.org) > >>> Subject: [OAUTH-WG] What are the primary criteria in issuing an > >>> authentication challenge? > >>> > >>> An authentication challenge (to make sure we are all on the same > >>> page) is something the server sends to the client when denying > >>> access to a protected resource. The challenge can be as simple as > >>> "use Basic", or complex as "use Digest with the following > >>> parameters". OAuth 1.0 doesn't really use a challenge because it was > >>> created for cases where the API calls are preconfigured and > >>> hardcoded into the client. The client should never receive an OAuth > >>> challenge the way the protocol was originally designed. > >>> > >>> In my token authentication draft I tried to propose multiple > >>> mechanisms (not fully baked yet) for issuing a challenge and > >>> allowing the client to figure out what to do next. Before producing > >>> another draft, it is important to figure out what challenge model we > >>> want to use. Here are the general options I came up with: > >>> > >>> 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is > >>> left on its own to figure out what to do next. > >>> > >>> 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you > >>> need a new token go there". It is still not clear how this will help > >>> the client given that getting a token is likely it include many > >>> different options, and to fully address this we need to dig deep > >>> into discovery which was left out of scope. > >>> > >>> 3. Token attributes - the server informs the client of the kind of > >>> tokens accepted (based on their cryptographic properties or the > >>> resource-set/realm they are good for). This is just like #2 but with > >>> the ability for the server to support more than one token type per > >>> resource. > >>> > >>> Question: Is the ability for a single token-protected resource to > >>> support more than one token type (say Plain+SSL *and* HMAC-256) part > >>> of our requirements? If not, there is no reason at all for the > >>> challenge to include anything other than #1 or #2 (probably defined > >>> as a future extension). > >>> > >>> EHL > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From josephholsten@gmail.com Wed Feb 3 18:53:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148B33A6A48 for ; Wed, 3 Feb 2010 18:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=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 V7yDMkR-NkxE for ; Wed, 3 Feb 2010 18:53:20 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id AC8A73A6A28 for ; Wed, 3 Feb 2010 18:53:20 -0800 (PST) Received: by gxk28 with SMTP id 28so1964334gxk.9 for ; Wed, 03 Feb 2010 18:54:02 -0800 (PST) Received: by 10.150.180.6 with SMTP id c6mr1119928ybf.82.1265252041305; Wed, 03 Feb 2010 18:54:01 -0800 (PST) Received: from ?192.168.1.101? (ip70-189-108-199.ok.ok.cox.net [70.189.108.199]) by mx.google.com with ESMTPS id 9sm2772256ywf.20.2010.02.03.18.53.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 18:53:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Joseph Anthony Pasquale Holsten In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2D79@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 3 Feb 2010 20:53:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <48AF826E-1B19-4AD5-94CF-E445C40AD39F@josephholsten.com> References: <90C41DD21FB7C64BB94121FBBC2E723437899D22BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112503E4238@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B7E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2D79@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: "OAuth WG (oauth@ietf.org)" X-Mailer: Apple Mail (2.1077) Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge? X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Feb 2010 02:53:22 -0000 Please consider my position retracted. -- j On Feb 3, 2010, at 8:16 PM, Eran Hammer-Lahav wrote: > You are going too far. I meant the people on this list. That's the = only group that matters. >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Joseph Anthony Pasquale Holsten >> Sent: Wednesday, February 03, 2010 6:12 PM >> To: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an >> authentication challenge? >>=20 >> A self fulfilling prophecy. >>=20 >> Who isn't interested? Client authors or service providers with an = incentive to >> lock people in? If you work at microsoft or google or yahoo or = facebook, you >> might consider asking people like ping.fm how much they care about >> interoperability. And maybe ask why the people who are supposed to be >> consuming these services aren't active on these lists. >> -- >> j >>=20 >> On Feb 3, 2010, at 10:46 AM, Eran Hammer-Lahav wrote: >>=20 >>> It doesn't feel like we have much interest at this level of = interoperability at >> this point. >>>=20 >>> EHL >>>=20 >>>> -----Original Message----- >>>> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] >>>> Sent: Wednesday, February 03, 2010 5:38 AM >>>> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) >>>> Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an >>>> authentication challenge? >>>>=20 >>>> An authentication challenge (WWW-Authenticate header) defined in a >>>> spec for an authentication mechanism should be present, but only = with >>>> details specific to that mechanism (eg list of MAC algorithms). >>>>=20 >>>> I think there should be a totally separate WWW-Authenticate header >>>> specifically saying "a delegation flow can be used to access this >>>> resource". It should include details such as the URI to redirect = the user to. >>>>=20 >>>> We really need this if we want to offer a web-style protocol with = any >>>> semblance of interoperability. If we omit it because "clients need = to >>>> know lots of other API-specific details anyway" then we wont have a >>>> path to get past that limitation in future. >>>>=20 >>>>=20 >>>> -- >>>> James Manger >>>>=20 >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>> Behalf Of Eran Hammer-Lahav >>>>> Sent: Thursday, 28 January 2010 2:12 PM >>>>> To: OAuth WG (oauth@ietf.org) >>>>> Subject: [OAUTH-WG] What are the primary criteria in issuing an >>>>> authentication challenge? >>>>>=20 >>>>> An authentication challenge (to make sure we are all on the same >>>>> page) is something the server sends to the client when denying >>>>> access to a protected resource. The challenge can be as simple as >>>>> "use Basic", or complex as "use Digest with the following >>>>> parameters". OAuth 1.0 doesn't really use a challenge because it = was >>>>> created for cases where the API calls are preconfigured and >>>>> hardcoded into the client. The client should never receive an = OAuth >>>>> challenge the way the protocol was originally designed. >>>>>=20 >>>>> In my token authentication draft I tried to propose multiple >>>>> mechanisms (not fully baked yet) for issuing a challenge and >>>>> allowing the client to figure out what to do next. Before = producing >>>>> another draft, it is important to figure out what challenge model = we >>>>> want to use. Here are the general options I came up with: >>>>>=20 >>>>> 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is >>>>> left on its own to figure out what to do next. >>>>>=20 >>>>> 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if = you >>>>> need a new token go there". It is still not clear how this will = help >>>>> the client given that getting a token is likely it include many >>>>> different options, and to fully address this we need to dig deep >>>>> into discovery which was left out of scope. >>>>>=20 >>>>> 3. Token attributes - the server informs the client of the kind of >>>>> tokens accepted (based on their cryptographic properties or the >>>>> resource-set/realm they are good for). This is just like #2 but = with >>>>> the ability for the server to support more than one token type per >>>>> resource. >>>>>=20 >>>>> Question: Is the ability for a single token-protected resource to >>>>> support more than one token type (say Plain+SSL *and* HMAC-256) = part >>>>> of our requirements? If not, there is no reason at all for the >>>>> challenge to include anything other than #1 or #2 (probably = defined >>>>> as a future extension). >>>>>=20 >>>>> EHL >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Feb 3 20:39: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 3A25A3A6B96 for ; Wed, 3 Feb 2010 20:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 dmhs2DBoHUBI for ; Wed, 3 Feb 2010 20:39:00 -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 8C5FD3A698E for ; Wed, 3 Feb 2010 20:39:00 -0800 (PST) Received: (qmail 26207 invoked from network); 4 Feb 2010 04:39:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Feb 2010 04:39:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 3 Feb 2010 21:39:41 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "OAuth WG (oauth@ietf.org)" Date: Wed, 3 Feb 2010 21:39:17 -0700 Thread-Topic: Comment on draft-hammer-http-token-auth-01 Thread-Index: AcqlNcPYYGtgKuxYSvaWZIMKPEOn5gAGoMKQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2D92@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E112503E48B3@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112503E48B3@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Comment on draft-hammer-http-token-auth-01 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Feb 2010 04:39:04 -0000 VGhhbmtzIEphbWVzLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG9h dXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYNCj4gT2YgTWFuZ2VyLCBKYW1lcyBIDQo+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkg MDMsIDIwMTAgNTowMyBQTQ0KPiBUbzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KPiBTdWJq ZWN0OiBbT0FVVEgtV0ddIENvbW1lbnQgb24gZHJhZnQtaGFtbWVyLWh0dHAtdG9rZW4tYXV0aC0w MQ0KPiANCj4gQ29tbWVudHMgb24gZHJhZnQtaGFtbWVyLWh0dHAtdG9rZW4tYXV0aC0wMSAoMyBG ZWIgMjAxMCkgYWZ0ZXIgYSBxdWljaw0KPiByZWFkLg0KPiBbaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaGFtbWVyLWh0dHAtdG9rZW4tYXV0aC0wMV0NCj4gDQo+IFRoZSBzaW1wbGUg YmVhcmVyIHRva2VuIG1vZGUgaXMgc3RpbGwgYnVyaWVkIGFzIGFuIGV4Y2VwdGlvbiB0byB0aGUg cmVxdWVzdA0KPiBzaWduaW5nIHJ1bGVzLg0KDQpUaGlzIGRyYWZ0IHdhcyBqdXN0IHRvIHJlbW92 ZSB0aGUgY29uZnVzaW5nIGJpdHMuIEkgYW0gc3RpbGwgd29ya2luZyBvbiBpdCB0byBtYWtlIHRo ZSBwbGFpbiBtZXRob2QgZWFzaWVyIHRvIG5vdGljZS4NCg0KPiBUaGlzIGp1c3QgaXNu4oCZdCBu ZWNlc3NhcnksIGl04oCZcyBhd2Z1bC4NCg0KQ29uc3RydWN0aXZlIGNyaXRpY2lzbSBpcyBhbHdh eXMgaGVscGZ1bC4gOi0pDQoNCj4gQ2hvb3NpbmcgYSBoYXNoIGFsZ29yaXRobSBpcyBhc3N1bWVk IHRvIGJlIGRvbmUgd2hlbiBhIGNyZWRlbnRpYWwgaXMgaXNzdWVkLg0KPiBJdCBpcyBuaWNlIGNy eXB0by1oeWdpZW5lIHRvIG9ubHkgdXNlIGEgZ2l2ZW4gc2VjcmV0IHdpdGggYSBzaW5nbGUgYWxn b3JpdGhtLCBidXQNCj4gaXQgaXMgbm90IGFsd2F5cyBzZW5zaWJsZS4gT25lIGFwcCBtYXkgb25s eSBzdXBwb3J0IFNIQS0xLCB3aGlsZSBhbm90aGVyIG9ubHkNCj4gc3VwcG9ydHMgU0hBLTI1Ni4g U3RhbmRhcmQgQVBJcyBtYXkgb25seSBhY2NlcHQgYW4gaWQgYW5kIHNlY3JldCwgYW5kDQo+IGFz c3VtZSB0aGF0IGFjY2VwdGFibGUgaGFzaCBhbGdvcml0aG1zIGFyZSBjb25maWd1cmVkIGVsc2V3 aGVyZSBpbiB0aGUNCj4gc29mdHdhcmUuIEhhdmluZyB0byByZWlzc3VlIGFsbCBjcmVkZW50aWFs cyB0byBzdG9wIHN1cHBvcnRpbmcgYW4gb2xkIGhhc2gNCj4gYWxnb3JpdGhtIHdpbGwgbm90IGFs d2F5cyBiZSBwcmFjdGljYWwsIGFuZCBsb29rcyBsaWtlIGEgc3Vic3RhbnRpYWwgYmFycmllciB0 bw0KPiByZW1vdmluZyBzdXBwb3J0IGZvciBhbGdvcml0aG1zIHRoYXQgZ2V0IGJyb2tlbi4NCg0K SSBkaXNhZ3JlZS4gVm9pZGluZyBhIHRva2VuIHRvIHN0b3Agc3VwcG9ydGluZyBhbiBhbGdvcml0 aG0gaXMgcGVyZmVjdGx5IHJlYXNvbmFibGUgYW5kIG1pZ2h0IG5vdCBldmVuIHJlcXVpcmUgdXNl ciBpbnZvbHZlbWVudCBpZiB0aGUgcmVmcmVzaCBtZWNoYW5pc20gaXMgKGFkb3B0ZWQgYW5kKSB1 c2VkLiBBbmQgaWYgdGhlIHJlYXNvbiBmb3IgdGhpcyBpcyBhIGJyb2tlbiBhbGdvcml0aG0sIHdl bGwsIEkgd291bGQgaG9wZSB0aGUgdG9rZW5zIGFyZSB2b2lkZWQsIG5vdCBqdXN0IHVzZWQgd2l0 aCB0aGUgc2FtZSBzZWNyZXQgYW5kIG5ldyBhbGdvcml0aG0uDQoNCkkgYW0gbm90IHN1cmUgd2hh dCB5b3UgbWVhbiBieSAib25lIGFwcCBtYXkgb25seSBzdXBwb3J0IFNIQS0xLCB3aGlsZSBhbm90 aGVyIG9ubHkgc3VwcG9ydHMgU0hBLTI1NiIuIEFyZSB5b3Ugc3VnZ2VzdGluZyBzb21ldGhpbmcg bGlrZSBhIGNvbXBhbnkgd2l0aCBjZW50cmFsaXplZCB0b2tlbiBzZXJ2aWNlIGJ1dCB3aGVyZSBl YWNoIHNlcnZpY2UgdXNpbmcgYSBkaWZmZXJlbnQgc2V0IG9mIGFsZ29yaXRobSwgYnV0IHN0aWxs IHNoYXJpbmcgdGhlIHNhbWUgdG9rZW4gYWNyb3NzIHNlcnZpY2VzPyBTb3VuZHMgbGlrZSBhIGNv bXBhbnkgaW4gbmVlZCBvZiBuZXcgbWFuYWdlbWVudC4NCg0KPiBJIHdvdWxkIHByZWZlciB0byBz dGljayB3aXRoIG1vcmUgY29tbW9uIHByYWN0aXNlOiBleHBsaWNpdGx5IGxpc3QgdGhlIE1BQw0K PiBhbGdvcml0aG0gaW4gYSBzaWduZWQgcmVxdWVzdDsgYW5kIHN1cHBvcnQgc29tZSBhbGdvcml0 aG0gbmVnb3RpYXRpb24gd2hlbg0KPiBhY2Nlc3NpbmcgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgKGVn IGJ5IHRoZSBzZXJ2ZXIgbGlzdGluZyBzdXBwb3J0ZWQgYWxnb3JpdGhtcw0KPiBpbiBhIFdXVy1B dXRoZW50aWNhdGUgaGVhZGVyKS4gVGhpcyBkb2VzbuKAmXQgc3RvcCBhIGNyZWRlbnRpYWwtaXNz dWVyIHN0YXRpbmcNCj4gdGhhdCBvbmx5IGEgc3BlY2lmaWMgaGFzaCBhbGcgY2FuIGJlIHVzZWQg d2l0aCBhIHNwZWNpZmljIHNlY3JldCwgaXQganVzdCBkb2VzbuKAmXQNCj4gZm9yY2UgdGhpcyBt b2RlLg0KDQpUaGlzIGNoYW5nZSB3YXMgYmFzZWQgZGlyZWN0bHkgb24gV0cgZmVlZGJhY2suIEkg YXNrZWQgdHdvIHF1ZXN0aW9uczoNCg0KMS4gV2hhdCBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhl IGNoYWxsZW5nZT8NCjIuIFNob3VsZCBvbmUgdG9rZW4gYmUgYWxsb3dlZCB0byBzdXBwb3J0IG11 bHRpcGxlIGFsZ29yaXRobXM/DQoNCkl0IHNlZW1zIHRvIG1lIHRoYXQgd2VyZSB3YXMgbm8gaW50 ZXJlc3QgaW4gbmVnb3RpYXRpbmcgYWxnb3JpdGhtcyBvciB0b2tlbnMgd2l0aCBtdWx0aXBsZSBt ZXRob2RzLiBCdXQgSSBhbSBoYXBweSB0byBhc2sgdGhlc2UgcXVlc3Rpb25zIGFnYWluIGFuZCBz ZWUgaWYgcGVvcGxlIGhhdmUgZGlmZmVyZW50IGFuc3dlcnMgbm93IHRoYXQgdGhlcmUgaXMgYSBu ZXcgZHJhZnQgdG8gcG9rZSBhdC4NCg0KPiBUaGVyZSBpcyBvbmx5IGEgc3BvdCBmb3IgYSBzaW5n bGUgaWQgaW4gdGhlIHByb3RvY29sLCBub3Qgc3BvdHMgZm9yIHNlcGFyYXRlDQo+IGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGlkcy4gVGhlIGFic2VuY2Ugb2YgYm90aCBpbiBleGlz dGluZw0KPiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIGlzIHRoZSBvbmx5IHJlYXNvbiB0aGVy ZSBpcyBhbnkgY29uY2VybiBhYm91dA0KPiB1c2luZyB0aG9zZSBtZWNoYW5pc21zIHdpdGggY3Jl ZGVudGlhbHMgZnJvbSBkZWxlZ2F0aW9uLg0KDQpUaGF0J3MgYW5vdGhlciBhcmVhIHdoZXJlIEkg ZmVlbCB0aGVyZSBpcyBubyBpbnRlcmVzdC4gVGhlIGV4aXN0aW5nIHNjaGVtZXMgY29tZSB3aXRo IHRvbyBtdWNoIGV4aXN0aW5nIGRlcGxveW1lbnQgYW5kIGV4cGVjdGF0aW9ucyAtIHRoYXQncyB3 aHkgd2UgYXJlIG5vdCByZXVzaW5nIHRoZW0uIFRoZSB0b2tlbiBzY2hlbWUgaXMgZGVzaWduZWQg dG8gYWx3YXlzIHdvcmsgd2l0aCBhIHNlcnZlciBpc3N1aW5nIHRva2VucywgZXZlbiBpZiB0aGVy ZSBpcyBubyBlbmQtdXNlci4gVGhlIGlkZWEgb2YgdXNpbmcgaXQgYXMgYSByZXBsYWNlbWVudCBm b3IgQmFzaWMgYXV0aCBpcyBwcmV0dHkgbXVjaCBkZWFkIGNvbnNpZGVyaW5nIHRoYXQgcmVxdWly aW5nIHNlcnZlcnMgdG8ga2VlcCBwbGFpbiB0ZXh0IGNvcGllcyBvZiBwYXNzd29yZHMgaXMgYSBk ZWFsIGJyZWFrZXIuDQoNCkRpZCB5b3UgcmVhY2ggYSBkaWZmZXJlbnQgY29uY2x1c2lvbiBmcm9t IHRoZXNlIGRpc2N1c3Npb25zPw0KDQo+IFRoZSBleGFtcGxlIHVzZSBhIHBvb3IgY2hvaWNlIG9m IHJlYWxtOiByZWFsbT3igJ1odHRwOi8vZXhhbXBsZS5jb20v4oCdLg0KPiBSZWFsbXMgYXJlIG9u bHkgbWVhbmluZ2Z1bCBpbiB0aGUgc2NvcGUgb2YgdGhlIGN1cnJlbnQgc2VydmVyLiBUaGUgZXhh bXBsZQ0KPiBzdWdnZXN0cyBhbnktb2xkLXNpdGUuY29tIGNhbiByZXR1cm4gcmVhbG094oCdaHR0 cDovL3lhaG9vLmNvbS/igJ0gYW5kIHRoZQ0KPiBjbGllbnQgd2lsbCByZXRyeSB0aGUgcmVxdWVz dCBhIHNldCBvZiB0b2tlbiBjcmVkZW50aWFscyBpc3N1ZWQgZm9yIFlhaG9vDQo+IHNlcnZpY2Vz Lg0KDQpZZWFoLiBJIGhhZCAiRXhhbXBsZSBSZXNvdXJjZXMiIGJlZm9yZSBidXQgY2hhbmdlZCBp dC4gVGhlIHJlYWxtIHBhcmFtZXRlciBuZWVkcyBhIGxvdCBvZiB3b3JrLg0KDQo+IFlpa2VzIQ0K DQpTb3JyeS4gRGlkbid0IG1lYW4gdG8gc2NhcmUgeW91Lg0KDQo+IFRoZSAxc3QgcGFyYWdyYXBo IG9mIHRoZSBpbnRyb2R1Y3Rpb24gY29uZnVzZXMgdGhlIOKAnGNsaWVudOKAnSB0ZXJtaW5vbG9n eS4NCj4g4oCcQ2xpZW504oCdIGlzIHVzZWQgdG8gbWVhbnMgYW4gT0F1dGgg4oCccmVzb3VyY2Ug b3duZXLigJ0gYW5kIE9BdXRoIOKAnGNsaWVudOKAnS4NCg0KRml4ZWQuDQoNCj4gQnJlYWtpbmcg dGhlIGV4aXN0aW5nIG1vZGVsIG9mIEhUVFAgYXV0aGVudGljYXRpb24gKDEgc2NoZW1lIHBlcg0K PiBtZWNoYW5pc20pIGlzIHRoZSB3cm9uZyBhcHByb2FjaC4NCg0KTm90IHN1cmUgd2hhdCB5b3Ug bWVhbi4NCg0KRUhMDQo= From jpanzer@google.com Wed Feb 3 21:22: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 4302828C12C for ; Wed, 3 Feb 2010 21:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.377 X-Spam-Level: X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kArSChlyRqA8 for ; Wed, 3 Feb 2010 21:22:05 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 84B8928C10A for ; Wed, 3 Feb 2010 21:22:04 -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 o145MmAK025925 for ; Wed, 3 Feb 2010 21:22:48 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265260968; bh=cMB1LJhp3yjlE2FrqwZtibgXw9o=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=yncKOmhNjRNjzNsYEbT/YCxapZxBUFBoTod9kJaMQ95lBnGJoVZnVJHnwKTJMfsvy mWA0mNa956BGASzZoNrmA== 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=TSJHxZNPyjv/2OFK6SRwBDhvUNIwDb2y6/QtReCzjzZTXW+1vfO66V9bp0R4nD3la zvPvLXdtOStlRmAlhOCng== Received: from yxe6 (yxe6.prod.google.com [10.190.2.6]) by kpbe18.cbf.corp.google.com with ESMTP id o145Mklx016490 for ; Wed, 3 Feb 2010 21:22:46 -0800 Received: by yxe6 with SMTP id 6so4881699yxe.11 for ; Wed, 03 Feb 2010 21:22:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.55.30 with SMTP id d30mr1259143yba.138.1265260965699; Wed, 03 Feb 2010 21:22:45 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B7E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437899D22BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112503E4238@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B7E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 3 Feb 2010 21:22:45 -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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge? X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Feb 2010 05:22:06 -0000 Au contraire (speaking only for myself). On Wednesday, February 3, 2010, Eran Hammer-Lahav wro= te: > It doesn't feel like we have much interest at this level of interoperabil= ity at this point. > > EHL > >> -----Original Message----- >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] >> Sent: Wednesday, February 03, 2010 5:38 AM >> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) >> Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an >> authentication challenge? >> >> An authentication challenge (WWW-Authenticate header) defined in a spec >> for an authentication mechanism should be present, but only with details >> specific to that mechanism (eg list of MAC algorithms). >> >> I think there should be a totally separate WWW-Authenticate header >> specifically saying "a delegation flow can be used to access this resour= ce". It >> should include details such as the URI to redirect the user to. >> >> We really need this if we want to offer a web-style protocol with any >> semblance of interoperability. If we omit it because "clients need to kn= ow >> lots of other API-specific details anyway" then we wont have a path to g= et >> past that limitation in future. >> >> >> -- >> James Manger >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> > Of Eran Hammer-Lahav >> > Sent: Thursday, 28 January 2010 2:12 PM >> > To: OAuth WG (oauth@ietf.org) >> > Subject: [OAUTH-WG] What are the primary criteria in issuing an >> > authentication challenge? >> > >> > An authentication challenge (to make sure we are all on the same page) >> > is something the server sends to the client when denying access to a >> > protected resource. The challenge can be as simple as "use Basic", or >> > complex as "use Digest with the following parameters". OAuth 1.0 >> > doesn't really use a challenge because it was created for cases where >> > the API calls are preconfigured and hardcoded into the client. The >> > client should never receive an OAuth challenge the way the protocol >> > was originally designed. >> > >> > In my token authentication draft I tried to propose multiple >> > mechanisms (not fully baked yet) for issuing a challenge and allowing >> > the client to figure out what to do next. Before producing another >> > draft, it is important to figure out what challenge model we want to >> > use. Here are the general options I came up with: >> > >> > 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is >> > left on its own to figure out what to do next. >> > >> > 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you >> > need a new token go there". It is still not clear how this will help >> > the client given that getting a token is likely it include many >> > different options, and to fully address this we need to dig deep into >> > discovery which was left out of scope. >> > >> > 3. Token attributes - the server informs the client of the kind of >> > tokens accepted (based on their cryptographic properties or the >> > resource-set/realm they are good for). This is just like #2 but with >> > the ability for the server to support more than one token type per >> > resource. >> > >> > Question: Is the ability for a single token-protected resource to >> > support more than one token type (say Plain+SSL *and* HMAC-256) part >> > of our requirements? If not, there is no reason at all for the >> > challenge to include anything other than #1 or #2 (probably defined as >> > a future extension). >> > >> > EHL >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > ht=A0 --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From James.H.Manger@team.telstra.com Wed Feb 3 22:19: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 DEDB33A6C9A for ; Wed, 3 Feb 2010 22:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KADSESl9A6er for ; Wed, 3 Feb 2010 22:18:49 -0800 (PST) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id 0884A3A67DF for ; Wed, 3 Feb 2010 22:18:31 -0800 (PST) Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipbi.ntcif.telstra.com.au with ESMTP; 04 Feb 2010 17:19:15 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id ABD29FF81; Thu, 4 Feb 2010 17:19:14 +1100 (EST) Received: from wsmsg3756.srv.dir.telstra.com (wsmsg3756.srv.dir.telstra.com [172.49.40.84]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA02066; Thu, 4 Feb 2010 17:19:14 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Thu, 4 Feb 2010 17:19:14 +1100 From: "Manger, James H" To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Thu, 4 Feb 2010 17:19:12 +1100 Thread-Topic: Comment on draft-hammer-http-token-auth-01 Thread-Index: AcqlNcPYYGtgKuxYSvaWZIMKPEOn5gAGoMKQAAKRi0A= Message-ID: <255B9BB34FB7D647A506DC292726F6E112504AE32A@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E112503E48B3@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2D92@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2D92@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: yes acceptlanguage: en-US, en-AU Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000E_01CAA5BE.2B19A270" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Comment on draft-hammer-http-token-auth-01 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Feb 2010 06:19:37 -0000 ------=_NextPart_000_000E_01CAA5BE.2B19A270 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit > I disagree. Voiding a token to stop supporting an algorithm is > perfectly reasonable and might not even require user involvement if the > refresh mechanism is (adopted and) used. And if the reason for this is > a broken algorithm, well, I would hope the tokens are voided, not just > used with the same secret and new algorithm. Migrating to new algorithms is a very slow and tortuous process -- partly because an algorithm is rarely completely broken in a single instant. Even MD5 is still safe for some purposes. Binding secrets to hash algorithms in the protocol (not just as a choice by one server) will make migrations that much harder. > I am not sure what you mean by "one app may only support SHA-1, while > another only supports SHA-256". Are you suggesting something like a > company with centralized token service but where each service using a > different set of algorithm, but still sharing the same token across > services? Sounds like a company in need of new management. That is exactly what I am suggesting. Old apps, new apps, outsourced apps, legacy apps, white-label apps rebadged, app in this language, app in that language, apps in the cloud, apps from a merger... There is no way I expect perfect consistency in supported algorithms, but I do want to try to have SSO across these apps and a central token service for accessing their APIs. I don't want to have to upgrade every single app (even the niche near end-of-life ones) to support a new algorithm before I can start using it anywhere. If a credential bound to a new algorithm is issued to a client, that client can no longer access apps that have not been upgraded -- or, worst still, the client is expected to manage multiple app-specific credentials where previously they used one. > > Breaking the existing model of HTTP authentication (1 scheme per > > mechanism) is the wrong approach. > > Not sure what you mean. In most HTTP authentication mechanisms, knowing the scheme is sufficient to know the sort of credential required, the security properties, and if you have the code to support it. With Token, the credentials might be just a token, a token and shared secret, or a token and asymmetric key. With Token, you may or may not be safe from passive attacks, or active attacks; may or may not require lower-layer security; might have to do computationally-intensive public-key crypto or might only require trivial copy 'n paste. You have broken the model where the scheme means something about the type of credential and the security. -- James Manger ------=_NextPart_000_000E_01CAA5BE.2B19A270 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIbMzCCBjsw ggUjoAMCAQICChdxQLUAAAAAAXowDQYJKoZIhvcNAQEFBQAwFzEVMBMGA1UEAxMMTWVzc2FnaW5n IENBMB4XDTA5MDMzMDA0MDM1NloXDTEwMDMzMDA0MDM1NlowEjEQMA4GA1UEAxMHYzc5OTg3ODCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO8P/+Fi1PoZEwtviknjbBwidlGRLsFmvBzs 17SVVVm9mnqftyvY8SxCbOtXrhG+8+OyMK585h7PaNW3u0v9mK027UC+uPFEOU8SEEQmXLW1pm6L et1uzuTEEYIDDtjcMEfYLkFnaV5bNBiCeyWEHHN7aiqMi8a6RORrNlz9W/Jl261e1m+OlBp1ERwl LpqiuCa6xTh1uferf5v0vmerUUuontzdiS8m0Xm0maA/lKsArsUL0suD2Eq87karqJoXzcN0irHu F7zfOYclo4Fn/1QFuYaY8V2n7QQUNNrbsTkLOzm4flO6DNgtbIOXLZcY2JR6cKFXgKhAnQXJwiuO w1MCAwEAAaOCA4wwggOIMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQU8lC4r/gvSB0BMMqVbVhIirsC L4wwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhNSOIoLt31OF9YMYgsa8XIWHuy1+htX/D4L9 +g4CAWQCAQowHwYDVR0jBBgwFoAUjrE+SRWrx5IE38/Ol+qJtJ4lVREwggEnBgNVHR8EggEeMIIB GjCCARagggESoIIBDoaBxmxkYXA6Ly8vQ049TWVzc2FnaW5nJTIwQ0EsQ049d3NjYXMwMDEyLENO PUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPWNvcmUsREM9ZGlyLERDPXRlbHN0cmEsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZDaHR0cDovL3dzY2Fz MDAxMi5jb3JlLmRpci50ZWxzdHJhLmNvbS9DZXJ0RW5yb2xsL01lc3NhZ2luZyUyMENBLmNybDCC AUEGCCsGAQUFBwEBBIIBMzCCAS8wgbwGCCsGAQUFBzAChoGvbGRhcDovLy9DTj1NZXNzYWdpbmcl MjBDQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29u ZmlndXJhdGlvbixEQz1jb3JlLERDPWRpcixEQz10ZWxzdHJhLERDPWNvbT9jQUNlcnRpZmljYXRl P2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBuBggrBgEFBQcwAoZiaHR0 cDovL3dzY2FzMDAxMi5jb3JlLmRpci50ZWxzdHJhLmNvbS9DZXJ0RW5yb2xsL3dzY2FzMDAxMi5j b3JlLmRpci50ZWxzdHJhLmNvbV9NZXNzYWdpbmclMjBDQS5jcnQwEwYDVR0lBAwwCgYIKwYBBQUH AwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBYBgNVHREEUTBPoCwGCisGAQQBgjcUAgOg HgwcYzc5OTg3OEBjb3JlLmRpci50ZWxzdHJhLmNvbYEfSmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxz dHJhLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEALZDeZpos2zSrCoLRDx1Cu6f7xbqf/Obpi+aAuqJu LiHWw/gwyy0lY9KBa4naedOAA0REylEP5A/fwXQa/wEzGtqY5naaeEurSOiWWTOcsmg8ay9bWSS9 KUzUoaRhYr5Fh1eYU9Gu+RuyzPRoRYE4Iw9kWT0fTSPRWmNTJLX644Ja1qelxQMw1nurrUAyaSEb tR8TFqdegghVhEqHjSWAF/M+DxpXragF4tM1q97tXcKtpSMa+ohibRDocegXru+MhKrFyUm/TP0H kG4q0HiRHTlyXEiPyiNKbCFJxPeh1eOGKKEcABDmOz2tzrQX45QUGagzv8m42jpX1DNEzeyIdTCC BoEwggVpoAMCAQICChdwbt4AAAAAAXkwDQYJKoZIhvcNAQEFBQAwFzEVMBMGA1UEAxMMTWVzc2Fn aW5nIENBMB4XDTA5MDMzMDA0MDMwMFoXDTEwMDMzMDA0MDMwMFowEjEQMA4GA1UEAxMHYzc5OTg3 ODCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk6xFOFUU5KUvl92YXce4jF7DLPOHfb 8HttBGUDqnn1btHtMNsR2+aN4EHYgCkxCk+bVidmI9iael9f+DwuwG3CtidUfnJkSbBMtnt52r/Z yBn9QVwJxPq58BycssAI7qnBSDEQp3Um1vQlUSJP+U89I+5G8QpBParV+uNeMxksZnpb1WwxyHID DJrTfJQpctW3TdKAFJBRxpT+zw/gAGUNWER7H1SSWbAmnLRfODD/EtcnuXKEYOGjT1nAwmb81yZs MHKuHHHwP8ae3M+B6qfsuj9MrsrG/AhwbxvUYUoofxEPZQD8oMGvxMaCdXIziLgaNll4Tu32W1qc 1lohhb0CAwEAAaOCA9IwggPOMAsGA1UdDwQEAwIFIDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3 DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFPdI bbMdMWgxNFd5S4gUmvNtA9m5MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCITUjiKC7d9ThfWD GILGvFyFh7stfoTLh2ODx+odAgFkAgEEMB8GA1UdIwQYMBaAFI6xPkkVq8eSBN/PzpfqibSeJVUR MIIBJwYDVR0fBIIBHjCCARowggEWoIIBEqCCAQ6GgcZsZGFwOi8vL0NOPU1lc3NhZ2luZyUyMENB LENOPXdzY2FzMDAxMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vydmlj ZXMsQ049Q29uZmlndXJhdGlvbixEQz1jb3JlLERDPWRpcixEQz10ZWxzdHJhLERDPWNvbT9jZXJ0 aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9p bnSGQ2h0dHA6Ly93c2NhczAwMTIuY29yZS5kaXIudGVsc3RyYS5jb20vQ2VydEVucm9sbC9NZXNz YWdpbmclMjBDQS5jcmwwggFBBggrBgEFBQcBAQSCATMwggEvMIG8BggrBgEFBQcwAoaBr2xkYXA6 Ly8vQ049TWVzc2FnaW5nJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y29yZSxEQz1kaXIsREM9dGVsc3RyYSxEQz1j b20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw bgYIKwYBBQUHMAKGYmh0dHA6Ly93c2NhczAwMTIuY29yZS5kaXIudGVsc3RyYS5jb20vQ2VydEVu cm9sbC93c2NhczAwMTIuY29yZS5kaXIudGVsc3RyYS5jb21fTWVzc2FnaW5nJTIwQ0EuY3J0MBMG A1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwQwWAYDVR0RBFEw T6AsBgorBgEEAYI3FAIDoB4MHGM3OTk4NzhAY29yZS5kaXIudGVsc3RyYS5jb22BH0phbWVzLkgu TWFuZ2VyQHRlYW0udGVsc3RyYS5jb20wDQYJKoZIhvcNAQEFBQADggEBAA2df1z0HL7kzTTXbX9r YPbQ2LxN339XNf6THqbKXHfEnsj72nIFvflxkpHiR0PDQi9IVTushhY81Oumkb64II3hDqCnWztt fllQDrEQtF9xUVNBISQD9H1i3j8zI5LIiQOaGYdrf5ebEf16g7Y2Apwfo9V9bY09T50ztJvi5W56 cTZEWeXsvYSopvTFT620rro+V549ZBSMAn6qlg1dOpiWCB0MJsCXXp+7kpCTtuM9dafpJRNI5w9S 8QoCyQlfH94U1uRqQ21zixSDLbO0gDDglSLdvsp0tK44+ZRHHzVFzfSpX/Ls0/bKEqXq+ZW3rEPb TfNCgDILTliP0QsYi3YwggcKMIIE8qADAgECAhA9Ft3ZAidOrEiRFBv9SOnSMA0GCSqGSIb3DQEB BQUAMIGnMSEwHwYJKoZIhvcNAQkBFhJSb290Q0FAdGVsc3RyYS5jb20xCzAJBgNVBAYTAkFVMREw DwYDVQQIEwhWaWN0b3JpYTESMBAGA1UEBxMJTWVsYm91cm5lMRAwDgYDVQQKEwdUZWxzdHJhMRkw FwYDVQQLExBOZXR3b3JrIFNlY3VyaXR5MSEwHwYDVQQDExhUZWxzdHJhIEludGVybmFsIFJvb3Qg Q0EwHhcNMDAxMTE2MDIyOTEzWhcNMTAxMTE2MDIzMTU1WjCBpzEhMB8GCSqGSIb3DQEJARYSUm9v dENBQHRlbHN0cmEuY29tMQswCQYDVQQGEwJBVTERMA8GA1UECBMIVmljdG9yaWExEjAQBgNVBAcT CU1lbGJvdXJuZTEQMA4GA1UEChMHVGVsc3RyYTEZMBcGA1UECxMQTmV0d29yayBTZWN1cml0eTEh MB8GA1UEAxMYVGVsc3RyYSBJbnRlcm5hbCBSb290IENBMIICIjANBgkqhkiG9w0BAQEFAAOCAg8A MIICCgKCAgEAnpwjjsFHf+79TWueHlUdxK3+abffdE4bUBL+QuaNnWZ9iPyQU08vqhENwyIJO0nx AXeGLtjKsbzOu3wBxKCuefjb8XSoo4bOQQ5c5Rsf3hs4v+I09zwFgF+pxNV6DpOiwIB9XQgz0lpu joZVBl6m5ugVk+ADio10cD8ug8OyZvUURiHwgigHSUgqPcj+bqlJFMLbdg9mgAxEx5Ty1xRlKJ17 0CMnUeAV419eQrg0+GPCAt7nViNxW4SYR/9riFtMfavvBYjxvHbcq2v3PBfvhGAxFLWChKDm0wg2 qqt4wLm4VNrE+desJF+XOlqBi0IHQy5mE8KhWMMhW6Bbag5mQfPZVYwDXJ+TSprxRTkQ0KYU2vLF nBo0f5gqpcp4tiBRba6VDe/RmGgUUYCaBB4dh7v/Q1yxQrinUOHMqxVepZugobszXin1pRZ/Qy3D tCfJzO6C85gsN+bcGlfzajFLTV9VGo283+0g3HIahQdYG83PvvhZF8eR9+fohwwasYtKKiSl40z5 I46VrainDdjL1l4adwbjnS0nDv3mL9kbSyJLmRpfE5Nb3+BVUFErDV8a23KHr1mdAUMEKHU4Y8Ep g+q9vTVZsAJfRMgNc5+bzd1C65j+1FhOh3xKgwlu1qvux2BAtOYIRwUf59tEuJELM5iszyPThURE my/eapk1SlcCAwEAAaOCAS4wggEqMBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAP BgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQS3FKmReD1ql/Ger9J5nUZcw29+TCBwwYDVR0fBIG7 MIG4MFmgV6BVhlNodHRwOi8vd3NjYXIwMDAxLmNvcmUuZGlyLnRlbHN0cmEuY29tL0NlcnRFbnJv bGwvVGVsc3RyYSUyMEludGVybmFsJTIwUm9vdCUyMENBLmNybDBboFmgV4ZVZmlsZTovL1xcV1ND QVIwMDAxLmNvcmUuZGlyLnRlbHN0cmEuY29tXENlcnRFbnJvbGxcVGVsc3RyYSUyMEludGVybmFs JTIwUm9vdCUyMENBLmNybDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOCAgEAkysT 049btivCdrHQWHbsi7yg1O/gkK4RPY5kS3tbsJiMlYFNxpPuQL30/MKNMNubP6lBNucZBCRK8+J7 XtuBltfznqe6zvWtcNIWUWbBsZlJ7lM/rYuKFkU/EYnK8sCHmDwZtxd53Vb1BGmlGZ8ORJSggZm8 LKqhyQLXTr7fdvSBIfoOEEUhVNPu3qBul+QjtwVmnhYgX4IXxM624nZTs9BoSe++wGJALHZJ5CJb 6FIAC4t5dY2PJMHeAs84kybkmb3LfM1gTEpeZYFrH50pHxsLocapb/gR7K0NPHzQnLc6MeYdIHxm oLWIWEsb4kYKNlhip4ddC2qnwhT7ynp8vWVhrQRwr5LVvmMSSyUIYJn0+QV6q4ptfvO4v2J6RkDv APGJdfx0WD+4N2gQ/xrRGmjJn73efCzpzjffy0SH1Xjj5d5+ofR7wbu6i5iB1aZdeaPj95flfy7e BW3z/3r0MboP624XiDqlLF+FKt8lh0nh38vECPBUh6U9BH5bp2c36my2b1ZdDs/ryg1Rs9o0inpU q7yexHwGIKiEtqKGNGL2Osxm5NDn8OvCY0FsIchdzvCORUYEQV85nbW1SkTcms+QjYfptcA72bdZ KDfpvSK1tArBqWAdUeJlwB9uC6NTSazXTNB3fGgGvNl4y6hi82oRAfaZKKLYuMZd/C2eOuAwggdd MIIFRaADAgECAgphC9E1AAAAAAAaMA0GCSqGSIb3DQEBBQUAMIGnMSEwHwYJKoZIhvcNAQkBFhJS b290Q0FAdGVsc3RyYS5jb20xCzAJBgNVBAYTAkFVMREwDwYDVQQIEwhWaWN0b3JpYTESMBAGA1UE BxMJTWVsYm91cm5lMRAwDgYDVQQKEwdUZWxzdHJhMRkwFwYDVQQLExBOZXR3b3JrIFNlY3VyaXR5 MSEwHwYDVQQDExhUZWxzdHJhIEludGVybmFsIFJvb3QgQ0EwHhcNMDYwNTIzMDMxNDM0WhcNMTAx MTE2MDIzMTU1WjAXMRUwEwYDVQQDEwxNZXNzYWdpbmcgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCwoF8xB3u77NXnoqaWEMkvFMsxiUyCDcfXbUdQzEPsEaj5ldeR4lRBVeiADIDN R0bnvFOGQSrmNK7i5KugI7EfA0h6giZ8Oh3lCx1kpzrPswIJOCwbKpjqgjT6sJXa+plLPmLm2j6v B6Dzye1SotWzeCMWnwmSdIT8LbSsz5QVS7K/eck0CWgIxwiOvgUNGfDNJLfBzFIotvxq1olQL8i2 m6J8s9T9Fx7LGvju9g25M4rghJW9YPGSekJcxHmVEvbYUDNnKQHFJKQ8U/vC5KSgfGrMivQg6O7m ucKnPb8s+1Wp5SkOjOCInaqtlGlWsLRcubOueJgcA/oae7sr1vOFAgMBAAGjggMYMIIDFDAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBSOsT5JFavHkgTfz86X6om0niVVETALBgNVHQ8EBAMCAcYw EAYJKwYBBAGCNxUBBAMCAQAwgeMGA1UdIwSB2zCB2IAUEtxSpkXg9apfxnq/SeZ1GXMNvfmhga2k gaowgacxITAfBgkqhkiG9w0BCQEWElJvb3RDQUB0ZWxzdHJhLmNvbTELMAkGA1UEBhMCQVUxETAP BgNVBAgTCFZpY3RvcmlhMRIwEAYDVQQHEwlNZWxib3VybmUxEDAOBgNVBAoTB1RlbHN0cmExGTAX BgNVBAsTEE5ldHdvcmsgU2VjdXJpdHkxITAfBgNVBAMTGFRlbHN0cmEgSW50ZXJuYWwgUm9vdCBD QYIQPRbd2QInTqxIkRQb/Ujp0jCBwwYDVR0fBIG7MIG4MFmgV6BVhlNodHRwOi8vd3NjYXIwMDAx LmNvcmUuZGlyLnRlbHN0cmEuY29tL0NlcnRFbnJvbGwvVGVsc3RyYSUyMEludGVybmFsJTIwUm9v dCUyMENBLmNybDBboFmgV4ZVZmlsZTovL1xcV1NDQVIwMDAxLmNvcmUuZGlyLnRlbHN0cmEuY29t XENlcnRFbnJvbGxcVGVsc3RyYSUyMEludGVybmFsJTIwUm9vdCUyMENBLmNybDCCARUGCCsGAQUF BwEBBIIBBzCCAQMwfgYIKwYBBQUHMAKGcmh0dHA6Ly93c2NhcjAwMDEuY29yZS5kaXIudGVsc3Ry YS5jb20vQ2VydEVucm9sbC9XU0NBUjAwMDEuY29yZS5kaXIudGVsc3RyYS5jb21fVGVsc3RyYSUy MEludGVybmFsJTIwUm9vdCUyMENBLmNydDCBgAYIKwYBBQUHMAKGdGZpbGU6Ly9cXFdTQ0FSMDAw MS5jb3JlLmRpci50ZWxzdHJhLmNvbVxDZXJ0RW5yb2xsXFdTQ0FSMDAwMS5jb3JlLmRpci50ZWxz dHJhLmNvbV9UZWxzdHJhJTIwSW50ZXJuYWwlMjBSb290JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA A4ICAQB2Gd568tcY04j08RWRSd32wdJeS42EDLl9mDqFn8xOyF4ODrPNKCymhp5ZxKQfE06YQBCa qvJBVDiV+qFehjvEns0RmZwvAbZalqWeSwu66P8NbbXu0108ubTyiECoIeRGZIHXblDQ3BfkR3e4 8Ise+DOPCIA/PjDdKJ3jtR+1XTL0f/i191k/bjGts+07MOQWuBFssTL0b0MD5l/fs2MDXWClozlM dgI407z+e6bk5JyiwdEALM0TlXSzim/SfGu70Ks20XDUpDiV/1RPE/YVDbVsCdVeG5S0tuQu3PGw dDpb4ROGvrusT4fIP/uYh7/vRwZp6LCf2e8rUBgWo+mPva0FJm5uiJgmHkXX+GV7LVEfAjtlE0gU pfsnx/2PUbyMi9AH1kZxnlJvdD2yL/qTwMb087dqWigmTPO+pIq4MZaTQdQFxEfvHdW6fx2yMUcG 15kw7lmYcYD8zSCbWMPZX9c3sQTWo5OK70ZPpA3xnHwyMZbpXCZ84BE8M9JoW32DHMGIobuSEgh8 DKdrfaMS9K2VcYRS79oA19QASVLnIZGkSWyDsfJ1FIDWPRz7GLZVeiqFObL6pWjH6zi5pHNX3nc+ u/XowTcy4XDEAaNN4apuxNuzi4Rhw+8tCiG3h4YIbx9B8jjXno/0O5IPSMx4eJfoZikbLJKE9xMn uSmSrjGCAoQwggKAAgEBMCUwFzEVMBMGA1UEAxMMTWVzc2FnaW5nIENBAgoXcUC1AAAAAAF6MAkG BSsOAwIaBQCgggE0MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEw MDIwNDA2MTkxMVowIwYJKoZIhvcNAQkEMRYEFIPS8Vysjv2VRJ3KIetP+hYOL9JAMDQGCSsGAQQB gjcQBDEnMCUwFzEVMBMGA1UEAxMMTWVzc2FnaW5nIENBAgoXcG7eAAAAAAF5MDYGCyqGSIb3DQEJ EAILMSegJTAXMRUwEwYDVQQDEwxNZXNzYWdpbmcgQ0ECChdwbt4AAAAAAXkwZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwDQYJKoZIhvcNAQEBBQAEggEAiqsc kXq30sZ47QM7ReWfuKdgz7+gAd7+FNjUlgdEHnZBNjFW6J262+s6YwvAgzmnqdrGDZIiEOUnlnM2 KPD7vvkJ6Nuo7q20NJpnnYqnl6gziSe1d9F/fGp8Wu8rh/NIQ91S8Fk8OgXT+CLgMEbd61HlaJ9R +6AIZoCrXQzYBAKUhapz/mpE26iN9UKrxOaarMnz3J1n5lx9cNk7oaHjf7jY1RsMqYh3bLTLpbAc nUd45/fFB9RJ0cP3I4Owq2CXH4bGWMyq6ng2ZvSpLWFwbhwus3M4u4B+HMHacfIobsGMTnwfdnWD 7l7LtYYq7/gxzrrdS2/ewjEJZuzQacyRMwAAAAAAAA== ------=_NextPart_000_000E_01CAA5BE.2B19A270-- From eran@hueniverse.com Wed Feb 3 22:35:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D1A3A6CF5 for ; Wed, 3 Feb 2010 22:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_53=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 eGT4o9-BcpbL for ; Wed, 3 Feb 2010 22:35:23 -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 7B0D93A6CB1 for ; Wed, 3 Feb 2010 22:35:23 -0800 (PST) Received: (qmail 16465 invoked from network); 4 Feb 2010 06:36:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Feb 2010 06:36:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 3 Feb 2010 23:35:53 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Wed, 3 Feb 2010 23:35:41 -0700 Thread-Topic: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge? Thread-Index: AcqlWhSJjC8N8iQJRoi/kLDAXab+zQACb6KA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2DA1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437899D22BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112503E4238@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B7E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge? X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Feb 2010 06:35:25 -0000 Just to be clear, I was referring to the case where a client can figure out= how to obtain authorization and then authenticate without any pre-configur= ation. This means giving a discovery flow for each type of authorization op= tion (desktop, mobile, web, etc.) with all the parameters needed for each (= pop-up size, redirection URIs, extension parameters, digital TOS). EHL > -----Original Message----- > From: John Panzer [mailto:jpanzer@google.com] > Sent: Wednesday, February 03, 2010 9:23 PM > To: Eran Hammer-Lahav > Cc: Manger, James H; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an > authentication challenge? >=20 > Au contraire (speaking only for myself). >=20 > On Wednesday, February 3, 2010, Eran Hammer-Lahav > wrote: > > It doesn't feel like we have much interest at this level of interoperab= ility at > this point. > > > > EHL > > > >> -----Original Message----- > >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > >> Sent: Wednesday, February 03, 2010 5:38 AM > >> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > >> Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an > >> authentication challenge? > >> > >> An authentication challenge (WWW-Authenticate header) defined in a > >> spec for an authentication mechanism should be present, but only with > >> details specific to that mechanism (eg list of MAC algorithms). > >> > >> I think there should be a totally separate WWW-Authenticate header > >> specifically saying "a delegation flow can be used to access this > >> resource". It should include details such as the URI to redirect the u= ser to. > >> > >> We really need this if we want to offer a web-style protocol with any > >> semblance of interoperability. If we omit it because "clients need to > >> know lots of other API-specific details anyway" then we wont have a > >> path to get past that limitation in future. > >> > >> > >> -- > >> James Manger > >> > >> > -----Original Message----- > >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> > Behalf Of Eran Hammer-Lahav > >> > Sent: Thursday, 28 January 2010 2:12 PM > >> > To: OAuth WG (oauth@ietf.org) > >> > Subject: [OAUTH-WG] What are the primary criteria in issuing an > >> > authentication challenge? > >> > > >> > An authentication challenge (to make sure we are all on the same > >> > page) is something the server sends to the client when denying > >> > access to a protected resource. The challenge can be as simple as > >> > "use Basic", or complex as "use Digest with the following > >> > parameters". OAuth 1.0 doesn't really use a challenge because it > >> > was created for cases where the API calls are preconfigured and > >> > hardcoded into the client. The client should never receive an OAuth > >> > challenge the way the protocol was originally designed. > >> > > >> > In my token authentication draft I tried to propose multiple > >> > mechanisms (not fully baked yet) for issuing a challenge and > >> > allowing the client to figure out what to do next. Before producing > >> > another draft, it is important to figure out what challenge model > >> > we want to use. Here are the general options I came up with: > >> > > >> > 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is > >> > left on its own to figure out what to do next. > >> > > >> > 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you > >> > need a new token go there". It is still not clear how this will > >> > help the client given that getting a token is likely it include > >> > many different options, and to fully address this we need to dig > >> > deep into discovery which was left out of scope. > >> > > >> > 3. Token attributes - the server informs the client of the kind of > >> > tokens accepted (based on their cryptographic properties or the > >> > resource-set/realm they are good for). This is just like #2 but > >> > with the ability for the server to support more than one token type > >> > per resource. > >> > > >> > Question: Is the ability for a single token-protected resource to > >> > support more than one token type (say Plain+SSL *and* HMAC-256) > >> > part of our requirements? If not, there is no reason at all for the > >> > challenge to include anything other than #1 or #2 (probably defined > >> > as a future extension). > >> > > >> > EHL > >> > > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > ht=A0 >=20 > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer From eran@hueniverse.com Wed Feb 3 22:43: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 347D23A6CFA for ; Wed, 3 Feb 2010 22:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 3My5s34JJwvZ for ; Wed, 3 Feb 2010 22:43: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 DA1773A6CC3 for ; Wed, 3 Feb 2010 22:43:44 -0800 (PST) Received: (qmail 23796 invoked from network); 4 Feb 2010 06:44:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Feb 2010 06:44:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 3 Feb 2010 23:44:16 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "OAuth WG (oauth@ietf.org)" Date: Wed, 3 Feb 2010 23:44:04 -0700 Thread-Topic: Comment on draft-hammer-http-token-auth-01 Thread-Index: AcqlNcPYYGtgKuxYSvaWZIMKPEOn5gAGoMKQAAKRi0AAAnipcA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2DA4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E112503E48B3@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2D92@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112504AE32A@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112504AE32A@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Comment on draft-hammer-http-token-auth-01 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Feb 2010 06:43:46 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFuZ2VyLCBKYW1lcyBI IFttYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbV0NCj4gU2VudDogV2VkbmVz ZGF5LCBGZWJydWFyeSAwMywgMjAxMCAxMDoxOSBQTQ0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXY7 IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNCj4gU3ViamVjdDogUkU6IENvbW1lbnQgb24gZHJh ZnQtaGFtbWVyLWh0dHAtdG9rZW4tYXV0aC0wMQ0KPiANCj4gPiBJIGRpc2FncmVlLiBWb2lkaW5n IGEgdG9rZW4gdG8gc3RvcCBzdXBwb3J0aW5nIGFuIGFsZ29yaXRobSBpcw0KPiA+IHBlcmZlY3Rs eSByZWFzb25hYmxlIGFuZCBtaWdodCBub3QgZXZlbiByZXF1aXJlIHVzZXIgaW52b2x2ZW1lbnQg aWYgdGhlDQo+ID4gcmVmcmVzaCBtZWNoYW5pc20gaXMgKGFkb3B0ZWQgYW5kKSB1c2VkLiBBbmQg aWYgdGhlIHJlYXNvbiBmb3IgdGhpcyBpcw0KPiA+IGEgYnJva2VuIGFsZ29yaXRobSwgd2VsbCwg SSB3b3VsZCBob3BlIHRoZSB0b2tlbnMgYXJlIHZvaWRlZCwgbm90IGp1c3QNCj4gPiB1c2VkIHdp dGggdGhlIHNhbWUgc2VjcmV0IGFuZCBuZXcgYWxnb3JpdGhtLg0KPiANCj4gTWlncmF0aW5nIHRv IG5ldyBhbGdvcml0aG1zIGlzIGEgdmVyeSBzbG93IGFuZCB0b3J0dW91cyBwcm9jZXNzIC0tIHBh cnRseQ0KPiBiZWNhdXNlIGFuIGFsZ29yaXRobSBpcyByYXJlbHkgY29tcGxldGVseSBicm9rZW4g aW4gYSBzaW5nbGUgaW5zdGFudC4gRXZlbg0KPiBNRDUNCj4gaXMgc3RpbGwgc2FmZSBmb3Igc29t ZSBwdXJwb3Nlcy4gQmluZGluZyBzZWNyZXRzIHRvIGhhc2ggYWxnb3JpdGhtcyBpbiB0aGUNCj4g cHJvdG9jb2wgKG5vdCBqdXN0IGFzIGEgY2hvaWNlIGJ5IG9uZSBzZXJ2ZXIpIHdpbGwgbWFrZSBt aWdyYXRpb25zIHRoYXQgbXVjaA0KPiBoYXJkZXIuDQoNCldoYXQgZG8geW91IG1lYW4gYnkgJ2Jp bmRpbmcgc2VjcmV0cyB0byBoYXNoIGFsZ29yaXRobXMgaW4gdGhlIHByb3RvY29sIj8NCiANCj4g PiBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgIm9uZSBhcHAgbWF5IG9ubHkgc3VwcG9y dCBTSEEtMSwgd2hpbGUNCj4gPiBhbm90aGVyIG9ubHkgc3VwcG9ydHMgU0hBLTI1NiIuIEFyZSB5 b3Ugc3VnZ2VzdGluZyBzb21ldGhpbmcgbGlrZSBhDQo+ID4gY29tcGFueSB3aXRoIGNlbnRyYWxp emVkIHRva2VuIHNlcnZpY2UgYnV0IHdoZXJlIGVhY2ggc2VydmljZSB1c2luZyBhDQo+ID4gZGlm ZmVyZW50IHNldCBvZiBhbGdvcml0aG0sIGJ1dCBzdGlsbCBzaGFyaW5nIHRoZSBzYW1lIHRva2Vu IGFjcm9zcw0KPiA+IHNlcnZpY2VzPyBTb3VuZHMgbGlrZSBhIGNvbXBhbnkgaW4gbmVlZCBvZiBu ZXcgbWFuYWdlbWVudC4NCj4gDQo+IFRoYXQgaXMgZXhhY3RseSB3aGF0IEkgYW0gc3VnZ2VzdGlu Zy4gT2xkIGFwcHMsIG5ldyBhcHBzLCBvdXRzb3VyY2VkIGFwcHMsDQo+IGxlZ2FjeSBhcHBzLCB3 aGl0ZS1sYWJlbCBhcHBzIHJlYmFkZ2VkLCBhcHAgaW4gdGhpcyBsYW5ndWFnZSwgYXBwIGluIHRo YXQNCj4gbGFuZ3VhZ2UsIGFwcHMgaW4gdGhlIGNsb3VkLCBhcHBzIGZyb20gYSBtZXJnZXIuLi4N Cj4gVGhlcmUgaXMgbm8gd2F5IEkgZXhwZWN0IHBlcmZlY3QgY29uc2lzdGVuY3kgaW4gc3VwcG9y dGVkIGFsZ29yaXRobXMsIGJ1dCBJDQo+IGRvDQo+IHdhbnQgdG8gdHJ5IHRvIGhhdmUgU1NPIGFj cm9zcyB0aGVzZSBhcHBzIGFuZCBhIGNlbnRyYWwgdG9rZW4gc2VydmljZSBmb3INCj4gYWNjZXNz aW5nIHRoZWlyIEFQSXMuDQo+IA0KPiBJIGRvbid0IHdhbnQgdG8gaGF2ZSB0byB1cGdyYWRlIGV2 ZXJ5IHNpbmdsZSBhcHAgKGV2ZW4gdGhlIG5pY2hlIG5lYXINCj4gZW5kLW9mLWxpZmUgb25lcykg dG8gc3VwcG9ydCBhIG5ldyBhbGdvcml0aG0gYmVmb3JlIEkgY2FuIHN0YXJ0IHVzaW5nIGl0DQo+ IGFueXdoZXJlLiBJZiBhIGNyZWRlbnRpYWwgYm91bmQgdG8gYSBuZXcgYWxnb3JpdGhtIGlzIGlz c3VlZCB0byBhIGNsaWVudCwgdGhhdA0KPiBjbGllbnQgY2FuIG5vIGxvbmdlciBhY2Nlc3MgYXBw cyB0aGF0IGhhdmUgbm90IGJlZW4gdXBncmFkZWQgLS0gb3IsIHdvcnN0DQo+IHN0aWxsLCB0aGUg Y2xpZW50IGlzIGV4cGVjdGVkIHRvIG1hbmFnZSBtdWx0aXBsZSBhcHAtc3BlY2lmaWMgY3JlZGVu dGlhbHMNCj4gd2hlcmUgcHJldmlvdXNseSB0aGV5IHVzZWQgb25lLg0KDQpUaGlzIGlzIGEgcXVl c3Rpb24gZm9yIHRoZSBncm91cCAtIGlzIHRoaXMgYSB1c2UgY2FzZSB3ZSB3YW50IHRvIHN1cHBv cnQ/IElzIGl0IHdvcnRoIHRoZSBjb21wbGV4aXR5IGl0IGFkZHM/DQogDQo+ID4gPiBCcmVha2lu ZyB0aGUgZXhpc3RpbmcgbW9kZWwgb2YgSFRUUCBhdXRoZW50aWNhdGlvbiAoMSBzY2hlbWUgcGVy DQo+ID4gPiBtZWNoYW5pc20pIGlzIHRoZSB3cm9uZyBhcHByb2FjaC4NCj4gPg0KPiA+IE5vdCBz dXJlIHdoYXQgeW91IG1lYW4uDQo+IA0KPiBJbiBtb3N0IEhUVFAgYXV0aGVudGljYXRpb24gbWVj aGFuaXNtcywga25vd2luZyB0aGUgc2NoZW1lIGlzIHN1ZmZpY2llbnQNCj4gdG8NCj4ga25vdyB0 aGUgc29ydCBvZiBjcmVkZW50aWFsIHJlcXVpcmVkLCB0aGUgc2VjdXJpdHkgcHJvcGVydGllcywg YW5kIGlmIHlvdSBoYXZlDQo+IHRoZSBjb2RlIHRvIHN1cHBvcnQgaXQuIFdpdGggVG9rZW4sIHRo ZSBjcmVkZW50aWFscyBtaWdodCBiZSBqdXN0IGEgdG9rZW4sIGENCj4gdG9rZW4gYW5kIHNoYXJl ZCBzZWNyZXQsIG9yIGEgdG9rZW4gYW5kIGFzeW1tZXRyaWMga2V5LiBXaXRoIFRva2VuLCB5b3UN Cj4gbWF5IG9yDQo+IG1heSBub3QgYmUgc2FmZSBmcm9tIHBhc3NpdmUgYXR0YWNrcywgb3IgYWN0 aXZlIGF0dGFja3M7IG1heSBvciBtYXkgbm90DQo+IHJlcXVpcmUgbG93ZXItbGF5ZXIgc2VjdXJp dHk7IG1pZ2h0IGhhdmUgdG8gZG8gY29tcHV0YXRpb25hbGx5LWludGVuc2l2ZQ0KPiBwdWJsaWMt a2V5IGNyeXB0byBvciBtaWdodCBvbmx5IHJlcXVpcmUgdHJpdmlhbCBjb3B5ICduIHBhc3RlLg0K DQpUaGF0J3MgT0F1dGggMS4wIHRvZGF5LCBqdXN0IHRvIGJlIGNsZWFyLg0KDQo+IFlvdSBoYXZl IGJyb2tlbiB0aGUgbW9kZWwgd2hlcmUgdGhlIHNjaGVtZSBtZWFucyBzb21ldGhpbmcgYWJvdXQg dGhlDQo+IHR5cGUgb2YNCj4gY3JlZGVudGlhbCBhbmQgdGhlIHNlY3VyaXR5Lg0KDQpOb3QgaW4g cHJhY3RpY2UuIFRoZSBzZXJ2ZXIga25vd3MgZXhhY3RseSB3aGF0IGtpbmQgb2YgY3JlZGVudGlh bHMgaXQgaXMgaXNzdWluZyBhbmQgdGhlIGNsaWVudCBrbm93cyBleGFjdGx5IHdoYXQga2luZCBv ZiBjcmVkZW50aWFscyBpdCBpcyB1c2luZy4gVG8gc3VnZ2VzdCB0aGF0IGp1c3QgYmVjYXVzZSB0 aGUgc2NoZW1lIGRvZXMgbm90IGluY2x1ZGUgc29tZSBsYWJlbCBtYWtlcyBpdCBicm9rZW4gaXMg Z29pbmcgdG9vIGZhci4gQWxsIEkgZGlkIHdhcyByZW1vdmUgdGhlIGFiaWxpdHkgdG8gbmVnb3Rp YXRlIHRoZSBhdXRoZW50aWNhdGlvbiBtZXRob2QsIG5vdCBtYWtlIGl0IGNvbXBsZXRlbHkgYXJi aXRyYXJ5Lg0KDQpBY2NvcmRpbmcgdG8geW91ciBhbmFseXNpcywgYWRkaW5nIHRoZSBhYmlsaXR5 IHRvIG5lZ290aWF0ZSB0aGUgdHlwZSBvZiBjcmVkZW50aWFscyBvciBhbGdvcml0aG0gaGFzIHRo ZSBleGFjdCBzYW1lIHByb2JsZW0gYmVjYXVzZSB5b3UgY2FuJ3QgdGVsbCB3aGF0IHRoZSBjbGll bnQgd2lsbCBjaG9vc2UuIEluIG15IGRyYWZ0LCB0aGUgY2xpZW50IGlzIGxpbWl0ZWQgdG8gd2hh dCB0aGUgc2VydmVyIGlzc3VlZCBpbiB0aGUgZmlyc3QgcGxhY2UgYW5kIHdoYXQgaXQgaXMgd2ls bGluZyB0byBhY2NlcHQuDQoNCklmIHRoaXMgaXMgYSByZWFsIGlzc3VlLCBpdCBjYW4gb25seSBi ZSBzb2x2ZWQgYmUgY3JlYXRpbmcgYSBzY2hlbWUgcGVyIGNyZWRlbnRpYWwgdHlwZSBhbmQgcG90 ZW50aWFsbHkgYWxnb3JpdGhtLg0KDQpFSEwNCg0K From grastogi@adobe.com Wed Feb 3 23:04: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 163843A6D09 for ; Wed, 3 Feb 2010 23:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.613, 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 4TPU44IT-z+5 for ; Wed, 3 Feb 2010 23:04:35 -0800 (PST) Received: from psmtp.com (exprod6ob114.obsmtp.com [64.18.1.32]) by core3.amsl.com (Postfix) with ESMTP id 19D363A6D08 for ; Wed, 3 Feb 2010 23:04:35 -0800 (PST) Received: from source ([192.150.8.22]) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKS2pxrqrb9JPK657g6+nrUTMBtEGXJI+t@postini.com; Wed, 03 Feb 2010 23:05:20 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id o1475As5019115; Wed, 3 Feb 2010 23:05:16 -0800 (PST) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id o147587o004588; Wed, 3 Feb 2010 23:05:09 -0800 (PST) Received: from NAMBX02.corp.adobe.com ([10.8.127.96]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Wed, 3 Feb 2010 23:05:08 -0800 From: Gaurav Rastogi To: "romeda@gmail.com" Date: Wed, 3 Feb 2010 23:05:05 -0800 Thread-Topic: Use Case: Adobe: HTTP based media delivery Thread-Index: AcqlaGIqauX6/pEVRYiTLfFJpqTLhQ== Message-ID: <2ED43C4E-BE7D-492E-B135-64C5E83577F1@adobe.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2ED43C4EBE7D492EB13564C5E83577F1adobecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Use Case: Adobe: HTTP based media delivery X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Feb 2010 07:04:37 -0000 --_000_2ED43C4EBE7D492EB13564C5E83577F1adobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Blaine, Here is details on the use case regarding http token authentication based o= ut of media delivery workflow currently being used by Adobe, several major = US broadcasting companies, and CDN vendors. We are hoping to use http token= authentication to solve some of the major pain points around media syndica= tion and IPTV use cases. thanks, Gaurav Adobe Systems. On Jan 29, 2010, at 11:58 AM, Gaurav Rastogi wrote: 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_2ED43C4EBE7D492EB13564C5E83577F1adobecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Blaine,

<= div>Here is details on the use case regarding http token authentication bas= ed out of media delivery workflow currently being used by Adobe, several ma= jor US broadcasting companies, and CDN vendors. We are hoping to use http t= oken authentication to solve some of the major pain points around media syn= dication and IPTV use cases.

thanks,
Gau= rav

Adobe Systems.

On Jan 29= , 2010, at 11:58 AM, Gaurav Rastogi wrote:

This proposal is to allow u= se 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 po= rt number in normalized request string
creation. Another possible approa= ch could be to allow modifications
of the subdomains as consistent with = the name server RFC. 

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

In cas= e of HTTP media streaming a single content delivery may comprise
of hund= reds of individual http fragments served that are delivered
over multipl= e network connections using multiple media assets. In
addition, Advertis= ing, DRM and License server API/interaction may also
be involved.
When dynamic streaming or multi-bit rate media is being streamed then
f= ragments from different versions of the asset are requested based on
rea= l time network and client feedback. Client re-authorization can
result i= n high a latency and non-realtime system degrading the user
experience i= n wide variety of rich media solutions delivered over the
internet.
<= br>In several load balancing solutions like CENAME or request redirectionmay modify server URI based on runtime considerations. Many CDN
workfl= ows and global Internet services use such schemes. Having
mandatory host= name, which could have been modified, restricts use of
HTTP token obtain= ed before the load balancing decision was made.
   
Example workflow
     +---+      =                     &nbs= p;      +---------------+
     | C |--(A)-= ----- credentials --------->| Authorization |
     | &= nbsp;l  |<-(B)------ Access Token ---------| Server     &= nbsp;  |
     | i |         &nbs= p;                     &n= bsp;  +---------------+
     | e |
   &= nbsp; | n |  +---+            Access Tok= en          +---------------+
   &nbs= p; | t |  | W |--(C)----- in HTTP header ------->| Protected  =   |
     |   |  | e |<-(D)------ API r= esponse ---------| Resource[0]   |
     |   |-&= gt;| b |                   &nb= sp;              +---------------+
&n= bsp;    |   |  |   |         &= nbsp;  Access Token          +---------------= +
     |   |<-| S |--(E)----- in HTTP header ----= --->| Protected     |
     |   |  = | e |<-(F)------ API response ---------| Resource[i]   |
 &= nbsp;   |   |  | r |           &nbs= p;                     &n= bsp;+---------------+
     |   |  | V |   =          Access Token         =  +---------------+
     |   |  | i |--(G)-= ---- in HTTP header ------->| Protected     |
   =   |   |  | c |<-(H)------ API response ---------| Resourc= e[N]   |
     |   |  | e |     &= nbsp;                    =        +---------------+
     +---+ =  +---+
                = ;             Figure 1.
In the above Figure 1,= client uses a webservice which performs a single
authorization to obtai= n 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 used.
C,D: Request for license to decrypt the HD conte= nt 
E,F: Multiple requests for the media fragments for HD contentG,H: Change request for lower bit-rate content in case there is networkcongestion or need for lower resources on client. This request may happen= after
30 mins of the start of the rich media experience session.
Thanks= ,
Gaurav= Rastogi
Adobe Systems



= --_000_2ED43C4EBE7D492EB13564C5E83577F1adobecom_-- From eran@hueniverse.com Wed Feb 3 23:42:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697A528C145 for ; Wed, 3 Feb 2010 23:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, J_CHICKENPOX_45=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 cwmmw53pQrPe for ; Wed, 3 Feb 2010 23:42:25 -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 2A75F28C130 for ; Wed, 3 Feb 2010 23:42:25 -0800 (PST) Received: (qmail 8185 invoked from network); 4 Feb 2010 07:43:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Feb 2010 07:43:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 4 Feb 2010 00:43:00 -0700 From: Eran Hammer-Lahav To: Dan Winship Date: Thu, 4 Feb 2010 00:42:42 -0700 Thread-Topic: [OAUTH-WG] Token Access Authentication Scheme Draft Thread-Index: Acp4OJTdeQYtySL6T36DU+nkRu6m1gtG8XNg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2DA8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1EA213.2040902@gmail.com> In-Reply-To: <4B1EA213.2040902@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 07:42:26 -0000 Thanks Dan. > -----Original Message----- > From: Dan Winship [mailto:dan.winship@gmail.com] > Sent: Tuesday, December 08, 2009 11:00 AM > If Token/OAuth is not intended for use with Proxy-Authenticate/Proxy- > Authorization, then you should say that explicitly near the beginning, an= d if > not, then everywhere you say "WWW-Authenticate" or "Authorization", you > need to allow for the proxy versions as well. (Maybe just by saying > "whenever I say WWW-Authenticate, I mean 'either WWW-Authenticate or > Proxy-Authenticate'.") I'll get to this if this draft ever makes it to the other side. > I know you said you don't care about typos, but "OWF" should be "OWS". >=20 > "rsassa-pkcs1-v1.5-sha-256" is way too long a name. :) Trying to be descriptive. The current RSA-SHA1 means nothing without readin= g the spec (it might as well be 'R1'). =20 > The grammar for method-list says >=20 > method-list =3D "method" "=3D" <"> 1#method-name <"> >=20 > where "1#method-name" in RFC2616 ABNF means a comma-delimited list of > method-name. But the text (4.2) and the example quoted above use a > space-delimited list. (Likewise with coverage-list.) Right. I wanted it to be space-delimited. =20 > The first paragraph of section 5 seems to say that clients MUST include a > Authorization header when requesting a protected resource even if they > don't know that it's protected. :) Changed to 'when making an authenticated request'. > In theory, the information in the Authentication-Error response could jus= t be > included in WWW-Authenticate... I am actually going to try and use Authentication-Info (expending its use b= eyond Digest and making it applicable for errors, not just success). Keepin= g this in a separate header makes it easier I think to parse the challenge.= No strong feelings here. > If error-message is supposed to be localized then you should allow for th= e > RFC 2183 grammar (or eventually, the grammar from the RFC that draft- > reschke-rfc2183-in-http becomes). OK. > The "normalized request string" says it includes both the hostname and th= e > request URI, which would be redundant. Maybe when you say "request > resource URI" you mean just the Request-URI production from the Request- > Line (ie, the path+query), not the actual complete request URI? Yeah, that's what I mean. > You should clarify that. Although if the user is behind a proxy then the > Request-URI will be a complete URI rather than just the path+query. So yo= u > might want to say something like "the path and query components of the > request URI, as they appear in the Request-Line"? The request Request-URI exactly as it appears on HTTP Reque= st-Line as defined by RFC2616> section 5.1.2. > There have been interoperability problems with Digest auth digest > computation because people weren't sure if the quotes around attribute > values were considered part of the value or not when computing the hash. > You should be explicit. We didn't get this one in OAuth 1.0 (plenty of other issues)... seems like = an odd thing to fail on. I'll note it. > "Any authentication attribute, with the exception of the "auth", which is > assigned a value (including default values), are added to the normalized > request string as follows" is hard to understand. I think what you mean i= s > "Any attribute which is present in the Authorization header, with the > exception of "auth", is added to the normalized request string as follows= ". Ok. > Hm... although 7.1 seems to suggest something else. > I'm not at all sure what attributes are supposed to be included in the > normalized request string now. Fixed. > Would probably be good to have an example of computing the string. If this makes it to the other side, I'll add plenty of examples in the spir= it of draft-hammer-oauth. EHL From eran@hueniverse.com Wed Feb 3 23:49: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 C33F03A6CBB for ; Wed, 3 Feb 2010 23:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 4M3utKRdJbdI for ; Wed, 3 Feb 2010 23:49:52 -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 A760F3A6818 for ; Wed, 3 Feb 2010 23:49:52 -0800 (PST) Received: (qmail 14344 invoked from network); 4 Feb 2010 07:50:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Feb 2010 07:50:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 4 Feb 2010 00:50:23 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Thu, 4 Feb 2010 00:50:12 -0700 Thread-Topic: [OAUTH-WG] Token Access Authentication Scheme Draft Thread-Index: Acp4ms7oD/YkANJTSJO/lj4DkhJWNAs0u1OA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2DA9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293CC2@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] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 07:49:53 -0000 First, congrats on the new member of the Eaton family. > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Tuesday, December 08, 2009 10:43 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft >=20 > On Mon, Dec 7, 2009 at 11:52 PM, Eran Hammer-Lahav > wrote: > > Can you list the use cases it doesn't meet? This is largely a cosmetic > > rewrite of 1.0 with the exception of directly supporting form-encoded > > parameters which is still being discussed. Your reference is to a post = about > mostly non-HTTP use cases. >=20 > There are basically two use cases for the crypto in OAuth 1.0, and one ma= jor > problem. >=20 > Major problem: people can't figure out the signature base string. > The new authentication spec does nothing to fix this, which is a sham= e. It is > solvable. Can you offer alternatives other than including a base64 copy of what is be= ing signed. > Use case #1: security for people who won't use https. > We seem to have concluded that this isn't achievable. [1] HTTPS will be a required part of the protocol. The question is, are we goin= g to accommodate the case where HTTPS is not desirable for every protected = resource request? There seems to be consensus that yes. > Use case #2: security for people who need to send messages through > untrusted third-parties. > The new authentication spec makes this much, much harder. > > Here are a few examples of places where people are using OAuth to send > messages through untrusted third-parties. Every single one of these use > cases is broken by the token-auth spec [2]. If we can't solve these prob= lems, > there is very little point in message authentication at all. >=20 > For example: > - signed URLs embedded in the browser [3] > - opensocial identity parameters [4] > - google-specific identity parameters [5] > - intermediate xmpp servers [6] > - intermediate sip servers [6] What about the draft breaks these? Is it the need to access the raw HTTP re= quest URI? That is the only difference between the token scheme and the cur= rent OAuth signature base string. This wasn't a new idea - I have asked abo= ut this more than once and the consensus was that it is not a problem. If i= t is, it certainly makes a difference and the side effect was not intention= al. EHL > We should be trying to make those use cases *easier*, not make them > impossible. If we push a new OAuth spec that drops these use cases, we'v= e > done more harm than good. >=20 > Cheers, > Brian >=20 > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00762.html > [2] http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt > [3] http://www.ietf.org/mail-archive/web/oauth/current/msg00689.html > [4] http://www.opensocial.org/Technical-Resources/opensocial-spec- > v09/Gadgets-API-Specification.html#gadgets.io.makeRequest > [5] > http://code.google.com/apis/accounts/docs/OAuth.html#GoogleAppsOAut > h > [6] http://www.ietf.org/mail-archive/web/oauth/current/msg00513.html From eran@hueniverse.com Thu Feb 4 00:02: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 7FEFB3A6D28 for ; Thu, 4 Feb 2010 00:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 8zuGxEjpHQei for ; Thu, 4 Feb 2010 00:02: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 7CF823A6D27 for ; Thu, 4 Feb 2010 00:02:12 -0800 (PST) Received: (qmail 26148 invoked from network); 4 Feb 2010 08:02:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Feb 2010 08:02:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 4 Feb 2010 01:02:54 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Thu, 4 Feb 2010 01:02:32 -0700 Thread-Topic: [OAUTH-WG] Token Access Authentication Scheme Draft Thread-Index: Acp4PLko/0KP5ePvTJ+k8i2S5V3xJwtMkXBQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2DAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 08:02:13 -0000 Thanks John. > -----Original Message----- > From: John Panzer [mailto:jpanzer@google.com] > Sent: Tuesday, December 08, 2009 11:29 AM > Suggestion: It would be better to start with simple examples (bearer toke= n) > which avoids the need to wade through concepts like timestamp > synchronization and authentication coverage in order to understand the > simplest possible flow? =A0(E.g., the example in 1.2.) I am not worried about examples at this point. There will be plenty more if= this draft is adopted. > Suggestion: Make it clear up front that protected resources are allowed a= nd > encouraged to put a WWW-Authenticate: header on all requests (even ones > that return 200 for read-only access) to indicate what authentication is > allowed in general. =A0(The equivalent of the "login" link on web pages t= hat > present a read-only view.) Is this consistent with common practice? > In general, I think that much of the text could be made simpler by separa= ting > out the coverage=3D"none" case from the other cases. =A0At the moment the > only method under discussion with coverage=3D"none" is bearer token. =A0I= think > that's all there ever will be. =A0If that's correct, perhaps separating o= ut things > that way would lead to a simpler reading experience (for the bearer token= - > users for sure, and possibly for everybody else as they don't have to wor= ry > about the special case of coverage=3D"none" over and over again.) Agreed. I still need to rework the 'none' methods. =20 > Section 5: "A client making a request for a protected resource either dir= ectly, > or in retrying a request after receiving a 401 status code > (Unauthorized) with a token challenge, MUST include at least one > "Authorization" header field including token scheme credentials." > - This could be read as forbidding clients from querying protected resour= ces > before figuring out what Authorization: header to use (as they sometimes > need to make an initial request to discover that the resource is > protected). =A0Possibly just rewording to "credentialled request"? =A0Wha= t is the > right terminology here? Authenticated request. > Suggestion: =A0Calling the token method "none" is odd and jarring. =A0It = makes me > think about the classic routine "Who's on first?". =A0How about "bearer"?= =A0As in, > the method for request validation is to simply check that it bears the to= ken. Plain, bearer, unsigned, blue, whatever. Don't care. Others ok with 'bearer= '? > "relying solely on the > value of the token identifier to authenticate the client" >=20 > Surely we are authenticating the request in all these > methods? =A0(Authenticating the client may be a side effect, but it is ne= ither > necessary nor sufficient.) Fixed. > Suggestion: =A0Add a note (SHOULD) about using SSL / TLS when discussing = the > bearer token option, either within this section or in the security > considerations section (couldn't find one after some searching). =A0It's = implied > by the discussion in section 8.1 but it's difficult to parse out. I'm hoping to make this a MUST. > "The "coverage" > attribute MUST be set to "none" but MAY be omitted from the request." >=20 > This reads oddly -- I would assume that I can set it to anything if it's = omitted > :). =A0Suggestion: =A0MUST be either set to "none", or omitted from the r= equest. Well, the value goes into the normalized string... > "Nevertheless, these attributes MUST be included in the normalized reques= t > string together with any other authentication attributes." >=20 > After quick read, I have no idea what this sentence means operationally. = =A0Can > you clarify? That when you create the normalized string, they are included even if they = are not sent on the wire. I tried to keep the normalized string consistent = regardless of method used. Does this sound like a good/bad idea? EHL From Bart.bv.Vrancken@alcatel-lucent.com Thu Feb 4 01:39:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0243A6A93 for ; Thu, 4 Feb 2010 01:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 80EL4z-goAxF for ; Thu, 4 Feb 2010 01:39:34 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id BA9B13A69BB for ; Thu, 4 Feb 2010 01:39:33 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o149dmCD031195; Thu, 4 Feb 2010 10:40:05 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.53]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 10:39:55 +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: Thu, 4 Feb 2010 10:39:11 +0100 Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E049723B9@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] proposed agenda for second interim meeting Thread-Index: Acqk4c0Wgr8hiOUoTAyGjwakt8fvGwADBNDAACPp2aA= References: <4B69066C.5050809@stpeter.im><90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET><62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "Vrancken Bart bv" To: "Eran Hammer-Lahav" , "Dick Hardt" X-OriginalArrivalTime: 04 Feb 2010 09:39:55.0792 (UTC) FILETIME=[02620100:01CAA57E] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second 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, 04 Feb 2010 09:39:35 -0000 Hi folks, In the beginning of December, I posted 2 use cases for multi-level delegation, but I didn't receive a lot of feedback there: http://www.ietf.org/mail-archive/web/oauth/current/msg00807.html Please feel free to provide feedback, now we are discussing about use cases. Best regards, Bart Vrancken -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: woensdag 3 februari 2010 17:41 To: Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting Has anyone gathered and reviewed use cases? I haven't seen much of that showing up on the list. From my experience, asking people for use cases rarely works, unless someone is willing to do the work and collect them (and so far I haven't heard from such volunteer). I much prefer the process in which we produce a technical document based on OAuth 1.0 and the new requirements as defined by WRAP, and discuss use cases as a property of the technical attributes of this draft. Of course, you don't have to agree with me, but that puts the burden of producing use cases documentation on you and others interested in taking that approach. We certainly have room for both, and keep in mind that my token draft is not (yet) a working group item. The indication I received from many of the active members of this list is that we have a strong desire to show up at Anaheim with two stable drafts. I think we are very close to getting the authentication piece done following much of OAuth 1.0 functionality (only cleaner and better structures), as well as treating bearer tokens as first class citizens. Given that no one has started a discussion about the delegation flows to include, I doubt we will have a stable second draft, but I plan on getting the authentication piece stable in time. It has also been my experience over the past two years that the biggest challenge is to figure out the authentication piece. The 'go get a token' piece tends to be much easier to agree on. If we get the authentication draft to a stable place, my intention is to leave it there and focus on the second part and come back to it as the delegation requirements become clearer (if changes are needed). But at least it gives us something stable to build upon. EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Wednesday, February 03, 2010 7:02 AM > To: Eran Hammer-Lahav > Cc: Peter Saint-Andre; OAuth WG > Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >=20 > Hi Eran >=20 > I think it is a little early in our phone discussions to get into technical details. > The next step according to the last call was to gather and review use cases. > Without rough consensus on what problem we are solving, your points > below (which all do need to be discussed at some point) is just moving > around deck chairs on the Titanic. >=20 > -- Dick >=20 > On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: >=20 > > Please add: > > > > - Discuss Adobe's recent request to allow excluding the host/port from the > signed message. > > > > - With regards to #4, how should the challenge identify the token to be > used (realm comes free, do we need another)? > > > > - Should a single token support multiple signature algorithms? This has > implications as to the information the client has to include with the request > (the algorithm used, etc.). > > > > - Where should the token structure live? OAuth 1.0 includes two response > parameters (token and token_secret). However, since we are now moving > towards having the algorithm part of the token definition, as well as duration > and other attributes, the server will need to provide this information to the > client. This calls for a simple schema (can be any format but need to agree to > consistent names). It is currently part of the authorization/delegation draft > (implicitly), but we should discuss moving it to the authentication draft since > that's where it is used (the authorization draft simply hands those "things" > out). > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Peter Saint-Andre > >> Sent: Tuesday, February 02, 2010 9:15 PM > >> To: OAuth WG > >> Subject: [OAUTH-WG] proposed agenda for second interim meeting > >> > >> > >> > >> At the first interim meeting, we didn't get through our agenda: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html > >> > >> Therefore I propose that this time we focus on some unfinished > >> business, starting with the topic of authentication. I have reviewed > >> all of the related threads on the list and have come up with the following > *rough* agenda. > >> Your feedback is welcome to improve this (a.k.a. "agenda > >> bashing") either on the list or during the meeting. > >> > >> For logistics information, see here: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html > >> > >> ****** > >> > >> AGENDA > >> > >> Base proposal: draft-ietf-oauth-authentication-01 > >> > >> Eran had hoped to push out a new version in time for our meeting, but > >> hasn't been able to get to it yet. However, I think we can continue > >> to move forward with discussion. Feedback is welcome on the general > >> approach, as well as specific open issues. > >> > >> Open issues.... > >> > >> Issue #1: Request Signing vs. API Signing vs. Message Signing > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html > >> > >> 1a. Seeming consensus for message signing. > >> > >> 1b. No consensus yet on message format. > >> - JSON and textual key-value seem to be the leading candidates. > >> > >> 1c. Seeming consensus for multiple/extensible signature algorithms. > >> - HMAC-SHA1 > >> - HMAC-SHA256 > >> - RSASSA-PKCS1-v1.5-SHA256 > >> - PLAIN over SSL/TLS > >> > >> But: which of these are Mandatory-to-Implement? > >> > >> Issue #2: Include the Normalized Request with the Request? > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html > >> > >> Seeming consensus to not include the normalized request (e.g., > >> signature string). > >> > >> Issue #3: Allow Secrets in Cleartext, or Require Channel Encryption? > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html > >> > >> Seeming consensus that channel encryption is must-implement (which > >> does not necessarily mean must-deploy). > >> > >> Issue #4: Authentication Challenges > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html > >> > >> If an authentication (access) request is unacceptable, how does the > >> server tell the client how it can provide proper credentials (e.g., > >> by using a different algorithm)? > >> > >> Possible other topics: > >> > >> - Mutual auth? > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html > >> > >> - Resource authorization? > >> http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html > >> > >> ****** > >> > >> /psa > >> > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Thu Feb 4 05:29:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2C028C1A8 for ; Thu, 4 Feb 2010 05:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 RiEpCrk+B4Hp for ; Thu, 4 Feb 2010 05:29:34 -0800 (PST) Received: from mailipao.vtcif.telstra.com.au (mailipao.vtcif.telstra.com.au [202.12.144.27]) by core3.amsl.com (Postfix) with ESMTP id E6C613A6DA7 for ; Thu, 4 Feb 2010 05:29:33 -0800 (PST) Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipai.vtcif.telstra.com.au with ESMTP; 05 Feb 2010 00:30:18 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id D3D571DA81 for ; Fri, 5 Feb 2010 00:30:17 +1100 (EST) Received: from WSMSG3705.srv.dir.telstra.com (wsmsg3705.srv.dir.telstra.com [172.49.40.203]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id E177141DAB for ; Fri, 5 Feb 2010 00:29:47 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Fri, 5 Feb 2010 00:30:17 +1100 From: "Manger, James H" To: "OAuth WG (oauth@ietf.org)" Date: Fri, 5 Feb 2010 00:30:11 +1100 Thread-Topic: Use case: photo framing app access new photo service Thread-Index: Acqlni1owrQMX6Z0TZyKbad7fljNYg== Message-ID: <255B9BB34FB7D647A506DC292726F6E112504AE426@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112504AE426WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] Use case: photo framing app access new photo service X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Feb 2010 13:29:35 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112504AE426WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVsb3cgaXMgYSBzY2VuYXJpbyB0aGF0IGNhcHR1cmVzIG1vc3Qgb2YgdGhlIGtleSBhc3BlY3Rz IHRoYXQgSSBiZWxpZXZlIE9BdXRoIHNwZWNzIHNob3VsZCBzdXBwb3J0LiBbU29tZSBtaWdodCBy ZWNvZ25pemUgaXQgZnJvbSAxOSBtb250aHMgYWdvIG9uIHRoZSBPQXV0aCBnb29nbGVncm91cHMg bGlzdF0NCg0KDQoNCkNvbnNpZGVyIGFuIGFwcCAodGhlIGNsaWVudCkgdGhhdCBhZGRzIHByZXR0 eSBmcmFtZXMgdG8gcGhvdG9zLiBUaGUgYXBwIHVuZGVyc3RhbmRzIEF0b20gZmVlZHMgdGhhdCBo b2xkIGNvbGxlY3Rpb25zIG9mIHBob3RvcywgYW5kIGluZHVzdHJ5IGNvbnZlbnRpb25zIGZvciBt YXJraW5nLXVwIHRodW1ibmFpbHMsIGNhcHRpb25zLCBhbmQgbGlua3MgdG8gSlBFR3MuIFRoZSBh cHAgYWxzbyBpbXBsZW1lbnRzIHRoZSBPQXV0aCBwcm90b2NvbC4gV2hpbGUgaXQgaGFzIHNvbWUg c3BlY2lhbCBjb2RlIGZvciBhIGhhbmRmdWwgb2YgcG9wdWxhciBwaG90byBzaXRlcywgaXQgaGFz IG5vIHNwZWNpYWwga25vd2xlZGdlIGFib3V0IHRoZSBwaG90byBzZXJ2aWNlIHRoYXQgQWxpY2Ug dXNlcy4gQWxpY2XigJlzIHBob3RvIHNlcnZpY2UgZG9lcyBwcm92aWRlIFVSSXMgZm9yIGVhY2gg b2YgQWxpY2XigJlzIGFsYnVtcyBhbmQgcGhvdG9zLg0KDQoNCg0KMC4gQWxpY2UgcGFzdGVzIGEg VVJJIGZvciBoZXIgcHJpdmF0ZSBwaG90byBhbGJ1bSBpbnRvIHRoZSBhcHAuDQoNCjEuIFRoZSBh cHAgbWFrZXMgYSBHRVQgb24gdGhlIFVSSS4NCg0KMi4gVGhlIGFsYnVtIGlzIHByaXZhdGUgc28g YSA0MDEgaXMgcmV0dXJuZWQsIGJ1dCB3aXRoIGEgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIgaW5k aWNhdGluZyBPQXV0aCBzdXBwb3J0IGFuZCBwcm92aWRpbmcgYXV0aG9yaXphdGlvbiBhbmQgYWNj ZXNzIFVSSXMuDQoNCjMuIFRoZSBhcHAgcmVkaXJlY3RzIEFsaWNlIHRvIHRoZSBhdXRob3JpemF0 aW9uIFVSSSBpdCBqdXN0IGdvdC4NCg0KNC4gQWxpY2UgYXBwcm92ZXMgdGhlIGFwcCwgcGVyaGFw cyB3aXRoIHRleHQgZnJvbSB0aGUgc2VydmljZSBjYXV0aW9uaW5nIHRoYXQgaXQgZG9lcyBub3Qg a25vdyBtdWNoIGFib3V0IHRoaXMgYXBwLg0KDQo1LiBUaGUgYXBwIGRldGVjdHMgd2hlbiBpdCBo YXMgYmVlbiBhdXRob3JpemVkLg0KDQo2LiBUaGUgYXBwIGNvbGxlY3RzIGFuIGFjY2VzcyB0b2tl biAocHJvYmFibHkgZnJvbSB0aGUgb3RoZXIgVVJJIHJlY2VpdmVkIGluIHN0ZXAgMikuDQoNCjcu IFRoZSBhcHAgcmV0cmllcyB0aGUgb3JpZ2luYWwgR0VUIGZvciB0aGUgcGhvdG8gYWxidW0sIHRo aXMgdGltZSB3aXRoIGRlbGVnYXRpb24gY3JlZGVudGlhbHMuDQoNCjguIFRoZSByZXF1ZXN0IHN1 Y2NlZWRzIC0gdGhlIGFwcCBjYW4gcmVhZCB0aGUgcGhvdG9zIGFuZCBzaG93IHRoZW0gaW4gcHJl dHR5IGZyYW1lcy4NCg0KDQoNClZhcmlvdXMgdmFyaWFudHMgb2YgdGhlIGFwcCBydW4gb24gYSB3 ZWIgc2l0ZSwgZGVza3RvcCBQQ3MsIG9uIG1vYmlsZSBwaG9uZXMsIGFuZCBvbiBvdGhlciBkZXZp Y2VzLg0KDQoNCg0KQSBtYWpvciBiYXJyaWVyIHRvIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGJldHdl ZW4gdGhpcyBhcHAgYW5kIEFsaWNl4oCZcyBwaG90byBzZXJ2aWNlIHdpdGggT0F1dGggMSB3YXMg dGhlIG5lZWQgdG8gcHJlLWNvbmZpZ3VyZSB0aGUgc2VydmljZS1zcGVjaWZpYyBPQXV0aCBVUklz IGludG8gdGhlIGFwcC4NCg0KSXTigJlzIGZpbmUgaWYgYW4gYXBwIGNhbiBza2lwIGEgc3RlcCBv ciB0d28gd2l0aCBzZXJ2aWNlLXNwZWNpZmljIGtub3dsZWRnZS4NCg0KSXTigJlzIGZpbmUgaWYg YSBwYXJ0aWN1bGFyIHNlcnZpY2Ugb25seSBhY2NlcHRzIHByZS1yZWdpc3RlcmVkIGFwcHMuDQoN ClRoZSBPQXV0aCBJRVRGIHNwZWMsIHRob3VnaCwgYWxzbyBuZWVkcyB0byBjb3ZlciB0aGUgYWJv dmUgc2NlbmFyaW8gb2YgYW4gYXBwIGFuZCBzZXJ2aWNlIGludGVyb3BlcmF0aW5nIGRlc3BpdGUg bm90IHByZXZpb3VzbHkga25vd2luZyBlYWNoIG90aGVyLg0KDQoNCg0KLS0NCg0KSmFtZXMgTWFu Z2VyDQoNCg0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E112504AE426WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHls ZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4N Cjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQVUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVsb3cg aXMgYSBzY2VuYXJpbyB0aGF0IGNhcHR1cmVzIG1vc3Qgb2YgdGhlIGtleSBhc3BlY3RzIHRoYXQg SSBiZWxpZXZlIE9BdXRoIHNwZWNzIHNob3VsZCBzdXBwb3J0LiBbU29tZSBtaWdodCByZWNvZ25p emUgaXQgZnJvbSAxOSBtb250aHMgYWdvIG9uIHRoZSBPQXV0aCBnb29nbGVncm91cHMgbGlzdF08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29uc2lkZXIgYW4gYXBwICh0aGUgY2xpZW50KSB0aGF0 IGFkZHMgcHJldHR5IGZyYW1lcyB0byBwaG90b3MuIFRoZSBhcHAgdW5kZXJzdGFuZHMgQXRvbSBm ZWVkcyB0aGF0IGhvbGQgY29sbGVjdGlvbnMgb2YgcGhvdG9zLCBhbmQgaW5kdXN0cnkgY29udmVu dGlvbnMgZm9yIG1hcmtpbmctdXAgdGh1bWJuYWlscywgY2FwdGlvbnMsIGFuZCBsaW5rcyB0byBK UEVHcy4gVGhlIGFwcCBhbHNvIGltcGxlbWVudHMgdGhlDQogT0F1dGggcHJvdG9jb2wuIFdoaWxl IGl0IGhhcyBzb21lIHNwZWNpYWwgY29kZSBmb3IgYSBoYW5kZnVsIG9mIHBvcHVsYXIgcGhvdG8g c2l0ZXMsIGl0IGhhcyBubyBzcGVjaWFsIGtub3dsZWRnZSBhYm91dCB0aGUgcGhvdG8gc2Vydmlj ZSB0aGF0IEFsaWNlIHVzZXMuIEFsaWNl4oCZcyBwaG90byBzZXJ2aWNlIGRvZXMgcHJvdmlkZSBV UklzIGZvciBlYWNoIG9mIEFsaWNl4oCZcyBhbGJ1bXMgYW5kIHBob3Rvcy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+MC4gQWxpY2UgcGFzdGVzIGEgVVJJIGZvciBoZXIgcHJpdmF0ZSBwaG90byBh bGJ1bSBpbnRvIHRoZSBhcHAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4x LiBUaGUgYXBwIG1ha2VzIGEgR0VUIG9uIHRoZSBVUkkuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4yLiBUaGUgYWxidW0gaXMgcHJpdmF0ZSBzbyBhIDQwMSBpcyByZXR1cm5l ZCwgYnV0IHdpdGggYSBXV1ctQXV0aGVudGljYXRlIGhlYWRlciBpbmRpY2F0aW5nIE9BdXRoIHN1 cHBvcnQgYW5kIHByb3ZpZGluZyBhdXRob3JpemF0aW9uIGFuZCBhY2Nlc3MgVVJJcy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuIFRoZSBhcHAgcmVkaXJlY3RzIEFsaWNl IHRvIHRoZSBhdXRob3JpemF0aW9uIFVSSSBpdCBqdXN0IGdvdC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjQuIEFsaWNlIGFwcHJvdmVzIHRoZSBhcHAsIHBlcmhhcHMgd2l0 aCB0ZXh0IGZyb20gdGhlIHNlcnZpY2UgY2F1dGlvbmluZyB0aGF0IGl0IGRvZXMgbm90IGtub3cg bXVjaCBhYm91dCB0aGlzIGFwcC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjUuIFRoZSBhcHAgZGV0ZWN0cyB3aGVuIGl0IGhhcyBiZWVuIGF1dGhvcml6ZWQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj42LiBUaGUgYXBwIGNvbGxlY3RzIGFuIGFjY2Vz cyB0b2tlbiAocHJvYmFibHkgZnJvbSB0aGUgb3RoZXIgVVJJIHJlY2VpdmVkIGluIHN0ZXAgMiku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj43LiBUaGUgYXBwIHJldHJpZXMg dGhlIG9yaWdpbmFsIEdFVCBmb3IgdGhlIHBob3RvIGFsYnVtLCB0aGlzIHRpbWUgd2l0aCBkZWxl Z2F0aW9uIGNyZWRlbnRpYWxzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ OC4gVGhlIHJlcXVlc3Qgc3VjY2VlZHMgLSB0aGUgYXBwIGNhbiByZWFkIHRoZSBwaG90b3MgYW5k IHNob3cgdGhlbSBpbiBwcmV0dHkgZnJhbWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5WYXJp b3VzIHZhcmlhbnRzIG9mIHRoZSBhcHAgcnVuIG9uIGEgd2ViIHNpdGUsIGRlc2t0b3AgUENzLCBv biBtb2JpbGUgcGhvbmVzLCBhbmQgb24gb3RoZXIgZGV2aWNlcy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QSBtYWpvciBiYXJyaWVyIHRvIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gdGhp cyBhcHAgYW5kIEFsaWNl4oCZcyBwaG90byBzZXJ2aWNlIHdpdGggT0F1dGggMSB3YXMgdGhlIG5l ZWQgdG8gcHJlLWNvbmZpZ3VyZSB0aGUgc2VydmljZS1zcGVjaWZpYyBPQXV0aCBVUklzIGludG8g dGhlIGFwcC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl04oCZcyBmaW5l IGlmIGFuIGFwcCBjYW4gc2tpcCBhIHN0ZXAgb3IgdHdvIHdpdGggc2VydmljZS1zcGVjaWZpYyBr bm93bGVkZ2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdOKAmXMgZmlu ZSBpZiBhIHBhcnRpY3VsYXIgc2VydmljZSBvbmx5IGFjY2VwdHMgcHJlLXJlZ2lzdGVyZWQgYXBw cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBPQXV0aCBJRVRGIHNw ZWMsIHRob3VnaCwgYWxzbyBuZWVkcyB0byBjb3ZlciB0aGUgYWJvdmUgc2NlbmFyaW8gb2YgYW4g YXBwIGFuZCBzZXJ2aWNlIGludGVyb3BlcmF0aW5nIGRlc3BpdGUgbm90IHByZXZpb3VzbHkga25v d2luZyBlYWNoIG90aGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_255B9BB34FB7D647A506DC292726F6E112504AE426WSMSG3153Vsrv_-- From stpeter@stpeter.im Thu Feb 4 09:49: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 58AE828C0ED for ; Thu, 4 Feb 2010 09:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=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 KhCM-nsGT-ev for ; Thu, 4 Feb 2010 09:49:52 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 520273A68F9 for ; Thu, 4 Feb 2010 09:49:52 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 055A740332 for ; Thu, 4 Feb 2010 10:50:35 -0700 (MST) Message-ID: <4B6B08E6.9050403@stpeter.im> Date: Thu, 04 Feb 2010 10:50:30 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <90C41DD21FB7C64BB94121FBBC2E723437899D22BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112503E4238@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B7E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B7E@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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="------------ms090904090002070905090005" Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge? X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Feb 2010 17:49:53 -0000 This is a cryptographically signed message in MIME format. --------------ms090904090002070905090005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If James is interested in this then he can write an Internet-Draft. That's how the IETF works. :) IMHO such a WWW-Authenticate header might be quite useful, if we think that random entities might try to access a resource that is protected and therefore might need a way to know that they can access the resource via a delegation flow. I'm not sure how likely that is, though. On 2/3/10 9:46 AM, Eran Hammer-Lahav wrote: > It doesn't feel like we have much interest at this level of interoperab= ility at this point. >=20 > EHL >=20 >> -----Original Message----- >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] >> Sent: Wednesday, February 03, 2010 5:38 AM >> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) >> Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an >> authentication challenge? >> >> An authentication challenge (WWW-Authenticate header) defined in a spe= c >> for an authentication mechanism should be present, but only with detai= ls >> specific to that mechanism (eg list of MAC algorithms). >> >> I think there should be a totally separate WWW-Authenticate header >> specifically saying "a delegation flow can be used to access this reso= urce". It >> should include details such as the URI to redirect the user to. >> >> We really need this if we want to offer a web-style protocol with any >> semblance of interoperability. If we omit it because "clients need to = know >> lots of other API-specific details anyway" then we wont have a path to= get >> past that limitation in future. >> >> >> -- >> James Manger >> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behal= f >>> Of Eran Hammer-Lahav >>> Sent: Thursday, 28 January 2010 2:12 PM >>> To: OAuth WG (oauth@ietf.org) >>> Subject: [OAUTH-WG] What are the primary criteria in issuing an >>> authentication challenge? >>> >>> An authentication challenge (to make sure we are all on the same page= ) >>> is something the server sends to the client when denying access to a >>> protected resource. The challenge can be as simple as "use Basic", or= >>> complex as "use Digest with the following parameters". OAuth 1.0 >>> doesn't really use a challenge because it was created for cases where= >>> the API calls are preconfigured and hardcoded into the client. The >>> client should never receive an OAuth challenge the way the protocol >>> was originally designed. >>> >>> In my token authentication draft I tried to propose multiple >>> mechanisms (not fully baked yet) for issuing a challenge and allowing= >>> the client to figure out what to do next. Before producing another >>> draft, it is important to figure out what challenge model we want to >>> use. Here are the general options I came up with: >>> >>> 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is >>> left on its own to figure out what to do next. >>> >>> 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you >>> need a new token go there". It is still not clear how this will help >>> the client given that getting a token is likely it include many >>> different options, and to fully address this we need to dig deep into= >>> discovery which was left out of scope. >>> >>> 3. Token attributes - the server informs the client of the kind of >>> tokens accepted (based on their cryptographic properties or the >>> resource-set/realm they are good for). This is just like #2 but with >>> the ability for the server to support more than one token type per >>> resource. >>> >>> Question: Is the ability for a single token-protected resource to >>> support more than one token type (say Plain+SSL *and* HMAC-256) part >>> of our requirements? If not, there is no reason at all for the >>> challenge to include anything other than #1 or #2 (probably defined a= s >>> a future extension). >>> >>> EHL --------------ms090904090002070905090005 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 hvcNAQkFMQ8XDTEwMDIwNDE3NTAzMFowIwYJKoZIhvcNAQkEMRYEFKcv5BwfjI8gGAVQiiT0 kYrUfQ2YMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAP2InfkHi5c00yFVsvOEFyoyEDzBB+5GoxxNLSLp7 oxl7EDWU5Z0ZQ3daiVNYFA/4UA3zWhzxMV7HenE7BH+9B9uMYGXqakjlaoqi77ovyAzVtPyV 3dU+VF8A27CK0QXR1zhJlPu8tBUe7OLiv/fYOIyiaZnVbbWc628u+aVLORFlLmCNZiGGo2Mt XSSuw6dN+yl+EcFGp4el31nPKbVZ+Z9jFYOEtKxiKRYLEH/smmEC9Qiv0S9rYvYtXHrkJXny 23sgU6fDVVS7XHwQ/UaEj6eGxwYXIT32nylvEbWEyY1XaktVSEyx3R0HTuf2OTBMyilsVdYC T8z7FbkE/qlyTAAAAAAAAA== --------------ms090904090002070905090005-- From dick.hardt@gmail.com Thu Feb 4 10:45: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 8921E3A6DF1 for ; Thu, 4 Feb 2010 10:45:00 -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 w8AjmBzCypTt for ; Thu, 4 Feb 2010 10:44:59 -0800 (PST) Received: from mail1.sxip.com (nvg-01-e0.yvr.sxip.com [72.15.146.183]) by core3.amsl.com (Postfix) with ESMTP id 4FF4B3A6A27 for ; Thu, 4 Feb 2010 10:44:59 -0800 (PST) Received: from [192.168.1.243] (c-24-17-212-68.hsd1.wa.comcast.net [24.17.212.68]) (authenticated bits=0) by mail1.sxip.com (8.13.8/8.13.8) with ESMTP id o14IjfO3038147 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 4 Feb 2010 10:45:41 -0800 (PST) (envelope-from dick.hardt@gmail.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Thu, 4 Feb 2010 10:45:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eve Maler X-Mailer: Apple Mail (2.1077) X-Scanned-By: MIMEDefang 2.63 on 172.16.6.3 Cc: OAuth WG Subject: Re: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second 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, 04 Feb 2010 18:45:00 -0000 On 2010-02-03, at 10:54 AM, Eve Maler wrote: >=20 > - There is a conceptual similarity between the UMA and WRAP entities, = but our analysis so far shows it to be shallow in spots. For example, = WRAP's "protected resource" maps fairly well to an UMA "host" (which may = host any number of protected resources), and WRAP's and OAuth's = "client"/"consumer" maps to an UMA "requester". However, it seems that = a WRAP authorization server is assumed to be in the same domain as a = protected resource, allowing for implicit rather than explicit scoping = of resources. The UMA authorization manager and any one host may be in = entirely separate domains, and introductions between them are intended = to be user-driven. In OAuth WRAP, Authorization Server (AS) is NOT assumed to be in the = same domain as the Protected Resource (PR). The Client does need to know = which AS it can call for an Access Token for a given PR. Discovery of = the PR and AS was out of scope for OAuth WRAP (and I think for this WG). = We figured general purpose APIs would have their own discovery and the = AS and PR would be discovered in that process. -- Dick= From stpeter@stpeter.im Thu Feb 4 10:46:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081D23A6DEE for ; Thu, 4 Feb 2010 10:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 KdOlzkPPl9Sj for ; Thu, 4 Feb 2010 10:46:38 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 361F73A6DC1 for ; Thu, 4 Feb 2010 10:46:38 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A36F040332 for ; Thu, 4 Feb 2010 11:47:24 -0700 (MST) Message-ID: <4B6B1638.8030303@stpeter.im> Date: Thu, 04 Feb 2010 11:47:20 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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="------------ms090104050402070309020009" Subject: Re: [OAUTH-WG] proposed agenda for second 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, 04 Feb 2010 18:46:39 -0000 This is a cryptographically signed message in MIME format. --------------ms090104050402070309020009 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/3/10 11:55 AM, Dick Hardt wrote: > I recall from the call that Peter did ask if there was consensus on > the approach of gathering use cases. There seemed consensus that the > WG might not fully understand the problem and that this made sense. I agree, but given that we haven't had a lot of discussion about use cases on the list, I figured it would be more productive to focus this call on the authentication work, encourage more people to contribute use cases over the next two weeks, and then discuss use cases on the next call (slated for February 11, I need to schedule that today). Peter --------------ms090104050402070309020009 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 hvcNAQkFMQ8XDTEwMDIwNDE4NDcyMFowIwYJKoZIhvcNAQkEMRYEFOrSGr13shbMXxcB4/SK VpU1GHifMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAP1ZLb9qVuiWmwfrR++tg9gNZVNIfJvD08m8EaSOt 8IRCumOCdjc6E7yNNU00cAkxvpZKc1tOvsVSRKVnp/QReNtJNh5W0xyMkZEELDgmXYX8Vjcx 9tuBcRzkZO2guC7aXUS8lVIqdlIs/aDwgJQ43y4d0cALSsEvCTT9UoCNmAxicmBAsMONRviR rYKl8gE1xyV/AKvBzGiFIqjvk48Zr64fiQfOCzlHek+QdpgJ/w+rDvpXY/nezYHQQQEP6p6h FU9UWfMj7zJO7dwK5RaFeupCiq4aHK+OXa6WxoPPQR7hNaris4SfPBQ6cQknQDBsR1fk64X+ 5PF5FVGeDMccvAAAAAAAAA== --------------ms090104050402070309020009-- From dick.hardt@gmail.com Thu Feb 4 10:51: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 8BD3C3A6E02 for ; Thu, 4 Feb 2010 10:51:44 -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 VGb-4ueEf41y for ; Thu, 4 Feb 2010 10:51:43 -0800 (PST) Received: from mail1.sxip.com (nvg-01-e0.yvr.sxip.com [72.15.146.183]) by core3.amsl.com (Postfix) with ESMTP id C91BB3A6DC1 for ; Thu, 4 Feb 2010 10:51:43 -0800 (PST) Received: from [192.168.1.243] (c-24-17-212-68.hsd1.wa.comcast.net [24.17.212.68]) (authenticated bits=0) by mail1.sxip.com (8.13.8/8.13.8) with ESMTP id o14IqRaX038618 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 4 Feb 2010 10:52:28 -0800 (PST) (envelope-from dick.hardt@gmail.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <4B6B1638.8030303@stpeter.im> Date: Thu, 4 Feb 2010 10:52:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2797DBC8-90D1-4B81-B95A-04112DD5E66F@gmail.com> References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B6B1638.8030303@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1077) X-Scanned-By: MIMEDefang 2.63 on 172.16.6.3 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] proposed agenda for second 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, 04 Feb 2010 18:51:44 -0000 On 2010-02-04, at 10:47 AM, Peter Saint-Andre wrote: > >=20 > On 2/3/10 11:55 AM, Dick Hardt wrote: >> I recall from the call that Peter did ask if there was consensus on >> the approach of gathering use cases. There seemed consensus that the >> WG might not fully understand the problem and that this made sense. >=20 > I agree, but given that we haven't had a lot of discussion about use > cases on the list, I figured it would be more productive to focus this > call on the authentication work, encourage more people to contribute = use > cases over the next two weeks, and then discuss use cases on the next > call (slated for February 11, I need to schedule that today). Works for me.=20 I'm hopeful someone can explain what is meant by "authentication work"! =46rom my understanding of Eran's draft, I don't see the distinction = between Authorization Server and Protected Resource we have in OAuth = WRAP. -- Dick From stpeter@stpeter.im Thu Feb 4 10:53: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 74B4728C162 for ; Thu, 4 Feb 2010 10:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KGw9wPxERhH for ; Thu, 4 Feb 2010 10:53:50 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 63F6A3A6803 for ; Thu, 4 Feb 2010 10:53:50 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8ED2D40332; Thu, 4 Feb 2010 11:54:36 -0700 (MST) Message-ID: <4B6B17EB.4010208@stpeter.im> Date: Thu, 04 Feb 2010 11:54:35 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dick Hardt References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <371693C7-5694-4E30-87EF-B8859B72D437@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B6B1638.8030303@stpeter.im> <2797DBC8-90D1-4B81-B95A-04112DD5E66F@gmail.com> In-Reply-To: <2797DBC8-90D1-4B81-B95A-04112DD5E66F@gmail.com> 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="------------ms060302050200040801010107" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] proposed agenda for second 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, 04 Feb 2010 18:53:51 -0000 This is a cryptographically signed message in MIME format. --------------ms060302050200040801010107 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/4/10 11:52 AM, Dick Hardt wrote: >=20 > On 2010-02-04, at 10:47 AM, Peter Saint-Andre wrote: >=20 >> >>=20 >> On 2/3/10 11:55 AM, Dick Hardt wrote: >>> I recall from the call that Peter did ask if there was consensus >>> on the approach of gathering use cases. There seemed consensus >>> that the WG might not fully understand the problem and that this >>> made sense. >>=20 >> I agree, but given that we haven't had a lot of discussion about >> use cases on the list, I figured it would be more productive to >> focus this call on the authentication work, encourage more people >> to contribute use cases over the next two weeks, and then discuss >> use cases on the next call (slated for February 11, I need to >> schedule that today). >=20 > Works for me. >=20 > I'm hopeful someone can explain what is meant by "authentication > work"! >=20 > From my understanding of Eran's draft, I don't see the distinction > between Authorization Server and Protected Resource we have in OAuth > WRAP. By "Eran's draft" do you mean draft-ietf-oauth-authentication-01 or draft-hammer-http-token-auth-01? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060302050200040801010107 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 hvcNAQkFMQ8XDTEwMDIwNDE4NTQzNVowIwYJKoZIhvcNAQkEMRYEFFBY+f3iHemK5oebXuIm s0pgAwBTMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAJJ+jOXVJ22l4LpGmEv9zoCj8Zw9De9A6mpcIlehB seEDVjNF+xN+h5gF5RX0y1IK5Xg4Ly4cDLfRhsBsAam6cl1z5pIku+gGf6eN25okA6+Hpojv jEuChIHV/TBC/3HnmAH52uCd27KOG0nIkk0gUewzG0rf31ceJ81obx+XfBLcIoy0h3VE4dZ/ tJcTNUXvESbR0qcwELN6ZBJFbhbKePSTq3FesT67xwCfWbQdgus62zog0kJ5YM0EHvqJ/Ehv ZiTZC6r/tD6AH2Ekkyp+gx8AbRwSRVf/lQo8vMsN8PRe/agx9yLXlNURUsKSpofKpUnaIUfq wV4WRmD+NipJfwAAAAAAAA== --------------ms060302050200040801010107-- From tonynad@microsoft.com Thu Feb 4 11:16: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 7F48A28C188 for ; Thu, 4 Feb 2010 11:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.196 X-Spam-Level: X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 HAAdAbjo4XpD for ; Thu, 4 Feb 2010 11:16:57 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id CC1D428C1B4 for ; Thu, 4 Feb 2010 11:16:57 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 4 Feb 2010 11:18:36 -0800 Received: from TK5EX14MBXC103.redmond.corp.microsoft.com ([169.254.3.76]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Thu, 4 Feb 2010 11:17:44 -0800 From: Anthony Nadalin To: Eve Maler , OAuth WG Thread-Topic: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second interim meeting) Thread-Index: AQHKpQSGwYiNbBp6LUaw5KdmO+3QYpG2Up1w Date: Thu, 4 Feb 2010 19:17:42 +0000 Message-ID: References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second 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, 04 Feb 2010 19:16:59 -0000 > use UMA to require the requester to assure her they will not misuse or fu= rther share her information Not sure how UMA would be able to deal with this, if you look at things lik= e the OECD Data Protection Principles (on which Privacy laws have been base= d) there are a lot of things considered misuse -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ve Maler Sent: Wednesday, February 03, 2010 10:54 AM To: OAuth WG Subject: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second inter= im meeting) Sorry for the delay, and thanks for the push. In scrambling to approve a p= assel of scenarios and produce our webinar last week, we got a bit behind. = (By the way, complete recordings are now available. Their quality is not = perfect, but should suffice. Please see http://kantarainitiative.org/confl= uence/display/uma/UMA+Explained for recordings, overview slides, protocol e= xplanation slides, and example wireframes.) In order to inform the OAuth V2.0 effort, here is some information about ke= y User-Managed Access (UMA) use cases and needs. The wiki home is at http:= //kantarainitiative.org/confluence/display/uma/Home , and the sidebar on th= e right has links to all the available materials. The focus of UMA is to externalize authorization decisions currently perfor= med by OAuth SPs/servers into a fourth distinct entity we call an "authoriz= ation manager" or AM. Protected resources are hosted at endpoints called "= hosts" and the endpoints seeking data/service access are called "requesters= ". An application embodying the AM endpoint can help the "authorizing user"= globally manage what otherwise might be a complicated authorization pictur= e among all the services accessing and sharing data about her, including le= tting her dictate policies for access authorization that the AM enforces. = (If you're familiar with classic access management technology, the AM serve= s as a policy decision point and the hosts are policy enforcement points.) = An AM provides the user with the ability to apply discretionary access con= trols for his/her resources.=20 The extensive information available about UMA includes a Scenarios and Use = Cases document: http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+C= ases Here are summaries of two of the group's approved scenarios. Calendaring: Online calendars, whose content is volatile, are valuable to s= hare on an ongoing/"feed" basis. In somewhat the same fashion that people = today share online calendars selectively with other people, a user can shar= e a calendar with a vendor for various purposes. Prior to allowing the acc= ess, she might use UMA to require the requester to assure her they will not= misuse or further share her information. Having authorized access to a pa= rticular resource, the user can then examine all the connections forged to = all her shared resources in similar fashion, from a single console. Personal Loan: A user applies for a loan online, and the loan application s= ite requires him to provide certain third-party-attested information, such = as his salary, bank account, and credit score. This information is best ho= sted directly out of the (several) authoritative sites for it, but the user= is able to package up references to all of it and point the loan site to t= he package; the loan site can then become a requester of each relevant reso= urce. The user can see, from a single place, whether the information has b= een successfully received, and can keep a record of its access. (The webin= ar wireframes show how this packaging might be achieved, along with illustr= ating other potential parts of the user experience.) UMA currently solves its use cases, in part, with a composition of three in= stances of OAuth (along with using XRD metadata and LRDD discovery methods)= . The user introduces each host to the AM with so-called "three-legged" (a= uthn plus web delegation) OAuth as a preface to other interactions. Each r= equester later dynamically introduces itself to a host with the option of u= sing "two-legged" (authn only) OAuth, and then introduces itself to the AM = using two-legged OAuth -- we think of these as "automated self-registration= " of the services. The draft spec can be found here: http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol A few key points: - UMA wants to give users an opportunity, not just to set unilateral policy= (how long access is allowed over time, whether the user should be asked fo= r real-time consent in some fashion when access is attempted, and so on), b= ut also to set terms which the requester must meet. This gives users new to= ols for control, and also enables some interesting high-value use cases, in= volving requests for access on the basis of third-party-attested claims. - There is a conceptual similarity between the UMA and WRAP entities, but o= ur analysis so far shows it to be shallow in spots. For example, WRAP's "p= rotected resource" maps fairly well to an UMA "host" (which may host any nu= mber of protected resources), and WRAP's and OAuth's "client"/"consumer" ma= ps to an UMA "requester". However, it seems that a WRAP authorization serv= er is assumed to be in the same domain as a protected resource, allowing fo= r implicit rather than explicit scoping of resources. The UMA authorizatio= n manager and any one host may be in entirely separate domains, and introdu= ctions between them are intended to be user-driven. Eve On 3 Feb 2010, at 9:34 AM, Eran Hammer-Lahav wrote: > Hi Anthony, >=20 > The problem with this approach is that it hasn't worked (multiple times) = before because no one ever wants to do the work of collecting and writing t= he use cases. What we get instead are short cryptic lists and pointers to e= dge cases. We have a good grasp on how OAuth 1.0 is used and its limitation= s as addressed by the WRAP draft. >=20 > The best use of my time is to continue working on the drafts and asking t= echnical questions whenever a decision is needed. If and when someone write= s use cases, I will review those and see if they are supported by the draft= s. >=20 > I will leave it up to the chairs to decide how they want to guide the wor= king group. >=20 > EHL >=20 >> -----Original Message----- >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] >> Sent: Wednesday, February 03, 2010 9:02 AM >> To: Eran Hammer-Lahav; Dick Hardt >> Cc: OAuth WG >> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting >>=20 >> I would tend to agree with Dick based upon the last call and where=20 >> that was heading. I believe that Eve had some use cases to share=20 >> around UMA >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 >> Behalf Of Eran Hammer-Lahav >> Sent: Wednesday, February 03, 2010 8:41 AM >> To: Dick Hardt >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >>=20 >> Has anyone gathered and reviewed use cases? I haven't seen much of=20 >> that showing up on the list. From my experience, asking people for=20 >> use cases rarely works, unless someone is willing to do the work and=20 >> collect them (and so far I haven't heard from such volunteer). I much=20 >> prefer the process in which we produce a technical document based on=20 >> OAuth 1.0 and the new requirements as defined by WRAP, and discuss=20 >> use cases as a property of the technical attributes of this draft. >>=20 >> Of course, you don't have to agree with me, but that puts the burden=20 >> of producing use cases documentation on you and others interested in=20 >> taking that approach. We certainly have room for both, and keep in=20 >> mind that my token draft is not (yet) a working group item. >>=20 >> The indication I received from many of the active members of this=20 >> list is that we have a strong desire to show up at Anaheim with two=20 >> stable drafts. I think we are very close to getting the=20 >> authentication piece done following much of OAuth 1.0 functionality=20 >> (only cleaner and better structures), as well as treating bearer=20 >> tokens as first class citizens. Given that no one has started a=20 >> discussion about the delegation flows to include, I doubt we will=20 >> have a stable second draft, but I plan on getting the authentication pie= ce stable in time. >>=20 >> It has also been my experience over the past two years that the=20 >> biggest challenge is to figure out the authentication piece. The 'go=20 >> get a token' piece tends to be much easier to agree on. If we get the=20 >> authentication draft to a stable place, my intention is to leave it=20 >> there and focus on the second part and come back to it as the=20 >> delegation requirements become clearer (if changes are needed). But at l= east it gives us something stable to build upon. >>=20 >> EHL >>=20 >>> -----Original Message----- >>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>> Sent: Wednesday, February 03, 2010 7:02 AM >>> To: Eran Hammer-Lahav >>> Cc: Peter Saint-Andre; OAuth WG >>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >>>=20 >>> Hi Eran >>>=20 >>> I think it is a little early in our phone discussions to get into techn= ical details. >>> The next step according to the last call was to gather and review use c= ases. >>> Without rough consensus on what problem we are solving, your points=20 >>> below (which all do need to be discussed at some point) is just=20 >>> moving around deck chairs on the Titanic. >>>=20 >>> -- Dick >>>=20 >>> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: >>>=20 >>>> Please add: >>>>=20 >>>> - Discuss Adobe's recent request to allow excluding the host/port=20 >>>> from the >>> signed message. >>>>=20 >>>> - With regards to #4, how should the challenge identify the token=20 >>>> to be >>> used (realm comes free, do we need another)? >>>>=20 >>>> - Should a single token support multiple signature algorithms? This=20 >>>> has >>> implications as to the information the client has to include with=20 >>> the request (the algorithm used, etc.). >>>>=20 >>>> - Where should the token structure live? OAuth 1.0 includes two=20 >>>> response >>> parameters (token and token_secret). However, since we are now=20 >>> moving towards having the algorithm part of the token definition, as=20 >>> well as duration and other attributes, the server will need to=20 >>> provide this information to the client. This calls for a simple=20 >>> schema (can be any format but need to agree to consistent names). It=20 >>> is currently part of the authorization/delegation draft=20 >>> (implicitly), but we should discuss moving it to the authentication=20 >>> draft since that's where it is used (the >> authorization draft simply hands those "things" >>> out). >>>>=20 >>>> EHL Eve Maler eve@xmlgrrl.com http://www.xmlgrrl.com/blog _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From faynberg@alcatel-lucent.com Thu Feb 4 13:12:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACC2C28C163 for ; Thu, 4 Feb 2010 13:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=0.730, 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 N4MoNbtHeXZe for ; Thu, 4 Feb 2010 13:11:57 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 01F7128C1B5 for ; Thu, 4 Feb 2010 13:11:55 -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 o14LCfBn007037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Feb 2010 15:12:42 -0600 (CST) Received: from [135.244.26.130] (faynberg.lra.lucent.com [135.244.26.130]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o14LCe1h014567; Thu, 4 Feb 2010 15:12:41 -0600 (CST) Message-ID: <4B6B3848.2@alcatel-lucent.com> Date: Thu, 04 Feb 2010 16:12:40 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Anthony Nadalin References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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] UMA use cases (was Re: proposed agenda for second interim meeting) 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: Thu, 04 Feb 2010 21:12:01 -0000 I think it is worth a detailed discussion to conclude whether or not UMA addresses the OECD principles. I don't have an opinion, and I don't know OECD well enough to have one, but I think it is important, and I am glad that Anthony has brought this up. Igor Anthony Nadalin wrote: >> use UMA to require the requester to assure her they will not misuse or further share her information >> > > Not sure how UMA would be able to deal with this, if you look at things like the OECD Data Protection Principles (on which Privacy laws have been based) there are a lot of things considered misuse > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eve Maler > Sent: Wednesday, February 03, 2010 10:54 AM > To: OAuth WG > Subject: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second interim meeting) > > Sorry for the delay, and thanks for the push. In scrambling to approve a passel of scenarios and produce our webinar last week, we got a bit behind. (By the way, complete recordings are now available. Their quality is not perfect, but should suffice. Please see http://kantarainitiative.org/confluence/display/uma/UMA+Explained for recordings, overview slides, protocol explanation slides, and example wireframes.) > > In order to inform the OAuth V2.0 effort, here is some information about key User-Managed Access (UMA) use cases and needs. The wiki home is at http://kantarainitiative.org/confluence/display/uma/Home , and the sidebar on the right has links to all the available materials. > > The focus of UMA is to externalize authorization decisions currently performed by OAuth SPs/servers into a fourth distinct entity we call an "authorization manager" or AM. Protected resources are hosted at endpoints called "hosts" and the endpoints seeking data/service access are called "requesters". An application embodying the AM endpoint can help the "authorizing user" globally manage what otherwise might be a complicated authorization picture among all the services accessing and sharing data about her, including letting her dictate policies for access authorization that the AM enforces. (If you're familiar with classic access management technology, the AM serves as a policy decision point and the hosts are policy enforcement points.) An AM provides the user with the ability to apply discretionary access controls for his/her resources. > > The extensive information available about UMA includes a Scenarios and Use Cases document: > > http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases > > Here are summaries of two of the group's approved scenarios. > > Calendaring: Online calendars, whose content is volatile, are valuable to share on an ongoing/"feed" basis. In somewhat the same fashion that people today share online calendars selectively with other people, a user can share a calendar with a vendor for various purposes. Prior to allowing the access, she might use UMA to require the requester to assure her they will not misuse or further share her information. Having authorized access to a particular resource, the user can then examine all the connections forged to all her shared resources in similar fashion, from a single console. > > Personal Loan: A user applies for a loan online, and the loan application site requires him to provide certain third-party-attested information, such as his salary, bank account, and credit score. This information is best hosted directly out of the (several) authoritative sites for it, but the user is able to package up references to all of it and point the loan site to the package; the loan site can then become a requester of each relevant resource. The user can see, from a single place, whether the information has been successfully received, and can keep a record of its access. (The webinar wireframes show how this packaging might be achieved, along with illustrating other potential parts of the user experience.) > > UMA currently solves its use cases, in part, with a composition of three instances of OAuth (along with using XRD metadata and LRDD discovery methods). The user introduces each host to the AM with so-called "three-legged" (authn plus web delegation) OAuth as a preface to other interactions. Each requester later dynamically introduces itself to a host with the option of using "two-legged" (authn only) OAuth, and then introduces itself to the AM using two-legged OAuth -- we think of these as "automated self-registration" of the services. The draft spec can be found here: > > http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol > > A few key points: > > - UMA wants to give users an opportunity, not just to set unilateral policy (how long access is allowed over time, whether the user should be asked for real-time consent in some fashion when access is attempted, and so on), but also to set terms which the requester must meet. This gives users new tools for control, and also enables some interesting high-value use cases, involving requests for access on the basis of third-party-attested claims. > > - There is a conceptual similarity between the UMA and WRAP entities, but our analysis so far shows it to be shallow in spots. For example, WRAP's "protected resource" maps fairly well to an UMA "host" (which may host any number of protected resources), and WRAP's and OAuth's "client"/"consumer" maps to an UMA "requester". However, it seems that a WRAP authorization server is assumed to be in the same domain as a protected resource, allowing for implicit rather than explicit scoping of resources. The UMA authorization manager and any one host may be in entirely separate domains, and introductions between them are intended to be user-driven. > > Eve > > On 3 Feb 2010, at 9:34 AM, Eran Hammer-Lahav wrote: > > >> Hi Anthony, >> >> The problem with this approach is that it hasn't worked (multiple times) before because no one ever wants to do the work of collecting and writing the use cases. What we get instead are short cryptic lists and pointers to edge cases. We have a good grasp on how OAuth 1.0 is used and its limitations as addressed by the WRAP draft. >> >> The best use of my time is to continue working on the drafts and asking technical questions whenever a decision is needed. If and when someone writes use cases, I will review those and see if they are supported by the drafts. >> >> I will leave it up to the chairs to decide how they want to guide the working group. >> >> EHL >> >> >>> -----Original Message----- >>> From: Anthony Nadalin [mailto:tonynad@microsoft.com] >>> Sent: Wednesday, February 03, 2010 9:02 AM >>> To: Eran Hammer-Lahav; Dick Hardt >>> Cc: OAuth WG >>> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting >>> >>> I would tend to agree with Dick based upon the last call and where >>> that was heading. I believe that Eve had some use cases to share >>> around UMA >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>> Behalf Of Eran Hammer-Lahav >>> Sent: Wednesday, February 03, 2010 8:41 AM >>> To: Dick Hardt >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >>> >>> Has anyone gathered and reviewed use cases? I haven't seen much of >>> that showing up on the list. From my experience, asking people for >>> use cases rarely works, unless someone is willing to do the work and >>> collect them (and so far I haven't heard from such volunteer). I much >>> prefer the process in which we produce a technical document based on >>> OAuth 1.0 and the new requirements as defined by WRAP, and discuss >>> use cases as a property of the technical attributes of this draft. >>> >>> Of course, you don't have to agree with me, but that puts the burden >>> of producing use cases documentation on you and others interested in >>> taking that approach. We certainly have room for both, and keep in >>> mind that my token draft is not (yet) a working group item. >>> >>> The indication I received from many of the active members of this >>> list is that we have a strong desire to show up at Anaheim with two >>> stable drafts. I think we are very close to getting the >>> authentication piece done following much of OAuth 1.0 functionality >>> (only cleaner and better structures), as well as treating bearer >>> tokens as first class citizens. Given that no one has started a >>> discussion about the delegation flows to include, I doubt we will >>> have a stable second draft, but I plan on getting the authentication piece stable in time. >>> >>> It has also been my experience over the past two years that the >>> biggest challenge is to figure out the authentication piece. The 'go >>> get a token' piece tends to be much easier to agree on. If we get the >>> authentication draft to a stable place, my intention is to leave it >>> there and focus on the second part and come back to it as the >>> delegation requirements become clearer (if changes are needed). But at least it gives us something stable to build upon. >>> >>> EHL >>> >>> >>>> -----Original Message----- >>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>>> Sent: Wednesday, February 03, 2010 7:02 AM >>>> To: Eran Hammer-Lahav >>>> Cc: Peter Saint-Andre; OAuth WG >>>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >>>> >>>> Hi Eran >>>> >>>> I think it is a little early in our phone discussions to get into technical details. >>>> The next step according to the last call was to gather and review use cases. >>>> Without rough consensus on what problem we are solving, your points >>>> below (which all do need to be discussed at some point) is just >>>> moving around deck chairs on the Titanic. >>>> >>>> -- Dick >>>> >>>> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: >>>> >>>> >>>>> Please add: >>>>> >>>>> - Discuss Adobe's recent request to allow excluding the host/port >>>>> from the >>>>> >>>> signed message. >>>> >>>>> - With regards to #4, how should the challenge identify the token >>>>> to be >>>>> >>>> used (realm comes free, do we need another)? >>>> >>>>> - Should a single token support multiple signature algorithms? This >>>>> has >>>>> >>>> implications as to the information the client has to include with >>>> the request (the algorithm used, etc.). >>>> >>>>> - Where should the token structure live? OAuth 1.0 includes two >>>>> response >>>>> >>>> parameters (token and token_secret). However, since we are now >>>> moving towards having the algorithm part of the token definition, as >>>> well as duration and other attributes, the server will need to >>>> provide this information to the client. This calls for a simple >>>> schema (can be any format but need to agree to consistent names). It >>>> is currently part of the authorization/delegation draft >>>> (implicitly), but we should discuss moving it to the authentication >>>> draft since that's where it is used (the >>>> >>> authorization draft simply hands those "things" >>> >>>> out). >>>> >>>>> EHL >>>>> > > Eve Maler > eve@xmlgrrl.com > http://www.xmlgrrl.com/blog > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From email@pbryan.net Thu Feb 4 14:36: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 DD4013A6E67 for ; Thu, 4 Feb 2010 14:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=-0.303, 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 v8I-OVuXHF5E for ; Thu, 4 Feb 2010 14:36:58 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 376A328C120 for ; Thu, 4 Feb 2010 14:36:58 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 61E85EA021 for ; Thu, 4 Feb 2010 22:37:42 +0000 (UTC) From: "Paul C. Bryan" To: OAuth WG In-Reply-To: References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 04 Feb 2010 14:37:36 -0800 Message-ID: <1265323056.2758.141.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second 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, 04 Feb 2010 22:37:00 -0000 On Thu, 2010-02-04 at 19:17 +0000, Anthony Nadalin wrote: > > use UMA to require the requester to assure her they will not misuse > or further share her information > > Not sure how UMA would be able to deal with this, if you look at > things like the OECD Data Protection Principles (on which Privacy laws > have been based) there are a lot of things considered misuse I don't imagine there would be any such term called "misuse" that a requester would claim. There would be specific, possibly enforceable terms. Examples: 1. Requester will retain accessed information for no longer than {n} days. 2. Requester will not share accessed information with any third party except as required to comply with the laws of {region, ...}. Paul > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eve Maler > Sent: Wednesday, February 03, 2010 10:54 AM > To: OAuth WG > Subject: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second > interim meeting) > > Sorry for the delay, and thanks for the push. In scrambling to > approve a passel of scenarios and produce our webinar last week, we > got a bit behind. (By the way, complete recordings are now available. > Their quality is not perfect, but should suffice. Please see > http://kantarainitiative.org/confluence/display/uma/UMA+Explained for > recordings, overview slides, protocol explanation slides, and example > wireframes.) > > In order to inform the OAuth V2.0 effort, here is some information > about key User-Managed Access (UMA) use cases and needs. The wiki > home is at http://kantarainitiative.org/confluence/display/uma/Home , > and the sidebar on the right has links to all the available materials. > > The focus of UMA is to externalize authorization decisions currently > performed by OAuth SPs/servers into a fourth distinct entity we call > an "authorization manager" or AM. Protected resources are hosted at > endpoints called "hosts" and the endpoints seeking data/service access > are called "requesters". An application embodying the AM endpoint can > help the "authorizing user" globally manage what otherwise might be a > complicated authorization picture among all the services accessing and > sharing data about her, including letting her dictate policies for > access authorization that the AM enforces. (If you're familiar with > classic access management technology, the AM serves as a policy > decision point and the hosts are policy enforcement points.) An AM > provides the user with the ability to apply discretionary access > controls for his/her resources. > > The extensive information available about UMA includes a Scenarios and > Use Cases document: > > http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and > +Use+Cases > > Here are summaries of two of the group's approved scenarios. > > Calendaring: Online calendars, whose content is volatile, are valuable > to share on an ongoing/"feed" basis. In somewhat the same fashion > that people today share online calendars selectively with other > people, a user can share a calendar with a vendor for various > purposes. Prior to allowing the access, she might use UMA to require > the requester to assure her they will not misuse or further share her > information. Having authorized access to a particular resource, the > user can then examine all the connections forged to all her shared > resources in similar fashion, from a single console. > > Personal Loan: A user applies for a loan online, and the loan > application site requires him to provide certain third-party-attested > information, such as his salary, bank account, and credit score. This > information is best hosted directly out of the (several) authoritative > sites for it, but the user is able to package up references to all of > it and point the loan site to the package; the loan site can then > become a requester of each relevant resource. The user can see, from > a single place, whether the information has been successfully > received, and can keep a record of its access. (The webinar > wireframes show how this packaging might be achieved, along with > illustrating other potential parts of the user experience.) > > UMA currently solves its use cases, in part, with a composition of > three instances of OAuth (along with using XRD metadata and LRDD > discovery methods). The user introduces each host to the AM with > so-called "three-legged" (authn plus web delegation) OAuth as a > preface to other interactions. Each requester later dynamically > introduces itself to a host with the option of using > "two-legged" (authn only) OAuth, and then introduces itself to the AM > using two-legged OAuth -- we think of these as "automated > self-registration" of the services. The draft spec can be found here: > > http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core > +Protocol > > A few key points: > > - UMA wants to give users an opportunity, not just to set unilateral > policy (how long access is allowed over time, whether the user should > be asked for real-time consent in some fashion when access is > attempted, and so on), but also to set terms which the requester must > meet. This gives users new tools for control, and also enables some > interesting high-value use cases, involving requests for access on the > basis of third-party-attested claims. > > - There is a conceptual similarity between the UMA and WRAP entities, > but our analysis so far shows it to be shallow in spots. For example, > WRAP's "protected resource" maps fairly well to an UMA "host" (which > may host any number of protected resources), and WRAP's and OAuth's > "client"/"consumer" maps to an UMA "requester". However, it seems > that a WRAP authorization server is assumed to be in the same domain > as a protected resource, allowing for implicit rather than explicit > scoping of resources. The UMA authorization manager and any one host > may be in entirely separate domains, and introductions between them > are intended to be user-driven. > > Eve > > On 3 Feb 2010, at 9:34 AM, Eran Hammer-Lahav wrote: > > > Hi Anthony, > > > > The problem with this approach is that it hasn't worked (multiple > times) before because no one ever wants to do the work of collecting > and writing the use cases. What we get instead are short cryptic lists > and pointers to edge cases. We have a good grasp on how OAuth 1.0 is > used and its limitations as addressed by the WRAP draft. > > > > The best use of my time is to continue working on the drafts and > asking technical questions whenever a decision is needed. If and when > someone writes use cases, I will review those and see if they are > supported by the drafts. > > > > I will leave it up to the chairs to decide how they want to guide > the working group. > > > > EHL > > > >> -----Original Message----- > >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] > >> Sent: Wednesday, February 03, 2010 9:02 AM > >> To: Eran Hammer-Lahav; Dick Hardt > >> Cc: OAuth WG > >> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting > >> > >> I would tend to agree with Dick based upon the last call and where > >> that was heading. I believe that Eve had some use cases to share > >> around UMA > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Eran Hammer-Lahav > >> Sent: Wednesday, February 03, 2010 8:41 AM > >> To: Dick Hardt > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting > >> > >> Has anyone gathered and reviewed use cases? I haven't seen much of > >> that showing up on the list. From my experience, asking people for > >> use cases rarely works, unless someone is willing to do the work > and > >> collect them (and so far I haven't heard from such volunteer). I > much > >> prefer the process in which we produce a technical document based > on > >> OAuth 1.0 and the new requirements as defined by WRAP, and discuss > >> use cases as a property of the technical attributes of this draft. > >> > >> Of course, you don't have to agree with me, but that puts the > burden > >> of producing use cases documentation on you and others interested > in > >> taking that approach. We certainly have room for both, and keep in > >> mind that my token draft is not (yet) a working group item. > >> > >> The indication I received from many of the active members of this > >> list is that we have a strong desire to show up at Anaheim with > two > >> stable drafts. I think we are very close to getting the > >> authentication piece done following much of OAuth 1.0 > functionality > >> (only cleaner and better structures), as well as treating bearer > >> tokens as first class citizens. Given that no one has started a > >> discussion about the delegation flows to include, I doubt we will > >> have a stable second draft, but I plan on getting the > authentication piece stable in time. > >> > >> It has also been my experience over the past two years that the > >> biggest challenge is to figure out the authentication piece. The > 'go > >> get a token' piece tends to be much easier to agree on. If we get > the > >> authentication draft to a stable place, my intention is to leave > it > >> there and focus on the second part and come back to it as the > >> delegation requirements become clearer (if changes are needed). But > at least it gives us something stable to build upon. > >> > >> EHL > >> > >>> -----Original Message----- > >>> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >>> Sent: Wednesday, February 03, 2010 7:02 AM > >>> To: Eran Hammer-Lahav > >>> Cc: Peter Saint-Andre; OAuth WG > >>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting > >>> > >>> Hi Eran > >>> > >>> I think it is a little early in our phone discussions to get into > technical details. > >>> The next step according to the last call was to gather and review > use cases. > >>> Without rough consensus on what problem we are solving, your > points > >>> below (which all do need to be discussed at some point) is just > >>> moving around deck chairs on the Titanic. > >>> > >>> -- Dick > >>> > >>> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: > >>> > >>>> Please add: > >>>> > >>>> - Discuss Adobe's recent request to allow excluding the > host/port > >>>> from the > >>> signed message. > >>>> > >>>> - With regards to #4, how should the challenge identify the > token > >>>> to be > >>> used (realm comes free, do we need another)? > >>>> > >>>> - Should a single token support multiple signature algorithms? > This > >>>> has > >>> implications as to the information the client has to include with > >>> the request (the algorithm used, etc.). > >>>> > >>>> - Where should the token structure live? OAuth 1.0 includes two > >>>> response > >>> parameters (token and token_secret). However, since we are now > >>> moving towards having the algorithm part of the token definition, > as > >>> well as duration and other attributes, the server will need to > >>> provide this information to the client. This calls for a simple > >>> schema (can be any format but need to agree to consistent names). > It > >>> is currently part of the authorization/delegation draft > >>> (implicitly), but we should discuss moving it to the > authentication > >>> draft since that's where it is used (the > >> authorization draft simply hands those "things" > >>> out). > >>>> > >>>> EHL > > Eve Maler > eve@xmlgrrl.com > http://www.xmlgrrl.com/blog > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From tonynad@microsoft.com Thu Feb 4 15:05: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 CB4603A68B0 for ; Thu, 4 Feb 2010 15:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.995 X-Spam-Level: X-Spam-Status: No, score=-9.995 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Abm0Tpsvxyu3 for ; Thu, 4 Feb 2010 15:05:50 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id E21183A688D for ; Thu, 4 Feb 2010 15:05:49 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 4 Feb 2010 15:06:37 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.133]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Thu, 4 Feb 2010 15:06:31 -0800 From: Anthony Nadalin To: "Paul C. Bryan" , OAuth WG Thread-Topic: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second interim meeting) Thread-Index: AQHKpeqy6Y/Tg471gkaUjLHxmSgYXpG2kV7w Date: Thu, 4 Feb 2010 23:06:30 +0000 Message-ID: References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62C93B79-9FF8-4D26-B1A7-7A79C122CC0E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2B78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2BB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1265323056.2758.141.camel@localhost> In-Reply-To: <1265323056.2758.141.camel@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second 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, 04 Feb 2010 23:05:51 -0000 Agree on the measurable/enforceable items -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= aul C. Bryan Sent: Thursday, February 04, 2010 2:38 PM To: OAuth WG Subject: Re: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second i= nterim meeting) On Thu, 2010-02-04 at 19:17 +0000, Anthony Nadalin wrote: > > use UMA to require the requester to assure her they will not misuse > or further share her information >=20 > Not sure how UMA would be able to deal with this, if you look at=20 > things like the OECD Data Protection Principles (on which Privacy laws=20 > have been based) there are a lot of things considered misuse I don't imagine there would be any such term called "misuse" that a request= er would claim. There would be specific, possibly enforceable terms. Exampl= es: 1. Requester will retain accessed information for no longer than {n} days. 2. Requester will not share accessed information with any third party excep= t as required to comply with the laws of {region, ...}. Paul > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Eve Maler > Sent: Wednesday, February 03, 2010 10:54 AM > To: OAuth WG > Subject: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second=20 > interim meeting) >=20 > Sorry for the delay, and thanks for the push. In scrambling to=20 > approve a passel of scenarios and produce our webinar last week, we=20 > got a bit behind. (By the way, complete recordings are now available. > Their quality is not perfect, but should suffice. Please see=20 > http://kantarainitiative.org/confluence/display/uma/UMA+Explained for=20 > recordings, overview slides, protocol explanation slides, and example > wireframes.) >=20 > In order to inform the OAuth V2.0 effort, here is some information=20 > about key User-Managed Access (UMA) use cases and needs. The wiki=20 > home is at http://kantarainitiative.org/confluence/display/uma/Home ,=20 > and the sidebar on the right has links to all the available materials. >=20 > The focus of UMA is to externalize authorization decisions currently=20 > performed by OAuth SPs/servers into a fourth distinct entity we call=20 > an "authorization manager" or AM. Protected resources are hosted at=20 > endpoints called "hosts" and the endpoints seeking data/service access=20 > are called "requesters". An application embodying the AM endpoint can=20 > help the "authorizing user" globally manage what otherwise might be a=20 > complicated authorization picture among all the services accessing and=20 > sharing data about her, including letting her dictate policies for=20 > access authorization that the AM enforces. (If you're familiar with=20 > classic access management technology, the AM serves as a policy=20 > decision point and the hosts are policy enforcement points.) An AM=20 > provides the user with the ability to apply discretionary access=20 > controls for his/her resources. >=20 > The extensive information available about UMA includes a Scenarios and=20 > Use Cases document: >=20 > http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and > +Use+Cases >=20 > Here are summaries of two of the group's approved scenarios. >=20 > Calendaring: Online calendars, whose content is volatile, are valuable=20 > to share on an ongoing/"feed" basis. In somewhat the same fashion=20 > that people today share online calendars selectively with other=20 > people, a user can share a calendar with a vendor for various=20 > purposes. Prior to allowing the access, she might use UMA to require=20 > the requester to assure her they will not misuse or further share her=20 > information. Having authorized access to a particular resource, the=20 > user can then examine all the connections forged to all her shared=20 > resources in similar fashion, from a single console. >=20 > Personal Loan: A user applies for a loan online, and the loan=20 > application site requires him to provide certain third-party-attested=20 > information, such as his salary, bank account, and credit score. This=20 > information is best hosted directly out of the (several) authoritative=20 > sites for it, but the user is able to package up references to all of=20 > it and point the loan site to the package; the loan site can then=20 > become a requester of each relevant resource. The user can see, from=20 > a single place, whether the information has been successfully=20 > received, and can keep a record of its access. (The webinar=20 > wireframes show how this packaging might be achieved, along with=20 > illustrating other potential parts of the user experience.) >=20 > UMA currently solves its use cases, in part, with a composition of=20 > three instances of OAuth (along with using XRD metadata and LRDD=20 > discovery methods). The user introduces each host to the AM with=20 > so-called "three-legged" (authn plus web delegation) OAuth as a=20 > preface to other interactions. Each requester later dynamically=20 > introduces itself to a host with the option of using "two-legged"=20 > (authn only) OAuth, and then introduces itself to the AM using=20 > two-legged OAuth -- we think of these as "automated self-registration"=20 > of the services. The draft spec can be found here: >=20 > http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core > +Protocol >=20 > A few key points: >=20 > - UMA wants to give users an opportunity, not just to set unilateral=20 > policy (how long access is allowed over time, whether the user should=20 > be asked for real-time consent in some fashion when access is=20 > attempted, and so on), but also to set terms which the requester must=20 > meet. This gives users new tools for control, and also enables some=20 > interesting high-value use cases, involving requests for access on the=20 > basis of third-party-attested claims. >=20 > - There is a conceptual similarity between the UMA and WRAP entities,=20 > but our analysis so far shows it to be shallow in spots. For example,=20 > WRAP's "protected resource" maps fairly well to an UMA "host" (which=20 > may host any number of protected resources), and WRAP's and OAuth's=20 > "client"/"consumer" maps to an UMA "requester". However, it seems=20 > that a WRAP authorization server is assumed to be in the same domain=20 > as a protected resource, allowing for implicit rather than explicit=20 > scoping of resources. The UMA authorization manager and any one host=20 > may be in entirely separate domains, and introductions between them=20 > are intended to be user-driven. >=20 > Eve >=20 > On 3 Feb 2010, at 9:34 AM, Eran Hammer-Lahav wrote: >=20 > > Hi Anthony, > >=20 > > The problem with this approach is that it hasn't worked (multiple > times) before because no one ever wants to do the work of collecting=20 > and writing the use cases. What we get instead are short cryptic lists=20 > and pointers to edge cases. We have a good grasp on how OAuth 1.0 is=20 > used and its limitations as addressed by the WRAP draft. > >=20 > > The best use of my time is to continue working on the drafts and > asking technical questions whenever a decision is needed. If and when=20 > someone writes use cases, I will review those and see if they are=20 > supported by the drafts. > >=20 > > I will leave it up to the chairs to decide how they want to guide > the working group. > >=20 > > EHL > >=20 > >> -----Original Message----- > >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] > >> Sent: Wednesday, February 03, 2010 9:02 AM > >> To: Eran Hammer-Lahav; Dick Hardt > >> Cc: OAuth WG > >> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting > >>=20 > >> I would tend to agree with Dick based upon the last call and where=20 > >> that was heading. I believe that Eve had some use cases to share=20 > >> around UMA > >>=20 > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > >> Behalf Of Eran Hammer-Lahav > >> Sent: Wednesday, February 03, 2010 8:41 AM > >> To: Dick Hardt > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting > >>=20 > >> Has anyone gathered and reviewed use cases? I haven't seen much of=20 > >> that showing up on the list. From my experience, asking people for=20 > >> use cases rarely works, unless someone is willing to do the work > and > >> collect them (and so far I haven't heard from such volunteer). I > much > >> prefer the process in which we produce a technical document based > on > >> OAuth 1.0 and the new requirements as defined by WRAP, and discuss=20 > >> use cases as a property of the technical attributes of this draft. > >>=20 > >> Of course, you don't have to agree with me, but that puts the > burden > >> of producing use cases documentation on you and others interested > in > >> taking that approach. We certainly have room for both, and keep in=20 > >> mind that my token draft is not (yet) a working group item. > >>=20 > >> The indication I received from many of the active members of this=20 > >> list is that we have a strong desire to show up at Anaheim with > two > >> stable drafts. I think we are very close to getting the=20 > >> authentication piece done following much of OAuth 1.0 > functionality > >> (only cleaner and better structures), as well as treating bearer=20 > >> tokens as first class citizens. Given that no one has started a=20 > >> discussion about the delegation flows to include, I doubt we will=20 > >> have a stable second draft, but I plan on getting the > authentication piece stable in time. > >>=20 > >> It has also been my experience over the past two years that the=20 > >> biggest challenge is to figure out the authentication piece. The > 'go > >> get a token' piece tends to be much easier to agree on. If we get > the > >> authentication draft to a stable place, my intention is to leave > it > >> there and focus on the second part and come back to it as the=20 > >> delegation requirements become clearer (if changes are needed). But > at least it gives us something stable to build upon. > >>=20 > >> EHL > >>=20 > >>> -----Original Message----- > >>> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >>> Sent: Wednesday, February 03, 2010 7:02 AM > >>> To: Eran Hammer-Lahav > >>> Cc: Peter Saint-Andre; OAuth WG > >>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting > >>>=20 > >>> Hi Eran > >>>=20 > >>> I think it is a little early in our phone discussions to get into > technical details. > >>> The next step according to the last call was to gather and review > use cases. > >>> Without rough consensus on what problem we are solving, your > points > >>> below (which all do need to be discussed at some point) is just=20 > >>> moving around deck chairs on the Titanic. > >>>=20 > >>> -- Dick > >>>=20 > >>> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote: > >>>=20 > >>>> Please add: > >>>>=20 > >>>> - Discuss Adobe's recent request to allow excluding the > host/port > >>>> from the > >>> signed message. > >>>>=20 > >>>> - With regards to #4, how should the challenge identify the > token > >>>> to be > >>> used (realm comes free, do we need another)? > >>>>=20 > >>>> - Should a single token support multiple signature algorithms? > This > >>>> has > >>> implications as to the information the client has to include with=20 > >>> the request (the algorithm used, etc.). > >>>>=20 > >>>> - Where should the token structure live? OAuth 1.0 includes two=20 > >>>> response > >>> parameters (token and token_secret). However, since we are now=20 > >>> moving towards having the algorithm part of the token definition, > as > >>> well as duration and other attributes, the server will need to=20 > >>> provide this information to the client. This calls for a simple=20 > >>> schema (can be any format but need to agree to consistent names). > It > >>> is currently part of the authorization/delegation draft=20 > >>> (implicitly), but we should discuss moving it to the > authentication > >>> draft since that's where it is used (the > >> authorization draft simply hands those "things" > >>> out). > >>>>=20 > >>>> EHL >=20 > Eve Maler > eve@xmlgrrl.com > http://www.xmlgrrl.com/blog >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Thu Feb 4 15:19:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8444B3A6E78; Thu, 4 Feb 2010 15:19:31 -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 PM0du4gDFmf4; Thu, 4 Feb 2010 15:19:30 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AB5A53A6E70; Thu, 4 Feb 2010 15:19:30 -0800 (PST) Received: from leavealone.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 59ED440332; Thu, 4 Feb 2010 16:20:14 -0700 (MST) Message-ID: <4B6B562A.7010006@stpeter.im> Date: Thu, 04 Feb 2010 16:20:10 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 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="------------ms090803070502070603030103" Cc: IESG Secretary Subject: [OAUTH-WG] third OAuth 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, 04 Feb 2010 23:19:31 -0000 This is a cryptographically signed message in MIME format. --------------ms090803070502070603030103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The OAuth WG will hold its third in a series of virtual interim meetings on February 18, 2010, at 19:00 UTC. This will be a two-hour call to work through a number of open issues leading up to IETF 77. --------------ms090803070502070603030103 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 hvcNAQkFMQ8XDTEwMDIwNDIzMjAxMFowIwYJKoZIhvcNAQkEMRYEFHOCyw9qwrLze+066Gty Ztvd90uGMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAFcYuWEtzvFppKcvFnDXvMqTLjOFwt2bQTN5rpa32 +VldMExThwCY11NlMKWeGxKGLB6ukoViJF4u2lmv18o2LAmeZ8mc9zPqMte2hs1rG9VMZSo0 knfPBHGDLJpFvAPZfTr4/9DDT5DAyeS3rpEhFjZ4XbPG+tn3viPMFcTjVRWnWeAUcrFnE7yZ PvRmKhdFyKgc72KexFJ2ELEBSsHzv11Lu+HfzdzaIKY0oPxUfv71v8N8RvESbBnciUYVUpj5 lWQkGyMgvm4l2m8N53dBkWtPPrkKyO5ELt+e5HJoNlXBemMN1ziiz62wlkDC5rSpXhIrhTms TPq2PKLwTVXlOgAAAAAAAA== --------------ms090803070502070603030103-- From eran@hueniverse.com Thu Feb 4 15:26:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D333A6E87 for ; Thu, 4 Feb 2010 15:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 krMHJlKwELg3 for ; Thu, 4 Feb 2010 15:26:30 -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 952303A6E84 for ; Thu, 4 Feb 2010 15:26:30 -0800 (PST) Received: (qmail 20967 invoked from network); 4 Feb 2010 23:27:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Feb 2010 23:27:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 4 Feb 2010 16:27:05 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Thu, 4 Feb 2010 16:26:50 -0700 Thread-Topic: [OAUTH-WG] proposed agenda for second interim meeting Thread-Index: Acqkj+a9lzJH3q1LRSyqGkSaQ530hQAEQ2XQAFQfuoA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFBA305E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] proposed agenda for second 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, 04 Feb 2010 23:26:31 -0000 All these items are still open for discussion, even if we didn't get to the= m on the call. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Tuesday, February 02, 2010 11:25 PM > To: Peter Saint-Andre; OAuth WG > Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >=20 > Please add: >=20 > - Discuss Adobe's recent request to allow excluding the host/port from th= e > signed message. >=20 > - With regards to #4, how should the challenge identify the token to be u= sed > (realm comes free, do we need another)? >=20 > - Should a single token support multiple signature algorithms? This has > implications as to the information the client has to include with the req= uest > (the algorithm used, etc.). >=20 > - Where should the token structure live? OAuth 1.0 includes two response > parameters (token and token_secret). However, since we are now moving > towards having the algorithm part of the token definition, as well as dur= ation > and other attributes, the server will need to provide this information to= the > client. This calls for a simple schema (can be any format but need to agr= ee to > consistent names). It is currently part of the authorization/delegation d= raft > (implicitly), but we should discuss moving it to the authentication draft= since > that's where it is used (the authorization draft simply hands those "thin= gs" > out). >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Peter Saint-Andre > > Sent: Tuesday, February 02, 2010 9:15 PM > > To: OAuth WG > > Subject: [OAUTH-WG] proposed agenda for second interim meeting > > > > > > > > At the first interim meeting, we didn't get through our agenda: > > > > http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html > > > > Therefore I propose that this time we focus on some unfinished > > business, starting with the topic of authentication. I have reviewed > > all of the related threads on the list and have come up with the follow= ing > *rough* agenda. > > Your feedback is welcome to improve this (a.k.a. "agenda > > bashing") either on the list or during the meeting. > > > > For logistics information, see here: > > > > http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html > > > > ****** > > > > AGENDA > > > > Base proposal: draft-ietf-oauth-authentication-01 > > > > Eran had hoped to push out a new version in time for our meeting, but > > hasn't been able to get to it yet. However, I think we can continue to > > move forward with discussion. Feedback is welcome on the general > > approach, as well as specific open issues. > > > > Open issues.... > > > > Issue #1: Request Signing vs. API Signing vs. Message Signing > > http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html > > > > 1a. Seeming consensus for message signing. > > > > 1b. No consensus yet on message format. > > - JSON and textual key-value seem to be the leading candidates. > > > > 1c. Seeming consensus for multiple/extensible signature algorithms. > > - HMAC-SHA1 > > - HMAC-SHA256 > > - RSASSA-PKCS1-v1.5-SHA256 > > - PLAIN over SSL/TLS > > > > But: which of these are Mandatory-to-Implement? > > > > Issue #2: Include the Normalized Request with the Request? > > http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html > > > > Seeming consensus to not include the normalized request (e.g., > > signature string). > > > > Issue #3: Allow Secrets in Cleartext, or Require Channel Encryption? > > http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html > > > > Seeming consensus that channel encryption is must-implement (which > > does not necessarily mean must-deploy). > > > > Issue #4: Authentication Challenges > > http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html > > > > If an authentication (access) request is unacceptable, how does the > > server tell the client how it can provide proper credentials (e.g., by > > using a different algorithm)? > > > > Possible other topics: > > > > - Mutual auth? > > http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html > > > > - Resource authorization? > > http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html > > > > ****** > > > > /psa > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Thu Feb 4 15:39: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 1552A3A6E85 for ; Thu, 4 Feb 2010 15:39:07 -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 0Oz-35hL0HHf for ; Thu, 4 Feb 2010 15:39:06 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EB3CA3A68B8 for ; Thu, 4 Feb 2010 15:39:05 -0800 (PST) Received: from leavealone.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E0AEA40332 for ; Thu, 4 Feb 2010 16:39:49 -0700 (MST) Message-ID: <4B6B5AC0.7010703@stpeter.im> Date: Thu, 04 Feb 2010 16:39:44 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <4B69066C.5050809@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2A70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA305E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA305E@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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="------------ms060105060301070305090508" Subject: Re: [OAUTH-WG] proposed agenda for second 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, 04 Feb 2010 23:39:07 -0000 This is a cryptographically signed message in MIME format. --------------ms060105060301070305090508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Indeed. Feel free to start separate threads on each, add them to the issue tracker, etc. I'll be mostly offline (travelling) for the next 36 hours but will try to catch up then. Thanks to everyone who participated in today's call. On 2/4/10 4:26 PM, Eran Hammer-Lahav wrote: > All these items are still open for discussion, even if we didn't get to= them on the call. >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf= >> Of Eran Hammer-Lahav >> Sent: Tuesday, February 02, 2010 11:25 PM >> To: Peter Saint-Andre; OAuth WG >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting >> >> Please add: >> >> - Discuss Adobe's recent request to allow excluding the host/port from= the >> signed message. >> >> - With regards to #4, how should the challenge identify the token to b= e used >> (realm comes free, do we need another)? >> >> - Should a single token support multiple signature algorithms? This ha= s >> implications as to the information the client has to include with the = request >> (the algorithm used, etc.). >> >> - Where should the token structure live? OAuth 1.0 includes two respon= se >> parameters (token and token_secret). However, since we are now moving >> towards having the algorithm part of the token definition, as well as = duration >> and other attributes, the server will need to provide this information= to the >> client. This calls for a simple schema (can be any format but need to = agree to >> consistent names). It is currently part of the authorization/delegatio= n draft >> (implicitly), but we should discuss moving it to the authentication dr= aft since >> that's where it is used (the authorization draft simply hands those "t= hings" >> out). >> >> EHL >> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behal= f >>> Of Peter Saint-Andre >>> Sent: Tuesday, February 02, 2010 9:15 PM >>> To: OAuth WG >>> Subject: [OAUTH-WG] proposed agenda for second interim meeting >>> >>> >>> >>> At the first interim meeting, we didn't get through our agenda: >>> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html >>> >>> Therefore I propose that this time we focus on some unfinished >>> business, starting with the topic of authentication. I have reviewed >>> all of the related threads on the list and have come up with the foll= owing >> *rough* agenda. >>> Your feedback is welcome to improve this (a.k.a. "agenda >>> bashing") either on the list or during the meeting. >>> >>> For logistics information, see here: >>> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html >>> >>> ****** >>> >>> AGENDA >>> >>> Base proposal: draft-ietf-oauth-authentication-01 >>> >>> Eran had hoped to push out a new version in time for our meeting, but= >>> hasn't been able to get to it yet. However, I think we can continue t= o >>> move forward with discussion. Feedback is welcome on the general >>> approach, as well as specific open issues. >>> >>> Open issues.... >>> >>> Issue #1: Request Signing vs. API Signing vs. Message Signing >>> http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html >>> >>> 1a. Seeming consensus for message signing. >>> >>> 1b. No consensus yet on message format. >>> - JSON and textual key-value seem to be the leading candidates. >>> >>> 1c. Seeming consensus for multiple/extensible signature algorithms. >>> - HMAC-SHA1 >>> - HMAC-SHA256 >>> - RSASSA-PKCS1-v1.5-SHA256 >>> - PLAIN over SSL/TLS >>> >>> But: which of these are Mandatory-to-Implement? >>> >>> Issue #2: Include the Normalized Request with the Request? >>> http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html >>> >>> Seeming consensus to not include the normalized request (e.g., >>> signature string). >>> >>> Issue #3: Allow Secrets in Cleartext, or Require Channel Encryption? >>> http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html >>> >>> Seeming consensus that channel encryption is must-implement (which >>> does not necessarily mean must-deploy). >>> >>> Issue #4: Authentication Challenges >>> http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html >>> >>> If an authentication (access) request is unacceptable, how does the >>> server tell the client how it can provide proper credentials (e.g., b= y >>> using a different algorithm)? >>> >>> Possible other topics: >>> >>> - Mutual auth? >>> http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html >>> >>> - Resource authorization? >>> http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html >>> >>> ****** >>> >>> /psa >>> --------------ms060105060301070305090508 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 hvcNAQkFMQ8XDTEwMDIwNDIzMzk0NFowIwYJKoZIhvcNAQkEMRYEFLo5H/qRBueaIDOnh3dD 62QZoRZ2MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEATKD4j6NnRVsnCSSLQ0C583V8JN9EEQUGk0ZDakDc G5NbpByNV8rbZNtJ+h2A4e7pkXOR80vbe72dMlRwsZPuw2KNKNvctweDFOFSAS/2eYrAoEYQ inP40eGNilM9xk549MRws0eEV75BdUMiTgwz004qj0ArP+X0Yetisc2ekcE7B97FWzfCQ2+Z 5o++gn2A6wdEu7JALinsYNcYrbYf2YtyDLuIVMvqHBXo/1xLvEjx3u0VUEMeXGAm6JxkAUMW des3/ALCOlNt0mA2+roGuzXDOepaqynsUuojd+X9VG87+cI7LRY531POA38F1fqA7Fee4nAI mGRI97QBh7qDTwAAAAAAAA== --------------ms060105060301070305090508-- From eran@hueniverse.com Thu Feb 4 23:28:21 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129613A6EC4 for ; Thu, 4 Feb 2010 23:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 kyq2086tFe0Q for ; Thu, 4 Feb 2010 23:28:20 -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 3ED2F3A6EB8 for ; Thu, 4 Feb 2010 23:28:19 -0800 (PST) Received: (qmail 10591 invoked from network); 5 Feb 2010 07:29:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 5 Feb 2010 07:29:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 5 Feb 2010 00:28:52 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Fri, 5 Feb 2010 00:28:45 -0700 Thread-Topic: Which draft to use as a starting point for 'using a token'? Thread-Index: AcqmNNn9ICKDZvAtSGS8T1z8KSpllw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFDDD98F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Which draft to use as a starting point for 'using a token'? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 07:28:21 -0000 On the call today I clarified what is going on with all the different draft= s. In brief: draft-hammer-oauth - documentation of the OAuth 1.0 Rev A (with changes) pr= otocol. This is done and should be approved by the IESG shortly for publica= tion. draft-ietf-oauth-authentication - the part of OAuth 1.0 dealing with 'how t= o use a token after you obtain it'. draft-ietf-oauth-web-delegation - the part of OAuth 1.0 rev A dealing with = 'getting a token'. draft-hammer-http-token-auth - an alternative proposal (meant to replace dr= aft-ietf-oauth-authentication) which builds on top of OAuth 1.0 but cleans = up the structure and removes the client credentials when accessing protecte= d resources. It also changes how the request is normalized into a string be= fore signing. We have three options for moving forward with 'how to use a token'. Start w= ith: 1. draft-ietf-oauth-authentication 2. draft-hammer-http-token-auth 3. something else* * Do not suggest something else unless you are going to submit a proposal. = It doesn't have to be an I-D, I am happy to do the editorial work but I wil= l need a detailed proposal that is enough to turn into a specification. Pick. EHL From jpanzer@google.com Thu Feb 4 23:41: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 33B843A6D02 for ; Thu, 4 Feb 2010 23:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 16Oc-Ej9ewtW for ; Thu, 4 Feb 2010 23:41:10 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 98C6C3A6D07 for ; Thu, 4 Feb 2010 23:41:10 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o157fxCQ029027 for ; Thu, 4 Feb 2010 23:41:59 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265355719; bh=NzpyzU+i4vRHi4sizMqlF0a8TmQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hbBBRLsG1bSVWCwFANkduIl3CRlEbw8xXU27bMu4K9JYq7wWgYg/x53i/au1TAnKb A+9cgff17ChUknJY7clhQ== 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=C+8Ld9g+rY2xsjA5DkWX5nOX/2+WB6GEzuMCmzdnAWCKeU58M+jslYfNNGmxHSTDI OGtuUFobrMWk07EsxUtnA== Received: from yxe1 (yxe1.prod.google.com [10.190.2.1]) by wpaz9.hot.corp.google.com with ESMTP id o157fw8L031624 for ; Thu, 4 Feb 2010 23:41:58 -0800 Received: by yxe1 with SMTP id 1so3187806yxe.3 for ; Thu, 04 Feb 2010 23:41:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.151.89.33 with SMTP id r33mr3540853ybl.290.1265355718148; Thu, 04 Feb 2010 23:41:58 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFBA2DAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437DFBA2DAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Thu, 4 Feb 2010 23:41:38 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000e0cd707f2184251047ed59695 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 07:41:12 -0000 --000e0cd707f2184251047ed59695 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 4, 2010 at 12:02 AM, Eran Hammer-Lahav wrote: > Thanks John. > > > -----Original Message----- > > From: John Panzer [mailto:jpanzer@google.com] > > Sent: Tuesday, December 08, 2009 11:29 AM > > > Suggestion: It would be better to start with simple examples (bearer > token) > > which avoids the need to wade through concepts like timestamp > > synchronization and authentication coverage in order to understand the > > simplest possible flow? (E.g., the example in 1.2.) > > I am not worried about examples at this point. There will be plenty more if > this draft is adopted. > > > Suggestion: Make it clear up front that protected resources are allowed > and > > encouraged to put a WWW-Authenticate: header on all requests (even ones > > that return 200 for read-only access) to indicate what authentication is > > allowed in general. (The equivalent of the "login" link on web pages > that > > present a read-only view.) > > Is this consistent with common practice? > We successfully did it for all feeds on AOL Journals for several years, with no bug reports. I don't know if anyone has done a recent survey. It's certainly allowed by the protocol, and it's the simplest way to flag what kind of auth is available IMHO. > > > In general, I think that much of the text could be made simpler by > separating > > out the coverage="none" case from the other cases. At the moment the > > only method under discussion with coverage="none" is bearer token. I > think > > that's all there ever will be. If that's correct, perhaps separating out > things > > that way would lead to a simpler reading experience (for the bearer > token- > > users for sure, and possibly for everybody else as they don't have to > worry > > about the special case of coverage="none" over and over again.) > > Agreed. I still need to rework the 'none' methods. > > > Section 5: "A client making a request for a protected resource either > directly, > > or in retrying a request after receiving a 401 status code > > (Unauthorized) with a token challenge, MUST include at least one > > "Authorization" header field including token scheme credentials." > > - This could be read as forbidding clients from querying protected > resources > > before figuring out what Authorization: header to use (as they sometimes > > need to make an initial request to discover that the resource is > > protected). Possibly just rewording to "credentialled request"? What is > the > > right terminology here? > > Authenticated request. > > > Suggestion: Calling the token method "none" is odd and jarring. It > makes me > > think about the classic routine "Who's on first?". How about "bearer"? > As in, > > the method for request validation is to simply check that it bears the > token. > > Plain, bearer, unsigned, blue, whatever. Don't care. Others ok with > 'bearer'? > > > "relying solely on the > > value of the token identifier to authenticate the client" > > > > Surely we are authenticating the request in all these > > methods? (Authenticating the client may be a side effect, but it is > neither > > necessary nor sufficient.) > > Fixed. > > > Suggestion: Add a note (SHOULD) about using SSL / TLS when discussing > the > > bearer token option, either within this section or in the security > > considerations section (couldn't find one after some searching). It's > implied > > by the discussion in section 8.1 but it's difficult to parse out. > > I'm hoping to make this a MUST. > > > "The "coverage" > > attribute MUST be set to "none" but MAY be omitted from the request." > > > > This reads oddly -- I would assume that I can set it to anything if it's > omitted > > :). Suggestion: MUST be either set to "none", or omitted from the > request. > > Well, the value goes into the normalized string... > > > "Nevertheless, these attributes MUST be included in the normalized > request > > string together with any other authentication attributes." > > > > After quick read, I have no idea what this sentence means operationally. > Can > > you clarify? > > That when you create the normalized string, they are included even if they > are not sent on the wire. I tried to keep the normalized string consistent > regardless of method used. Does this sound like a good/bad idea? > > That makes sense, but perhaps it would be good to make it more explicit: The default values are explicitly included in the normalized string for purposes of generating the signature, even if not sent on the wire. (Are you sure it wouldn't be better to just eliminate default values entirely?) > EHL > --000e0cd707f2184251047ed59695 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 4, 2010 at 12:02 AM, Eran Hammer-Lah= av <eran@hueniv= erse.com> wrote:
Thanks John.

> -----Original Message-----
> From: John Panzer [mailto:jpanze= r@google.com]
> Sent: Tuesday, December 08, 2009 11:29 AM

> Suggestion: It would be better to start with simple examples (bearer t= oken)
> which avoids the need to wade through concepts like timestamp
> synchronization and authentication coverage in order to understand the=
> simplest possible flow? =A0(E.g., the example in 1.2.)

I am not worried about examples at this point. Ther= e will be plenty more if this draft is adopted.

> Suggestion: Make it clear up front that protected resources are allowe= d and
> encouraged to put a WWW-Authenticate: header on all requests (even one= s
> that return 200 for read-only access) to indicate what authentication = is
> allowed in general. =A0(The equivalent of the "login" link o= n web pages that
> present a read-only view.)

Is this consistent with common practice?

We successfully did it for all feeds on AOL Journals for several ye= ars, with no bug reports. =A0I don't know if anyone has done a recent s= urvey. =A0It's certainly allowed by the protocol, and it's the simp= lest way to flag what kind of auth is available IMHO. =A0
=A0

> In general, I think that much of the text could be made simpler by sep= arating
> out the coverage=3D"none" case from the other cases. =A0At t= he moment the
> only method under discussion with coverage=3D"none" is beare= r token. =A0I think
> that's all there ever will be. =A0If that's correct, perhaps s= eparating out things
> that way would lead to a simpler reading experience (for the bearer to= ken-
> users for sure, and possibly for everybody else as they don't have= to worry
> about the special case of coverage=3D"none" over and over ag= ain.)

Agreed. I still need to rework the 'none' methods.

> Section 5: "A client making a request for a protected resource ei= ther directly,
> =A0 =A0or in retrying a request after receiving a 401 status code
> =A0 =A0(Unauthorized) with a token challenge, MUST include at least on= e
> =A0 =A0"Authorization" header field including token scheme c= redentials."
> - This could be read as forbidding clients from querying protected res= ources
> before figuring out what Authorization: header to use (as they sometim= es
> need to make an initial request to discover that the resource is
> protected). =A0Possibly just rewording to "credentialled request&= quot;? =A0What is the
> right terminology here?

Authenticated request.

> Suggestion: =A0Calling the token method "none" is odd and ja= rring. =A0It makes me
> think about the classic routine "Who's on first?". =A0Ho= w about "bearer"? =A0As in,
> the method for request validation is to simply check that it bears the= token.

Plain, bearer, unsigned, blue, whatever. Don't care. Others ok wi= th 'bearer'?

> "relying solely on the
> value of the token identifier to authenticate the client"
>
> Surely we are authenticating the request in all these
> methods? =A0(Authenticating the client may be a side effect, but it is= neither
> necessary nor sufficient.)

Fixed.

> Suggestion: =A0Add a note (SHOULD) about using SSL / TLS when discussi= ng the
> bearer token option, either within this section or in the security
> considerations section (couldn't find one after some searching). = =A0It's implied
> by the discussion in section 8.1 but it's difficult to parse out.<= br>
I'm hoping to make this a MUST.

> "The "coverage"
> attribute MUST be set to "none" but MAY be omitted from the = request."
>
> This reads oddly -- I would assume that I can set it to anything if it= 's omitted
> :). =A0Suggestion: =A0MUST be either set to "none", or omitt= ed from the request.

Well, the value goes into the normalized string...

> "Nevertheless, these attributes MUST be included in the normalize= d request
> string together with any other authentication attributes."
>
> After quick read, I have no idea what this sentence means operationall= y. =A0Can
> you clarify?

That when you create the normalized string, they are included even if= they are not sent on the wire. I tried to keep the normalized string consi= stent regardless of method used. Does this sound like a good/bad idea?


That ma= kes sense, but perhaps it would be good to make it more explicit: The defau= lt values are explicitly included in the normalized string for purposes of = generating the signature, even if not sent on the wire.

(Are you sure it wouldn't be better to just elimina= te default values entirely?)
=A0
EHL

--000e0cd707f2184251047ed59695-- From eran@hueniverse.com Tue Feb 9 08:13:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AABC3A71D3 for ; Tue, 9 Feb 2010 08:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swDw7yZcxop4 for ; Tue, 9 Feb 2010 08: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 8E7AA3A73C7 for ; Tue, 9 Feb 2010 08:13:53 -0800 (PST) Received: (qmail 8194 invoked from network); 9 Feb 2010 16:15:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Feb 2010 16:15:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 9 Feb 2010 09:14:34 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Tue, 9 Feb 2010 09:15:02 -0700 Thread-Topic: FW: Salmon signatures proposal Thread-Index: AcqpowibG7Ye33yNShm3FBvjTpt2ZQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AyFR CMc2 DZA3 Damd E0tr FTTI Fpnx F/3n Gmlt HPk8 Hn/x H3qo IE9D Ig92 JZbC KHMB; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {50EB6742-E2BC-4B8A-B695-11CDA4D24415}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Tue, 09 Feb 2010 16:15:02 GMT; RgBXADoAIABTAGEAbABtAG8AbgAgAHMAaQBnAG4AYQB0AHUAcgBlAHMAIABwAHIAbwBwAG8AcwBhAGwA x-cr-puzzleid: {50EB6742-E2BC-4B8A-B695-11CDA4D24415} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] FW: Salmon signatures proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:13:56 -0000 http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.ht= ml This is relevant to our discussion about how to apply signatures to HTTP re= quests. EHL From eran@hueniverse.com Tue Feb 9 08:14: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 74C3428C219 for ; Tue, 9 Feb 2010 08:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 uf99QCZWZ5OH for ; Tue, 9 Feb 2010 08:14:27 -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 D16F128C214 for ; Tue, 9 Feb 2010 08:14:27 -0800 (PST) Received: (qmail 8098 invoked from network); 9 Feb 2010 16:15:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Feb 2010 16:15:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 9 Feb 2010 09:15:19 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Tue, 9 Feb 2010 09:15:40 -0700 Thread-Topic: Which draft to use as a starting point for 'using a token'? Thread-Index: AcqmNNn9ICKDZvAtSGS8T1z8KSpllwDbj7+Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Which draft to use as a starting point for 'using a token'? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:14:29 -0000 No one cares? EHL > -----Original Message----- > From: Eran Hammer-Lahav > Sent: Thursday, February 04, 2010 11:29 PM > To: OAuth WG (oauth@ietf.org) > Subject: Which draft to use as a starting point for 'using a token'? >=20 > On the call today I clarified what is going on with all the different dra= fts. In > brief: >=20 > draft-hammer-oauth - documentation of the OAuth 1.0 Rev A (with changes) > protocol. This is done and should be approved by the IESG shortly for > publication. >=20 > draft-ietf-oauth-authentication - the part of OAuth 1.0 dealing with 'how= to > use a token after you obtain it'. > draft-ietf-oauth-web-delegation - the part of OAuth 1.0 rev A dealing wit= h > 'getting a token'. >=20 > draft-hammer-http-token-auth - an alternative proposal (meant to replace > draft-ietf-oauth-authentication) which builds on top of OAuth 1.0 but cle= ans > up the structure and removes the client credentials when accessing > protected resources. It also changes how the request is normalized into a > string before signing. >=20 > We have three options for moving forward with 'how to use a token'. Start > with: >=20 > 1. draft-ietf-oauth-authentication > 2. draft-hammer-http-token-auth > 3. something else* >=20 > * Do not suggest something else unless you are going to submit a proposal= . It > doesn't have to be an I-D, I am happy to do the editorial work but I will= need > a detailed proposal that is enough to turn into a specification. >=20 > Pick. >=20 > EHL From email@pbryan.net Tue Feb 9 08:35:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3F93A7432 for ; Tue, 9 Feb 2010 08:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 oOKtmINZtGyY for ; Tue, 9 Feb 2010 08:35:34 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 406133A73EF for ; Tue, 9 Feb 2010 08:35:34 -0800 (PST) Received: from [192.168.0.5] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id A5DF9EA021 for ; Tue, 9 Feb 2010 16:36:40 +0000 (UTC) From: "Paul C. Bryan" To: "OAuth WG (oauth@ietf.org)" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Tue, 09 Feb 2010 08:36:34 -0800 Message-ID: <1265733394.19870.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:35:35 -0000 On Tue, 2010-02-09 at 09:15 -0700, Eran Hammer-Lahav wrote: > http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html > > This is relevant to our discussion about how to apply signatures to HTTP requests. Just to get the ball rolling then, if OAuth were to adopt magic signatures for its requests, then I think the ramifications would be: 1. Payload would need to be embedded in the data element of the signature, so we'd be duplicating payload to support digital signatures. 2. Some standardization of signer identifier (in the decoded data element) would need to be selected. 3. Presumably we would not be using LRDD/XRD to discover the public key of the signer, but rather use the key that server issues to client? Paul > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From email@pbryan.net Tue Feb 9 08:40: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 6514F28C225 for ; Tue, 9 Feb 2010 08:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 bbhnoBFeLwKI for ; Tue, 9 Feb 2010 08:40:37 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id D59FE28C10D for ; Tue, 9 Feb 2010 08:40:36 -0800 (PST) Received: from [192.168.0.5] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 8C90EEA021 for ; Tue, 9 Feb 2010 16:41:43 +0000 (UTC) From: "Paul C. Bryan" To: "OAuth WG (oauth@ietf.org)" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Tue, 09 Feb 2010 08:41:37 -0800 Message-ID: <1265733697.19870.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Which draft to use as a starting point for 'using a token'? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:40:38 -0000 For me, not so much care as believe I am in a qualified-enough position to vote on this one. I'm inclined to use draft-ietf-oauth-authentication. On Tue, 2010-02-09 at 09:15 -0700, Eran Hammer-Lahav wrote: > No one cares? > > EHL > > > -----Original Message----- > > From: Eran Hammer-Lahav > > Sent: Thursday, February 04, 2010 11:29 PM > > To: OAuth WG (oauth@ietf.org) > > Subject: Which draft to use as a starting point for 'using a token'? > > > > On the call today I clarified what is going on with all the different drafts. In > > brief: > > > > draft-hammer-oauth - documentation of the OAuth 1.0 Rev A (with changes) > > protocol. This is done and should be approved by the IESG shortly for > > publication. > > > > draft-ietf-oauth-authentication - the part of OAuth 1.0 dealing with 'how to > > use a token after you obtain it'. > > draft-ietf-oauth-web-delegation - the part of OAuth 1.0 rev A dealing with > > 'getting a token'. > > > > draft-hammer-http-token-auth - an alternative proposal (meant to replace > > draft-ietf-oauth-authentication) which builds on top of OAuth 1.0 but cleans > > up the structure and removes the client credentials when accessing > > protected resources. It also changes how the request is normalized into a > > string before signing. > > > > We have three options for moving forward with 'how to use a token'. Start > > with: > > > > 1. draft-ietf-oauth-authentication > > 2. draft-hammer-http-token-auth > > 3. something else* > > > > * Do not suggest something else unless you are going to submit a proposal. It > > doesn't have to be an I-D, I am happy to do the editorial work but I will need > > a detailed proposal that is enough to turn into a specification. > > > > Pick. > > > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From email@pbryan.net Tue Feb 9 08:45:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9029228C239 for ; Tue, 9 Feb 2010 08:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfS0TgYKVFIE for ; Tue, 9 Feb 2010 08:45:38 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id A0AD228C237 for ; Tue, 9 Feb 2010 08:45:38 -0800 (PST) Received: from [192.168.0.5] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 14A61EA021 for ; Tue, 9 Feb 2010 16:46:45 +0000 (UTC) From: "Paul C. Bryan" To: "OAuth WG (oauth@ietf.org)" In-Reply-To: <1265733394.19870.17.camel@localhost> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1265733394.19870.17.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Tue, 09 Feb 2010 08:46:39 -0800 Message-ID: <1265733999.19870.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:45:39 -0000 P.S. for #3, I meant to be for the symmetric-key cases. On Tue, 2010-02-09 at 08:36 -0800, Paul C. Bryan wrote: > On Tue, 2010-02-09 at 09:15 -0700, Eran Hammer-Lahav wrote: > > http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html > > > > This is relevant to our discussion about how to apply signatures to HTTP requests. > > Just to get the ball rolling then, if OAuth were to adopt magic > signatures for its requests, then I think the ramifications would be: > > 1. Payload would need to be embedded in the data element of the > signature, so we'd be duplicating payload to support digital signatures. > > 2. Some standardization of signer identifier (in the decoded data > element) would need to be selected. > > 3. Presumably we would not be using LRDD/XRD to discover the public key > of the signer, but rather use the key that server issues to client? > > Paul > > > > > EHL > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From rbarnes@bbn.com Tue Feb 9 09:58: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 22B533A71CD for ; Tue, 9 Feb 2010 09:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 MuRlzmpY0KIk for ; Tue, 9 Feb 2010 09:58:11 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0C66F3A690D for ; Tue, 9 Feb 2010 09:58:11 -0800 (PST) Received: from [128.89.254.254] (helo=[128.54.56.215]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NeuMn-0005ta-AH; Tue, 09 Feb 2010 12:59:17 -0500 Message-Id: From: "Richard L. Barnes" To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 9 Feb 2010 09:59:15 -0800 References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 17:58:12 -0000 Could you clarify how you think it's relevant? ISTM that the major parts of the document are: -- Format for encoding a signature on arbitrary binary data -- Key discovery process I don't think it really makes sense to use the magic envelope format for signing HTTP requests, mainly because there's no need to replicate the data (since TCP guarantees that the recipient gets same sequence of bytes that was sent). The only things in the signature besides the data are the encoding/algorithm IDs and the signature, which is a small enough, constrained enough set of information that the encoding isn't a huge deal. In particular, the magic signature system doesn't address what parts of the HTTP request get signed, and how they get normalized -- the hard question of OAuth. All it really does is raise the idea of just blindly signing bytes, which might be a good idea here: Just take the whole HTTP request with the OAuth header removed and sign/verify it as a sequence of bytes. That sort of signature probably wouldn't survive things like proxies, though. Are you proposing to use the key discovery process? Even there, it doesn't seem like there's a whole lot of utility, given that the other major work of this group is defining a key management system. Just confused, --Richard On Feb 9, 2010, at 8:15 AM, Eran Hammer-Lahav wrote: > http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html > > This is relevant to our discussion about how to apply signatures to > HTTP requests. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Tue Feb 9 10:09:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFAE728C139 for ; Tue, 9 Feb 2010 10:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.826 X-Spam-Level: X-Spam-Status: No, score=-103.826 tagged_above=-999 required=5 tests=[AWL=2.150, 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 ppJAGegZBzEd for ; Tue, 9 Feb 2010 10:09:44 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 05B0C3A6849 for ; Tue, 9 Feb 2010 10:09:43 -0800 (PST) Received: from spaceape14.eur.corp.google.com (spaceape14.eur.corp.google.com [172.28.16.148]) by smtp-out.google.com with ESMTP id o19IAnej002247 for ; Tue, 9 Feb 2010 18:10:49 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265739049; bh=ZQQkFCrMXt0u9jTnfdXV6up5PXE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=N9zO03/5RctzmxcJX1j6jSXOjUIh1Rzuqf12WYgawhFlcCIbhfIIxt8NbqtukLcZa XWAxuX2pt7SslkBVkdJmw== 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=eKBJxf4MwvAdbVvEdVD4LbpcLjA1ddDBoUh7/EnLiTJMUTLH6ZPE39YHSxJhjfLTm 6EyNTeeiKOtcErul+gCBw== Received: from gxk23 (gxk23.prod.google.com [10.202.11.23]) by spaceape14.eur.corp.google.com with ESMTP id o19IAkHm019843 for ; Tue, 9 Feb 2010 10:10:48 -0800 Received: by gxk23 with SMTP id 23so1411367gxk.2 for ; Tue, 09 Feb 2010 10:10:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.55.27 with SMTP id d27mr607085yba.124.1265739046103; Tue, 09 Feb 2010 10:10:46 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Tue, 9 Feb 2010 10:10:26 -0800 Message-ID: To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=000e0cd71b6a38ac53047f2ed6d9 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 18:09:46 -0000 --000e0cd71b6a38ac53047f2ed6d9 Content-Type: text/plain; charset=ISO-8859-1 Not arguing pro or con using this for HTTP message signing, but clarifying a few points: On Tue, Feb 9, 2010 at 9:59 AM, Richard L. Barnes wrote: > Could you clarify how you think it's relevant? > > ISTM that the major parts of the document are: > -- Format for encoding a signature on arbitrary binary data > -- Key discovery process > > I don't think it really makes sense to use the magic envelope format for > signing HTTP requests, mainly because there's no need to replicate the data > (since TCP guarantees that the recipient gets same sequence of bytes that > was sent). Only if you consider the 'recipient' and 'sender' to be the actual machines talking to the raw sockets. But fewer and fewer people are doing that today. Everyone is at least relying on an HTTP library (so the chunked encoding details are hidden from you), and most everybody is sitting on top of a stack or embedded within a framework that they can't easily change. E.g., by the time a message goes through Apache and to a JSP servlet container, it may well have already normalized data and converted character sets (by default you definitely get data converted to UCS-2 of course). And then of course there are proxies :). > The only things in the signature besides the data are the > encoding/algorithm IDs and the signature, which is a small enough, > constrained enough set of information that the encoding isn't a huge deal. > > In particular, the magic signature system doesn't address what parts of the > HTTP request get signed, and how they get normalized -- the hard question of > OAuth. All it really does is raise the idea of just blindly signing bytes, > which might be a good idea here: Just take the whole HTTP request with the > OAuth header removed and sign/verify it as a sequence of bytes. That sort of > signature probably wouldn't survive things like proxies, though. > The Magic Signature spec is unabashedly an enveloping system that takes the bytes and armors them. If you are dealing with a system that MUST understand your signature algorithm, you then don't have any need to send the original bytes, just the armored ones. (And do you really want someone relying on unsigned bytes?) At which point, if you're doing HTTP requests, you're effectively tunneling an HTTP request (the important part) inside a request payload. It's very, very ugly, and (it seems to me) is basically replicating SSL but at the wrong layer. > > Are you proposing to use the key discovery process? Even there, it doesn't > seem like there's a whole lot of utility, given that the other major work of > this group is defining a key management system. > I do hope that the key discovery process (starting from an identifier for an author/sender identifier) is something that is re-usable and generic. And specifically, if I have an OAuth public key signed message, along with an identifier for the service that signed it, I would very much like to use this mechanism for discovering public key(s) for the service. Since we can represent both services and people as URIs this seems fairly straightforward and reasonable. > > Just confused, > --Richard > > > > > On Feb 9, 2010, at 8:15 AM, Eran Hammer-Lahav wrote: > > >> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html >> >> This is relevant to our discussion about how to apply signatures to HTTP >> requests. >> >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd71b6a38ac53047f2ed6d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not arguing pro or con using this for HTTP message signing, but clarifying = a few points:

On Tue, Feb 9, 2010 at 9:59= AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
Could you clarify how you think it's re= levant?

ISTM that the major parts of the document are:
-- Format for encoding a signature on arbitrary binary data
-- Key discovery process

I don't think it really makes sense to use the magic envelope format fo= r signing HTTP requests, mainly because there's no need to replicate th= e data (since TCP guarantees that the recipient gets same sequence of bytes= that was sent).

Only if you consider the 'recipient' and 's= ender' to be the actual machines talking to the raw sockets. =A0But few= er and fewer people are doing that today. =A0Everyone is at least relying o= n an HTTP library (so the chunked encoding details are hidden from you), an= d most everybody is sitting on top of a stack or embedded within a framewor= k that they can't easily change. =A0E.g., by the time a message goes th= rough Apache and to a JSP servlet container, it may well have already norma= lized data and converted character sets (by default you definitely get data= converted to UCS-2 of course). =A0

And then of course there are proxies :).
=A0<= /div>
=A0The only things in the signature b= esides the data are the encoding/algorithm IDs and the signature, which is = a small enough, constrained enough set of information that the encoding isn= 't a huge deal.

In particular, the magic signature system doesn't address what parts of= the HTTP request get signed, and how they get normalized -- the hard quest= ion of OAuth. =A0All it really does is raise the idea of just blindly signi= ng bytes, which might be a good idea here: Just take the whole HTTP request= with the OAuth header removed and sign/verify it as a sequence of bytes. T= hat sort of signature probably wouldn't survive things like proxies, th= ough.

The Magic Signature spec is unabashedly an= enveloping system that takes the bytes and armors them. =A0If you are deal= ing with a system that MUST understand your signature algorithm, you then d= on't have any need to send the original bytes, just the armored ones. = =A0(And do you really want someone relying on unsigned bytes?) =A0At which = point, if you're doing HTTP requests, you're effectively tunneling = an HTTP request (the important part) inside a request payload. =A0It's = very, very ugly, and (it seems to me) is basically replicating SSL but at t= he wrong layer.
=A0

Are you proposing to use the key discovery process? =A0Even there, it doesn= 't seem like there's a whole lot of utility, given that the other m= ajor work of this group is defining a key management system.

I do hope that the key discovery process (starting from= an identifier for an author/sender identifier) is something that is re-usa= ble and generic. =A0And specifically, if I have an OAuth public key signed = message, along with an identifier for the service that signed it, I would v= ery much like to use this mechanism for discovering public key(s) for the s= ervice. =A0Since we can represent both services and people as URIs this see= ms fairly straightforward and reasonable.
=A0

Just confused,
--Richard




On Feb 9, 2010, at 8:15 AM, Eran Hammer-Lahav wrote:

http://salmon-protocol.googlecode.com/svn/= trunk/draft-panzer-magicsig-00.html

This is relevant to our discussion about how to apply signatures to HTTP re= quests.

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

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

--000e0cd71b6a38ac53047f2ed6d9-- From rbarnes@bbn.com Tue Feb 9 10:32:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225153A75A7 for ; Tue, 9 Feb 2010 10:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 x1M+3fam-lBG for ; Tue, 9 Feb 2010 10:32:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 348483A75A6 for ; Tue, 9 Feb 2010 10:32:41 -0800 (PST) Received: from [128.89.254.254] (helo=[128.54.56.215]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NeuuB-000H2X-OP; Tue, 09 Feb 2010 13:33:48 -0500 Message-Id: <0781C59D-C8F8-42CE-83A5-BFE818B2E348@bbn.com> From: "Richard L. Barnes" To: John Panzer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 9 Feb 2010 10:33:44 -0800 References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 18:32:42 -0000 Couple of other observations: > Only if you consider the 'recipient' and 'sender' to be the actual > machines talking to the raw sockets. But fewer and fewer people are > doing that today. Everyone is at least relying on an HTTP library > (so the chunked encoding details are hidden from you), and most > everybody is sitting on top of a stack or embedded within a > framework that they can't easily change. E.g., by the time a > message goes through Apache and to a JSP servlet container, it may > well have already normalized data and converted character sets (by > default you definitely get data converted to UCS-2 of course). That's a fair point, and one of the main challenges for figuring out what to sign ... > And then of course there are proxies :). ... this being the other :) > The Magic Signature spec is unabashedly an enveloping system that > takes the bytes and armors them. If you are dealing with a system > that MUST understand your signature algorithm, you then don't have > any need to send the original bytes, just the armored ones. (And do > you really want someone relying on unsigned bytes?) At which point, > if you're doing HTTP requests, you're effectively tunneling an HTTP > request (the important part) inside a request payload. It's very, > very ugly, and (it seems to me) is basically replicating SSL but at > the wrong layer. Beyond the ugliness, if you send both the armored and unarmored bytes, you're introducing a security risk. Namely, the recipient might validate the signature over the armored bytes, then go on to use the unarmored request, which could be completely unrelated. > I do hope that the key discovery process (starting from an > identifier for an author/sender identifier) is something that is re- > usable and generic. And specifically, if I have an OAuth public key > signed message, along with an identifier for the service that signed > it, I would very much like to use this mechanism for discovering > public key(s) for the service. Since we can represent both services > and people as URIs this seems fairly straightforward and reasonable. But it still seems separable from the authentication system. As usual, there's a "find the key for the client" step before the verification. That step is deliberately unspecified in order to allow for multiple key management systems to be used with the same authentication protocol. --Richard From faynberg@alcatel-lucent.com Tue Feb 9 10:57:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95AC3A75BA for ; Tue, 9 Feb 2010 10:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.768, 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 NbYjvjcGrivd for ; Tue, 9 Feb 2010 10:57:34 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id C889D3A75B0 for ; Tue, 9 Feb 2010 10:57:34 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o19IwbUv026263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2010 12:58:37 -0600 (CST) Received: from [135.244.36.87] (faynberg.lra.lucent.com [135.244.36.87]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o19Iwbuw023130; Tue, 9 Feb 2010 12:58:37 -0600 (CST) Message-ID: <4B71B05C.1060503@alcatel-lucent.com> Date: Tue, 09 Feb 2010 13:58:36 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Paul C. Bryan" References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1265733394.19870.17.camel@localhost> <1265733999.19870.22.camel@localhost> In-Reply-To: <1265733999.19870.22.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal 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: Tue, 09 Feb 2010 18:57:35 -0000 Paul C. Bryan wrote: > ... >> 1. Payload would need to be embedded in the data element of the >> signature, so we'd be duplicating payload to support digital signatures. >> >> Would not just hash of the payload be enough? Igor From email@pbryan.net Tue Feb 9 12:11: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 A449E28C16D for ; Tue, 9 Feb 2010 12:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 w5AcEM6sv8s7 for ; Tue, 9 Feb 2010 12:11:42 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 46CBF3A7451 for ; Tue, 9 Feb 2010 12:11:42 -0800 (PST) Received: from [192.168.0.5] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 3153DEA021 for ; Tue, 9 Feb 2010 20:12:49 +0000 (UTC) From: "Paul C. Bryan" To: "OAuth WG (oauth@ietf.org)" In-Reply-To: <4B71B05C.1060503@alcatel-lucent.com> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1265733394.19870.17.camel@localhost> <1265733999.19870.22.camel@localhost> <4B71B05C.1060503@alcatel-lucent.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 09 Feb 2010 12:06:19 -0800 Message-ID: <1265745979.19870.26.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 20:11:46 -0000 On Tue, 2010-02-09 at 13:58 -0500, Igor Faynberg wrote: > Paul C. Bryan wrote: > > ... > >> 1. Payload would need to be embedded in the data element of the > >> signature, so we'd be duplicating payload to support digital signatures. > >> > >> > Would not just hash of the payload be enough? I guess as long as there were rules on how to normalize the payload before hashing it. Paul > > Igor From faynberg@alcatel-lucent.com Tue Feb 9 12:39:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884753A6D1D for ; Tue, 9 Feb 2010 12:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.512, 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 jczi7dL6P1AM for ; Tue, 9 Feb 2010 12:39:21 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id B19953A72F4 for ; Tue, 9 Feb 2010 12:39:21 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o19KeS5V029472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2010 14:40:28 -0600 (CST) Received: from [135.244.36.87] (faynberg.lra.lucent.com [135.244.36.87]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o19KeRE7012942; Tue, 9 Feb 2010 14:40:27 -0600 (CST) Message-ID: <4B71C839.7010801@alcatel-lucent.com> Date: Tue, 09 Feb 2010 15:40:25 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Paul C. Bryan" References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1265733394.19870.17.camel@localhost> <1265733999.19870.22.camel@localhost> <4B71B05C.1060503@alcatel-lucent.com> <1265745979.19870.26.camel@localhost> In-Reply-To: <1265745979.19870.26.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal 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: Tue, 09 Feb 2010 20:39:22 -0000 But what would be a problem with just running a hash function over the payload as is? Seems to me that this way the recipient could check the validity of the signature for this particular payload, right? Or is there some strange case where the payload gets modified in transit legitimately? Igor Paul C. Bryan wrote: > On Tue, 2010-02-09 at 13:58 -0500, Igor Faynberg wrote: > >> Paul C. Bryan wrote: >> >>> ... >>> >>>> 1. Payload would need to be embedded in the data element of the >>>> signature, so we'd be duplicating payload to support digital signatures. >>>> >>>> >>>> >> Would not just hash of the payload be enough? >> > > I guess as long as there were rules on how to normalize the payload > before hashing it. > > Paul > > >> Igor >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From email@pbryan.net Tue Feb 9 12:43:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5992A3A726B for ; Tue, 9 Feb 2010 12:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 7rVV4W-RJfC8 for ; Tue, 9 Feb 2010 12:43:53 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 9983C3A6AD0 for ; Tue, 9 Feb 2010 12:43:53 -0800 (PST) Received: from [192.168.0.5] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 1E33AEA021 for ; Tue, 9 Feb 2010 20:44:59 +0000 (UTC) From: "Paul C. Bryan" To: "OAuth WG (oauth@ietf.org)" In-Reply-To: <4B71C839.7010801@alcatel-lucent.com> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1265733394.19870.17.camel@localhost> <1265733999.19870.22.camel@localhost> <4B71B05C.1060503@alcatel-lucent.com> <1265745979.19870.26.camel@localhost> <4B71C839.7010801@alcatel-lucent.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 09 Feb 2010 12:44:52 -0800 Message-ID: <1265748292.19870.36.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 20:43:54 -0000 On Tue, 2010-02-09 at 15:40 -0500, Igor Faynberg wrote: > But what would be a problem with just running a hash function over the > payload as is? Seems to me that this way the recipient could check the > validity of the signature for this particular payload, right? Or is > there some strange case where the payload gets modified in transit > legitimately? The payload would be: method, URI, protocol, headers and entity. Intermediaries (e.g. proxies) are known for (legitimately) modifying various parts of payload in transit, for example adding/removing/reordering headers. Paul > > Igor > > Paul C. Bryan wrote: > > On Tue, 2010-02-09 at 13:58 -0500, Igor Faynberg wrote: > > > >> Paul C. Bryan wrote: > >> > >>> ... > >>> > >>>> 1. Payload would need to be embedded in the data element of the > >>>> signature, so we'd be duplicating payload to support digital signatures. > >>>> > >>>> > >>>> > >> Would not just hash of the payload be enough? > >> > > > > I guess as long as there were rules on how to normalize the payload > > before hashing it. > > > > Paul > > > > > >> Igor > >> > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > From faynberg@alcatel-lucent.com Tue Feb 9 12:50: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 ABD4F3A6A80 for ; Tue, 9 Feb 2010 12:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, 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 WEIbFsSpqlyU for ; Tue, 9 Feb 2010 12:50:23 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id A0B8C28C126 for ; Tue, 9 Feb 2010 12:50:23 -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 o19KpUgp023807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2010 14:51:30 -0600 (CST) Received: from [135.244.36.87] (faynberg.lra.lucent.com [135.244.36.87]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o19KpTwQ023297; Tue, 9 Feb 2010 14:51:30 -0600 (CST) Message-ID: <4B71CAD0.8050906@alcatel-lucent.com> Date: Tue, 09 Feb 2010 15:51:28 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Paul C. Bryan" References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1265733394.19870.17.camel@localhost> <1265733999.19870.22.camel@localhost> <4B71B05C.1060503@alcatel-lucent.com> <1265745979.19870.26.camel@localhost> <4B71C839.7010801@alcatel-lucent.com> <1265748292.19870.36.camel@localhost> In-Reply-To: <1265748292.19870.36.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal 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: Tue, 09 Feb 2010 20:50:24 -0000 I dreaded that this might be the case. Then I agree it is necessary to normalize the payload, unless signing the entity only is sufficient. Igor Paul C. Bryan wrote: > On Tue, 2010-02-09 at 15:40 -0500, Igor Faynberg wrote: > >> But what would be a problem with just running a hash function over the >> payload as is? Seems to me that this way the recipient could check the >> validity of the signature for this particular payload, right? Or is >> there some strange case where the payload gets modified in transit >> legitimately? >> > > The payload would be: method, URI, protocol, headers and entity. > Intermediaries (e.g. proxies) are known for (legitimately) modifying > various parts of payload in transit, for example > adding/removing/reordering headers. > > Paul > > >> Igor >> >> Paul C. Bryan wrote: >> >>> On Tue, 2010-02-09 at 13:58 -0500, Igor Faynberg wrote: >>> >>> >>>> Paul C. Bryan wrote: >>>> >>>> >>>>> ... >>>>> >>>>> >>>>>> 1. Payload would need to be embedded in the data element of the >>>>>> signature, so we'd be duplicating payload to support digital signatures. >>>>>> >>>>>> >>>>>> >>>>>> >>>> Would not just hash of the payload be enough? >>>> >>>> >>> I guess as long as there were rules on how to normalize the payload >>> before hashing it. >>> >>> Paul >>> >>> >>> >>>> Igor >>>> >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From chasen@ironmoney.com Wed Feb 10 19:42:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85FD228C114 for ; Wed, 10 Feb 2010 19:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3w-G0vLls9W for ; Wed, 10 Feb 2010 19:42:53 -0800 (PST) Received: from mail-iw0-f199.google.com (mail-iw0-f199.google.com [209.85.223.199]) by core3.amsl.com (Postfix) with ESMTP id 48D6228C110 for ; Wed, 10 Feb 2010 19:42:53 -0800 (PST) Received: by iwn37 with SMTP id 37so866340iwn.22 for ; Wed, 10 Feb 2010 19:44:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.153.205 with SMTP id l13mr2019013ibw.64.1265859841646; Wed, 10 Feb 2010 19:44:01 -0800 (PST) In-Reply-To: References: <4c07358b1001212246n19850fe1n84ddf724267991c9@mail.gmail.com> Date: Wed, 10 Feb 2010 19:44:01 -0800 Message-ID: <4c07358b1002101944v721eac67pb8b3f874a75eaa28@mail.gmail.com> From: Chasen Le Hara To: oauth@ietf.org Content-Type: multipart/alternative; boundary=005045013bff3262ff047f4af6a4 Subject: Re: [OAUTH-WG] Resource permissions X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Feb 2010 03:42:54 -0000 --005045013bff3262ff047f4af6a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the feedback. That=E2=80=99s what I presumed and I=E2=80=99m gla= d I wasn=E2=80=99t missing anything. For the record, I ended up adding two comma-separated parameters to the request token request like so: read_permissions=3Duser&write_permission=3Daccounts,accounts/transactions [Documentation: https://ironmoney.com/api/permissions/] On Sat, Jan 23, 2010 at 6:08 PM, Blaine Cook wrote: > Hi Chasen, > > the general consensus is that this is something best handled by each > provider individually, since there are too many possible approaches to > permissions to be covered in the authorization spec. Flickr and > Twitter are good examples of how to do simple read/write permissions. > > b. > > 2010/1/22 Chasen Le Hara : > > Hi, > > I am currently implementing an API that uses OAuth. I=E2=80=99m includi= ng a basic > > resource authorization feature in my API that lets clients ask for > > read/write permissions to a number of resources while getting a request > > token (something like permissions=3D"read:/accounts/ > > write:/accounts/transactions/"). > > I know that this isn=E2=80=99t covered by 1.0a or the latest draft. Aft= er > searching > > for a bit, I found this functionality mentioned in this thread [1] and = a > > thread about OAuth Core 1.1 [2]. I haven=E2=80=99t seen any mention of = this since > > then, and I don=E2=80=99t believe this is being tackled by WRAP either. > > My question to the floor: is there a draft I=E2=80=99ve missed that inc= ludes > > this? Are there any APIs planned or shipping that have this > functionality? > > Is this something worth standardizing, or should each service provider = do > it > > their own way? > > -Chasen > > P.S. My apologies if I posted this to the wrong mailing list; I thought > this > > would be a better choice than the Google Groups list. > > [1] > https://groups.google.com/group/oauth/browse_thread/thread/e44310037ba355= e3/91cabf9061004d0a > > [2] > https://groups.google.com/group/oauth/browse_thread/thread/b4d71abb0ac81e= 60/878a35a9d355437b > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > --005045013bff3262ff047f4af6a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the feedback. That=E2=80=99s what I presumed and I=E2=80=99= m glad I wasn=E2=80=99t missing anything.

For the = record, I ended up adding two comma-separated parameters to the request tok= en request like so:

read_permissions=3Duser&write_permission=3Daccounts= ,accounts/transactions


On Sat, Jan 23, 2010 at 6:08= PM, Blaine Cook <= romeda@gmail.com> wrote:
Hi Chasen,

the general consensus is that this is something best handled by each
provider individually, since there are too many possible approaches to
permissions to be covered in the authorization spec. Flickr and
Twitter are good examples of how to do simple read/write permissions.

b.

2010/1/22 Chasen Le Hara <chasen= @ironmoney.com>:
> Hi,
> I am currently implementing an API that uses OAuth. I=E2=80=99m includ= ing a basic
> resource authorization feature in my API that lets clients ask for
> read/write permissions to a number of resources while getting a reques= t
> token (something like permissions=3D"read:/accounts/
> write:/accounts/transactions/").
> I know that this isn=E2=80=99t covered by 1.0a or the latest draft. Af= ter searching
> for a bit, I found this functionality mentioned in this thread [1] and= a
> thread about OAuth Core 1.1 [2].=C2=A0I haven=E2=80=99t seen any menti= on of this since
> then, and I don=E2=80=99t believe this is being tackled by WRAP either= .
> My question to the floor: is there a draft I=E2=80=99ve missed that in= cludes
> this?=C2=A0Are there any APIs planned or shipping that have this funct= ionality?
> Is this something worth standardizing, or should each service provider= do it
> their own way?
> -Chasen
> P.S. My apologies if I posted this to the wrong mailing list; I though= t this
> would be a better choice than the Google Groups list.
> [1]=C2=A0https://group= s.google.com/group/oauth/browse_thread/thread/e44310037ba355e3/91cabf906100= 4d0a
> [2]=C2=A0https://group= s.google.com/group/oauth/browse_thread/thread/b4d71abb0ac81e60/878a35a9d355= 437b
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--005045013bff3262ff047f4af6a4-- From dick.hardt@gmail.com Wed Feb 10 19:52: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 44FAF3A7255 for ; Wed, 10 Feb 2010 19:52:15 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjR4fvy5FomJ for ; Wed, 10 Feb 2010 19:52:14 -0800 (PST) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 4D19E3A7509 for ; Wed, 10 Feb 2010 19:52:14 -0800 (PST) Received: by pzk4 with SMTP id 4so209831pzk.5 for ; Wed, 10 Feb 2010 19:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=nPwJkyW7/gLYk96IEXcl5Dn2haZgGQCBQhs42sv3NXc=; b=oyRK6pgigQM6Ry5zlXE27wDa9WVmGI36CEDZ3KWMdhII9rJu2sLEvJqWO80dxkeU1t 6McKHg82C6gulvB+lQzh8Oh/c72/b4/JjkeHKLIU+DykNwCycPDfMIV7CBdQKVPwr8el pbbMFXkbXyEAjJgvLzkjyOzpk3M/3cOUytE4o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=nkMIi+wb+OwOnuciLljDK3JKzpH1nw5VSlQAaT8Wo5Q5olOyvaNNVL1yS8U9YWWzoJ lytPTmJNe5dquPZhhKHG7u8zYQ/93i7MiWCTn5e1+NSI3uDFmwGh8XHbL05VQqdfL8AH NkEkPqC7atSeaZrqVaEtL+ySpvMUEVQWm6Gwc= Received: by 10.141.13.6 with SMTP id q6mr781095rvi.146.1265860403163; Wed, 10 Feb 2010 19:53:23 -0800 (PST) Received: from ?192.168.1.236? (c-24-17-212-68.hsd1.wa.comcast.net [24.17.212.68]) by mx.google.com with ESMTPS id 21sm684779pzk.11.2010.02.10.19.53.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Feb 2010 19:53:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFDDD98F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 10 Feb 2010 19:53:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <99605412-342E-444E-8C61-83773C9D6669@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDD98F@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Which draft to use as a starting point for 'using a token'? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 03:52:15 -0000 How about using draft-hardt-oauth-wrap and adding a section for how the = Client can sign? -- Dick On 2010-02-04, at 11:28 PM, Eran Hammer-Lahav wrote: > On the call today I clarified what is going on with all the different = drafts. In brief: >=20 > draft-hammer-oauth - documentation of the OAuth 1.0 Rev A (with = changes) protocol. This is done and should be approved by the IESG = shortly for publication. >=20 > draft-ietf-oauth-authentication - the part of OAuth 1.0 dealing with = 'how to use a token after you obtain it'. > draft-ietf-oauth-web-delegation - the part of OAuth 1.0 rev A dealing = with 'getting a token'. >=20 > draft-hammer-http-token-auth - an alternative proposal (meant to = replace draft-ietf-oauth-authentication) which builds on top of OAuth = 1.0 but cleans up the structure and removes the client credentials when = accessing protected resources. It also changes how the request is = normalized into a string before signing. >=20 > We have three options for moving forward with 'how to use a token'. = Start with: >=20 > 1. draft-ietf-oauth-authentication > 2. draft-hammer-http-token-auth > 3. something else* >=20 > * Do not suggest something else unless you are going to submit a = proposal. It doesn't have to be an I-D, I am happy to do the editorial = work but I will need a detailed proposal that is enough to turn into a = specification. >=20 > Pick. >=20 > EHL >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From gbrail@sonoasystems.com Wed Feb 10 21:06: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 9F3FA28C17B for ; Wed, 10 Feb 2010 21:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5piQFMGWmPFh for ; Wed, 10 Feb 2010 21:06:11 -0800 (PST) Received: from usps.sonoasystems.com (65.105.207.194.ptr.us.xo.net [65.105.207.194]) by core3.amsl.com (Postfix) with ESMTP id 60D6628C177 for ; Wed, 10 Feb 2010 21:06:11 -0800 (PST) Received: from usps.sonoa.local ([10.20.0.244]) by usps.sonoa.local ([10.20.0.244]) with mapi; Wed, 10 Feb 2010 21:09:19 -0800 From: Greg Brail To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Wed, 10 Feb 2010 21:07:22 -0800 Thread-Topic: [OAUTH-WG] Which draft to use as a starting point for 'using a token'? Thread-Index: AcqmNNn9ICKDZvAtSGS8T1z8KSpllwDbj7+QAExxZyA= Message-ID: <48AE706BD74FCC4297AD778805CA46F6184C707B6F@usps.sonoa.local> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Which draft to use as a starting point for 'using a token'? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 05:06:12 -0000 Like a lot of people, I think, things are moving along and we're trying to = keep up. I do have a few more basic questions. Like it or not, the concept of a "consumer key" and "access token" is hard-= wired into many developers' perceptions of OAuth, and a major difference be= tween the two specs is that "ietf-oauth-authentication" retains both tokens= and "http-token-auth" does not. Given that today's OAuth-based applications are relying on having two token= s on each request, how would this work if "ietf-oauth-authentication" were = to be adopted? If a developer or API provider wishes to include some sort o= f "consumer key" on each request in addition to the token, how should that = be accomplished? One option would be to simply say, "we don't care -- just make it an additi= onal request parameter and call it what you want". But I think if that's th= e case then that has to be spelled out in the "release notes" for the new s= pecs somehow. (And no, I don't know what the right mechanism is for that in= IETF.) For instance, in a number of APIs I've been involved with recently, the "co= nsumer key" from OAuth 1.0 is NOT an "equivalent to a username" as describe= d in "ietf-oauth-authentication." Rather, it's used to uniquely identify th= e application that is calling an API. API providers usually wish to track n= ot only the user making a request (which can be inferred from the token), b= ut also which application was used and which developer wrote that applicati= on. A sophisticated back-end app can of course infer this information too f= rom the token, but I don't know what kind of back-end changes would be requ= ired to make that happen for an existing API, nor do I know whether your ty= pical API provider wishes to store that much state. Finally, I personally like "draft-hammer-http-token-auth" better because it= is more straightforward in that there is only one token and no need to mes= s around with signing it by constructing a key made out of two keys, and so= forth. I also like that there is some structure around the "WWW-Authentica= te" response, and the option to sign the entire request body or leave it un= signed. Finally, finally this time, would it be possible to have a link to "draft-h= ammer-http-token-auth" on the main OAuth IETF page? Google works fine but s= till it'd help. greg -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, February 09, 2010 11:16 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Which draft to use as a starting point for 'using a= token'? No one cares? EHL > -----Original Message----- > From: Eran Hammer-Lahav > Sent: Thursday, February 04, 2010 11:29 PM > To: OAuth WG (oauth@ietf.org) > Subject: Which draft to use as a starting point for 'using a token'? >=20 > On the call today I clarified what is going on with all the different dra= fts. In > brief: >=20 > draft-hammer-oauth - documentation of the OAuth 1.0 Rev A (with changes) > protocol. This is done and should be approved by the IESG shortly for > publication. >=20 > draft-ietf-oauth-authentication - the part of OAuth 1.0 dealing with 'how= to > use a token after you obtain it'. > draft-ietf-oauth-web-delegation - the part of OAuth 1.0 rev A dealing wit= h > 'getting a token'. >=20 > draft-hammer-http-token-auth - an alternative proposal (meant to replace > draft-ietf-oauth-authentication) which builds on top of OAuth 1.0 but cle= ans > up the structure and removes the client credentials when accessing > protected resources. It also changes how the request is normalized into a > string before signing. >=20 > We have three options for moving forward with 'how to use a token'. Start > with: >=20 > 1. draft-ietf-oauth-authentication > 2. draft-hammer-http-token-auth > 3. something else* >=20 > * Do not suggest something else unless you are going to submit a proposal= . It > doesn't have to be an I-D, I am happy to do the editorial work but I will= need > a detailed proposal that is enough to turn into a specification. >=20 > Pick. >=20 > EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Feb 10 22:13:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD38B28C19F for ; Wed, 10 Feb 2010 22:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 qwSTezmmZLgJ for ; Wed, 10 Feb 2010 22:13:40 -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 307C63A73F7 for ; Wed, 10 Feb 2010 22:13:39 -0800 (PST) Received: (qmail 2062 invoked from network); 11 Feb 2010 06:14:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Feb 2010 06:14:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 10 Feb 2010 23:14:24 -0700 From: Eran Hammer-Lahav To: Greg Brail , "OAuth WG (oauth@ietf.org)" Date: Wed, 10 Feb 2010 23:14:36 -0700 Thread-Topic: [OAUTH-WG] Which draft to use as a starting point for 'using a token'? Thread-Index: AcqmNNn9ICKDZvAtSGS8T1z8KSpllwDbj7+QAExxZyAAAvZEYA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438648F87FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C707B6F@usps.sonoa.local> In-Reply-To: <48AE706BD74FCC4297AD778805CA46F6184C707B6F@usps.sonoa.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Which draft to use as a starting point for 'using a token'? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 06:13:41 -0000 > -----Original Message----- > From: Greg Brail [mailto:gbrail@sonoasystems.com] > Sent: Wednesday, February 10, 2010 9:07 PM > To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] Which draft to use as a starting point for 'using= a > token'? >=20 > Like a lot of people, I think, things are moving along and we're trying t= o keep > up. I do have a few more basic questions. >=20 > Like it or not, the concept of a "consumer key" and "access token" is har= d- > wired into many developers' perceptions of OAuth, and a major difference > between the two specs is that "ietf-oauth-authentication" retains both > tokens and "http-token-auth" does not. This was the consensus a few months ago, that is, that when accessing resou= rces, only the token credentials will be used. > Given that today's OAuth-based applications are relying on having two > tokens on each request, how would this work if "ietf-oauth-authentication= " > were to be adopted? If a developer or API provider wishes to include some > sort of "consumer key" on each request in addition to the token, how shou= ld > that be accomplished? There are many ways (two you listed below), but the easiest is to simply en= code that information into the token itself. For example, if before your ap= plication issued a consumer key 'asb432' and token 'ffd4f3', it can issue t= oken using the new scheme 'asb432:ffd4f3' (with or without the colon, in pl= aintext or encoded, etc.). There is really no difference in how to send thi= s information over (in one parameter or two). > API providers usually wish to > track not only the user making a request (which can be inferred from the > token), but also which application was used and which developer wrote tha= t > application. Keep in mind that the client credentials can only be trusted in a few selec= t cases. It is being treated by most services as a hint, not as something t= o rely on.=20 > Finally, finally this time, would it be possible to have a link to "draft= -hammer- > http-token-auth" on the main OAuth IETF page? Google works fine but still > it'd help. That's for the chairs. EHL From eran@hueniverse.com Wed Feb 10 22:26: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 A2DE53A68EF for ; Wed, 10 Feb 2010 22:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 uTCWBrxDqxSa for ; Wed, 10 Feb 2010 22:26: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 16F383A73E0 for ; Wed, 10 Feb 2010 22:26:08 -0800 (PST) Received: (qmail 9767 invoked from network); 11 Feb 2010 06:27:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Feb 2010 06:27:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 10 Feb 2010 23:27:11 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Wed, 10 Feb 2010 23:27:08 -0700 Thread-Topic: [OAUTH-WG] Which draft to use as a starting point for 'using a token'? Thread-Index: AcqqzbtY3Hx/hPxVSp+ysyL5hJxHHAAA4dLw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438648F87FF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDD98F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <99605412-342E-444E-8C61-83773C9D6669@gmail.com> In-Reply-To: <99605412-342E-444E-8C61-83773C9D6669@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Which draft to use as a starting point for 'using a token'? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 06:26:11 -0000 > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Wednesday, February 10, 2010 7:53 PM > How about using draft-hardt-oauth-wrap and adding a section for how the > Client can sign? We might end up with something that looks just like that, but your suggesti= ons doesn't help me as an editor because you are offering a place to host t= he text and I am looking for the text itself. WRAP doesn't have an 'how to use a token' section to build upon - anything = that might go in there will need to be written from scratch (normalizing, s= igning, header structure, error handling, etc.). The challenge isn't findin= g a place to insert the 'using a token' text, but to find the best text to = use as a foundation. Once we figure that out, we will go through the same process for the 'how t= o get a token' text in which WRAP and the OAuth 1.0 text will be compared (= along with any other proposals people wish to make). When we have two stable drafts, we will have another discussion about mergi= ng the two drafts together. If WRAP ends up as the foundation for the other= part, we will end up with your proposal. EHL From eran@hueniverse.com Wed Feb 10 22:29: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 398D73A68EF for ; Wed, 10 Feb 2010 22:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.152, 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 679MZTIA6vTb for ; Wed, 10 Feb 2010 22:29: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 DCFFA3A682E for ; Wed, 10 Feb 2010 22:29:55 -0800 (PST) Received: (qmail 12988 invoked from network); 11 Feb 2010 06:31:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Feb 2010 06:31:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 10 Feb 2010 23:30:59 -0700 From: Eran Hammer-Lahav To: Chasen Le Hara , "oauth@ietf.org" Date: Wed, 10 Feb 2010 23:30:57 -0700 Thread-Topic: [OAUTH-WG] Resource permissions Thread-Index: AcqqzHA3iWi4E6lKTOyqnWYa0E3aJAAFu/sw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438648F8801@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4c07358b1001212246n19850fe1n84ddf724267991c9@mail.gmail.com> <4c07358b1002101944v721eac67pb8b3f874a75eaa28@mail.gmail.com> In-Reply-To: <4c07358b1002101944v721eac67pb8b3f874a75eaa28@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723438648F8801P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Resource permissions X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Feb 2010 06:29:58 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723438648F8801P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hpbGUgSSBhZ3JlZSB3aXRoIEJsYWlu4oCZcyBjb25jbHVzaW9uLCBJIHdvdWxkIGNoYXJhY3Rl cml6ZSBpdCBhIGJpdCBkaWZmZXJlbnRseTogdGhlcmUgY3VycmVudGx5IGlzIG5vIGdlbmVyYWwg Y29uc2Vuc3VzIGFzIHRvIHdoYXQgdGhlIGJlc3Qgd2F5IHRvIGFwcHJvYWNoIHRoaXMgaXMsIGFu ZCB3aGV0aGVyIHRoZXJlIGlzIHZhbHVlIGluIGEgZ2VuZXJpYyBwZXJtaXNzaW9uIHBhcmFtZXRl ci4gTXkgZmF2b3JpdGUgZXhhbXBsZSBpcyBoZWFsdGggcmVjb3JkcyBBUEkgaW4gd2hpY2ggcmVh ZGluZyBpcyB0aGUgbW9yZSBjcml0aWNhbCByaWdodCwgbm90IHdyaXRpbmcg4oCTIGl0IGlzIGp1 c3QgdmVyeSBkaWZmZXJlbnQgaW4gZWFjaCB1c2UgY2FzZSBhbmQgd2UgZG9u4oCZdCBoYXZlIGVu b3VnaCBleHBlcmllbmNlIHRvIHNlZSBhIHVzZWZ1bCBwYXR0ZXJuLg0KDQpFSEwNCg0KRnJvbTog b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBDaGFzZW4gTGUgSGFyYQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMCwg MjAxMCA3OjQ0IFBNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IFJlc291cmNlIHBlcm1pc3Npb25zDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiBUaGF04oCZ cyB3aGF0IEkgcHJlc3VtZWQgYW5kIEnigJltIGdsYWQgSSB3YXNu4oCZdCBtaXNzaW5nIGFueXRo aW5nLg0KDQpGb3IgdGhlIHJlY29yZCwgSSBlbmRlZCB1cCBhZGRpbmcgdHdvIGNvbW1hLXNlcGFy YXRlZCBwYXJhbWV0ZXJzIHRvIHRoZSByZXF1ZXN0IHRva2VuIHJlcXVlc3QgbGlrZSBzbzoNCg0K cmVhZF9wZXJtaXNzaW9ucz11c2VyJndyaXRlX3Blcm1pc3Npb249YWNjb3VudHMsYWNjb3VudHMv dHJhbnNhY3Rpb25zDQoNCltEb2N1bWVudGF0aW9uOiBodHRwczovL2lyb25tb25leS5jb20vYXBp L3Blcm1pc3Npb25zL10NCg0KT24gU2F0LCBKYW4gMjMsIDIwMTAgYXQgNjowOCBQTSwgQmxhaW5l IENvb2sgPHJvbWVkYUBnbWFpbC5jb208bWFpbHRvOnJvbWVkYUBnbWFpbC5jb20+PiB3cm90ZToN CkhpIENoYXNlbiwNCg0KdGhlIGdlbmVyYWwgY29uc2Vuc3VzIGlzIHRoYXQgdGhpcyBpcyBzb21l dGhpbmcgYmVzdCBoYW5kbGVkIGJ5IGVhY2gNCnByb3ZpZGVyIGluZGl2aWR1YWxseSwgc2luY2Ug dGhlcmUgYXJlIHRvbyBtYW55IHBvc3NpYmxlIGFwcHJvYWNoZXMgdG8NCnBlcm1pc3Npb25zIHRv IGJlIGNvdmVyZWQgaW4gdGhlIGF1dGhvcml6YXRpb24gc3BlYy4gRmxpY2tyIGFuZA0KVHdpdHRl ciBhcmUgZ29vZCBleGFtcGxlcyBvZiBob3cgdG8gZG8gc2ltcGxlIHJlYWQvd3JpdGUgcGVybWlz c2lvbnMuDQoNCmIuDQoNCjIwMTAvMS8yMiBDaGFzZW4gTGUgSGFyYSA8Y2hhc2VuQGlyb25tb25l eS5jb208bWFpbHRvOmNoYXNlbkBpcm9ubW9uZXkuY29tPj46DQo+IEhpLA0KPiBJIGFtIGN1cnJl bnRseSBpbXBsZW1lbnRpbmcgYW4gQVBJIHRoYXQgdXNlcyBPQXV0aC4gSeKAmW0gaW5jbHVkaW5n IGEgYmFzaWMNCj4gcmVzb3VyY2UgYXV0aG9yaXphdGlvbiBmZWF0dXJlIGluIG15IEFQSSB0aGF0 IGxldHMgY2xpZW50cyBhc2sgZm9yDQo+IHJlYWQvd3JpdGUgcGVybWlzc2lvbnMgdG8gYSBudW1i ZXIgb2YgcmVzb3VyY2VzIHdoaWxlIGdldHRpbmcgYSByZXF1ZXN0DQo+IHRva2VuIChzb21ldGhp bmcgbGlrZSBwZXJtaXNzaW9ucz0icmVhZDovYWNjb3VudHMvDQo+IHdyaXRlOi9hY2NvdW50cy90 cmFuc2FjdGlvbnMvIikuDQo+IEkga25vdyB0aGF0IHRoaXMgaXNu4oCZdCBjb3ZlcmVkIGJ5IDEu MGEgb3IgdGhlIGxhdGVzdCBkcmFmdC4gQWZ0ZXIgc2VhcmNoaW5nDQo+IGZvciBhIGJpdCwgSSBm b3VuZCB0aGlzIGZ1bmN0aW9uYWxpdHkgbWVudGlvbmVkIGluIHRoaXMgdGhyZWFkIFsxXSBhbmQg YQ0KPiB0aHJlYWQgYWJvdXQgT0F1dGggQ29yZSAxLjEgWzJdLiBJIGhhdmVu4oCZdCBzZWVuIGFu eSBtZW50aW9uIG9mIHRoaXMgc2luY2UNCj4gdGhlbiwgYW5kIEkgZG9u4oCZdCBiZWxpZXZlIHRo aXMgaXMgYmVpbmcgdGFja2xlZCBieSBXUkFQIGVpdGhlci4NCj4gTXkgcXVlc3Rpb24gdG8gdGhl IGZsb29yOiBpcyB0aGVyZSBhIGRyYWZ0IEnigJl2ZSBtaXNzZWQgdGhhdCBpbmNsdWRlcw0KPiB0 aGlzPyBBcmUgdGhlcmUgYW55IEFQSXMgcGxhbm5lZCBvciBzaGlwcGluZyB0aGF0IGhhdmUgdGhp cyBmdW5jdGlvbmFsaXR5Pw0KPiBJcyB0aGlzIHNvbWV0aGluZyB3b3J0aCBzdGFuZGFyZGl6aW5n LCBvciBzaG91bGQgZWFjaCBzZXJ2aWNlIHByb3ZpZGVyIGRvIGl0DQo+IHRoZWlyIG93biB3YXk/ DQo+IC1DaGFzZW4NCj4gUC5TLiBNeSBhcG9sb2dpZXMgaWYgSSBwb3N0ZWQgdGhpcyB0byB0aGUg d3JvbmcgbWFpbGluZyBsaXN0OyBJIHRob3VnaHQgdGhpcw0KPiB3b3VsZCBiZSBhIGJldHRlciBj aG9pY2UgdGhhbiB0aGUgR29vZ2xlIEdyb3VwcyBsaXN0Lg0KPiBbMV0gaHR0cHM6Ly9ncm91cHMu Z29vZ2xlLmNvbS9ncm91cC9vYXV0aC9icm93c2VfdGhyZWFkL3RocmVhZC9lNDQzMTAwMzdiYTM1 NWUzLzkxY2FiZjkwNjEwMDRkMGENCj4gWzJdIGh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vZ3Jv dXAvb2F1dGgvYnJvd3NlX3RocmVhZC90aHJlYWQvYjRkNzFhYmIwYWM4MWU2MC84NzhhMzVhOWQz NTU0MzdiDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4N Cj4NCg0K --_000_90C41DD21FB7C64BB94121FBBC2E723438648F8801P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBs ZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5XaGlsZSBJIGFncmVlIHdpdGggQmxhaW7igJlzIGNvbmNsdXNpb24sIEkgd291 bGQgY2hhcmFjdGVyaXplIGl0IGEgYml0IGRpZmZlcmVudGx5OiB0aGVyZSBjdXJyZW50bHkgaXMg bm8gZ2VuZXJhbCBjb25zZW5zdXMgYXMgdG8gd2hhdCB0aGUgYmVzdCB3YXkgdG8gYXBwcm9hY2gg dGhpcyBpcywgYW5kIHdoZXRoZXIgdGhlcmUgaXMgdmFsdWUgaW4gYSBnZW5lcmljIHBlcm1pc3Np b24gcGFyYW1ldGVyLiBNeSBmYXZvcml0ZSBleGFtcGxlIGlzIGhlYWx0aCByZWNvcmRzIEFQSSBp biB3aGljaCByZWFkaW5nIGlzIHRoZSBtb3JlIGNyaXRpY2FsIHJpZ2h0LCBub3Qgd3JpdGluZyDi gJMgaXQgaXMganVzdCB2ZXJ5IGRpZmZlcmVudCBpbiBlYWNoIHVzZSBjYXNlIGFuZCB3ZSBkb27i gJl0IGhhdmUgZW5vdWdoIGV4cGVyaWVuY2UgdG8gc2VlIGEgdXNlZnVsIHBhdHRlcm4uPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5FSEw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9 TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IG9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYg T2YgPC9iPkNoYXNlbiBMZSBIYXJhPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDEwLCAyMDEwIDc6NDQgUE08YnI+PGI+VG86PC9iPiBvYXV0aEBpZXRmLm9yZzxicj48Yj5TdWJq ZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVzb3VyY2UgcGVybWlzc2lvbnM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiBUaGF0 4oCZcyB3aGF0IEkgcHJlc3VtZWQgYW5kIEnigJltIGdsYWQgSSB3YXNu4oCZdCBtaXNzaW5nIGFu eXRoaW5nLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkZvciB0aGUgcmVj b3JkLCBJIGVuZGVkIHVwIGFkZGluZyB0d28gY29tbWEtc2VwYXJhdGVkIHBhcmFtZXRlcnMgdG8g dGhlIHJlcXVlc3QgdG9rZW4gcmVxdWVzdCBsaWtlIHNvOjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPnJlYWRfcGVybWlzc2lvbnM9dXNlciZhbXA7d3JpdGVfcGVybWlzc2lv bj1hY2NvdW50cyxhY2NvdW50cy90cmFuc2FjdGlvbnM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5bRG9jdW1lbnRhdGlvbjombmJzcDs8YSBocmVmPSJodHRwczovL2lyb25t b25leS5jb20vYXBpL3Blcm1pc3Npb25zLyI+aHR0cHM6Ly9pcm9ubW9uZXkuY29tL2FwaS9wZXJt aXNzaW9ucy88L2E+XTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ T24gU2F0LCBKYW4gMjMsIDIwMTAgYXQgNjowOCBQTSwgQmxhaW5lIENvb2sgJmx0OzxhIGhyZWY9 Im1haWx0bzpyb21lZGFAZ21haWwuY29tIj5yb21lZGFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkhpIENoYXNlbiw8YnI+PGJyPnRoZSBn ZW5lcmFsIGNvbnNlbnN1cyBpcyB0aGF0IHRoaXMgaXMgc29tZXRoaW5nIGJlc3QgaGFuZGxlZCBi eSBlYWNoPGJyPnByb3ZpZGVyIGluZGl2aWR1YWxseSwgc2luY2UgdGhlcmUgYXJlIHRvbyBtYW55 IHBvc3NpYmxlIGFwcHJvYWNoZXMgdG88YnI+cGVybWlzc2lvbnMgdG8gYmUgY292ZXJlZCBpbiB0 aGUgYXV0aG9yaXphdGlvbiBzcGVjLiBGbGlja3IgYW5kPGJyPlR3aXR0ZXIgYXJlIGdvb2QgZXhh bXBsZXMgb2YgaG93IHRvIGRvIHNpbXBsZSByZWFkL3dyaXRlIHBlcm1pc3Npb25zLjxicj48YnI+ Yi48YnI+PGJyPjIwMTAvMS8yMiBDaGFzZW4gTGUgSGFyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNo YXNlbkBpcm9ubW9uZXkuY29tIj5jaGFzZW5AaXJvbm1vbmV5LmNvbTwvYT4mZ3Q7OjxvOnA+PC9v OnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyBIaSw8YnI+Jmd0OyBJIGFt IGN1cnJlbnRseSBpbXBsZW1lbnRpbmcgYW4gQVBJIHRoYXQgdXNlcyBPQXV0aC4gSeKAmW0gaW5j bHVkaW5nIGEgYmFzaWM8YnI+Jmd0OyByZXNvdXJjZSBhdXRob3JpemF0aW9uIGZlYXR1cmUgaW4g bXkgQVBJIHRoYXQgbGV0cyBjbGllbnRzIGFzayBmb3I8YnI+Jmd0OyByZWFkL3dyaXRlIHBlcm1p c3Npb25zIHRvIGEgbnVtYmVyIG9mIHJlc291cmNlcyB3aGlsZSBnZXR0aW5nIGEgcmVxdWVzdDxi cj4mZ3Q7IHRva2VuIChzb21ldGhpbmcgbGlrZSBwZXJtaXNzaW9ucz0mcXVvdDtyZWFkOi9hY2Nv dW50cy88YnI+Jmd0OyB3cml0ZTovYWNjb3VudHMvdHJhbnNhY3Rpb25zLyZxdW90OykuPGJyPiZn dDsgSSBrbm93IHRoYXQgdGhpcyBpc27igJl0IGNvdmVyZWQgYnkgMS4wYSBvciB0aGUgbGF0ZXN0 IGRyYWZ0LiBBZnRlciBzZWFyY2hpbmc8YnI+Jmd0OyBmb3IgYSBiaXQsIEkgZm91bmQgdGhpcyBm dW5jdGlvbmFsaXR5IG1lbnRpb25lZCBpbiB0aGlzIHRocmVhZCBbMV0gYW5kIGE8YnI+Jmd0OyB0 aHJlYWQgYWJvdXQgT0F1dGggQ29yZSAxLjEgWzJdLiZuYnNwO0kgaGF2ZW7igJl0IHNlZW4gYW55 IG1lbnRpb24gb2YgdGhpcyBzaW5jZTxicj4mZ3Q7IHRoZW4sIGFuZCBJIGRvbuKAmXQgYmVsaWV2 ZSB0aGlzIGlzIGJlaW5nIHRhY2tsZWQgYnkgV1JBUCBlaXRoZXIuPGJyPiZndDsgTXkgcXVlc3Rp b24gdG8gdGhlIGZsb29yOiBpcyB0aGVyZSBhIGRyYWZ0IEnigJl2ZSBtaXNzZWQgdGhhdCBpbmNs dWRlczxicj4mZ3Q7IHRoaXM/Jm5ic3A7QXJlIHRoZXJlIGFueSBBUElzIHBsYW5uZWQgb3Igc2hp cHBpbmcgdGhhdCBoYXZlIHRoaXMgZnVuY3Rpb25hbGl0eT88YnI+Jmd0OyBJcyB0aGlzIHNvbWV0 aGluZyB3b3J0aCBzdGFuZGFyZGl6aW5nLCBvciBzaG91bGQgZWFjaCBzZXJ2aWNlIHByb3ZpZGVy IGRvIGl0PGJyPiZndDsgdGhlaXIgb3duIHdheT88YnI+Jmd0OyAtQ2hhc2VuPGJyPiZndDsgUC5T LiBNeSBhcG9sb2dpZXMgaWYgSSBwb3N0ZWQgdGhpcyB0byB0aGUgd3JvbmcgbWFpbGluZyBsaXN0 OyBJIHRob3VnaHQgdGhpczxicj4mZ3Q7IHdvdWxkIGJlIGEgYmV0dGVyIGNob2ljZSB0aGFuIHRo ZSBHb29nbGUgR3JvdXBzIGxpc3QuPGJyPiZndDsgWzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9n cm91cHMuZ29vZ2xlLmNvbS9ncm91cC9vYXV0aC9icm93c2VfdGhyZWFkL3RocmVhZC9lNDQzMTAw MzdiYTM1NWUzLzkxY2FiZjkwNjEwMDRkMGEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dyb3Vw cy5nb29nbGUuY29tL2dyb3VwL29hdXRoL2Jyb3dzZV90aHJlYWQvdGhyZWFkL2U0NDMxMDAzN2Jh MzU1ZTMvOTFjYWJmOTA2MTAwNGQwYTwvYT48YnI+Jmd0OyBbMl0mbmJzcDs8YSBocmVmPSJodHRw czovL2dyb3Vwcy5nb29nbGUuY29tL2dyb3VwL29hdXRoL2Jyb3dzZV90aHJlYWQvdGhyZWFkL2I0 ZDcxYWJiMGFjODFlNjAvODc4YTM1YTlkMzU1NDM3YiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v Z3JvdXBzLmdvb2dsZS5jb20vZ3JvdXAvb2F1dGgvYnJvd3NlX3RocmVhZC90aHJlYWQvYjRkNzFh YmIwYWM4MWU2MC84NzhhMzVhOWQzNTU0MzdiPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsgPGEgaHJl Zj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+Jmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48 YnI+Jmd0Ozxicj4mZ3Q7PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_90C41DD21FB7C64BB94121FBBC2E723438648F8801P3PW5EX1MB01E_-- From James.H.Manger@team.telstra.com Wed Feb 10 22:57:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E873A7442 for ; Wed, 10 Feb 2010 22:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCIObOiwTX07 for ; Wed, 10 Feb 2010 22:57:57 -0800 (PST) Received: from mailipbo.vtcif.telstra.com.au (mailipbo.vtcif.telstra.com.au [202.12.144.29]) by core3.amsl.com (Postfix) with ESMTP id B48843A7654 for ; Wed, 10 Feb 2010 22:57:56 -0800 (PST) Received: from maili.vtcif.telstra.com.au (HELO mailai.vtcif.telstra.com.au) ([202.12.142.17]) by mailipbi.vtcif.telstra.com.au with ESMTP; 11 Feb 2010 17:59:08 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id 333731DA81; Thu, 11 Feb 2010 17:59:08 +1100 (EST) Received: from WSMSG3751.srv.dir.telstra.com (wsmsg3751.srv.dir.telstra.com [172.49.40.172]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA12163; Thu, 11 Feb 2010 17:59:07 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Thu, 11 Feb 2010 17:59:07 +1100 From: "Manger, James H" To: "OAuth WG (oauth@ietf.org)" , John Panzer Date: Thu, 11 Feb 2010 17:59:05 +1100 Thread-Topic: FW: Salmon signatures proposal - base64url Thread-Index: AcqpowibG7Ye33yNShm3FBvjTpt2ZQBPSNdg Message-ID: <255B9BB34FB7D647A506DC292726F6E112506F4872@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal - base64url X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Feb 2010 06:57:57 -0000 Sm9obiwNCg0KSSBsaWtlIHlvdXIgY2hvaWNlIG9mIGJhc2U2NHVybCBhcyBhIHdheSB0byBhcm1v dXIgYmluYXJ5IGRhdGEgYW5kIGF2b2lkIGVzY2FwaW5nIGlzc3Vlcy4NCg0KSXQgbWlnaHQgYmUg bmljZXIgdG8gc2lnbiB0aGUgYnl0ZXMgdGhhdCBnZXQgYXJtb3VyZWQsIGluc3RlYWQgb2YgdGhl IEFTQ0lJIG91dHB1dCBvZiB0aGUgYXJtb3VyaW5nLg0KSSBkb24ndCB0aGluayB0aGlzIGNvbXBy b21pc2VzIHRoZSByb2J1c3RuZXNzIGFpbSBvZiBNYWdpYyBTaWduYXR1cmVzLg0KSXQgd291bGQg bWVhbiB5b3Ugc2lnbiB0aGUgYmluYXJ5IG1lc3NhZ2UsIHRoZW4gdXNlIGJhc2U2NHVybCBhcm1v dXJpbmcgdG8gZW5zdXJlIHRoZSBleGFjdCBieXRlcyBzaWduZWQgbWFrZSBpdCB1bmFsdGVyZWQg dG8gdGhlIG90aGVyIGVuZC4gVGhlIGFybW91cmluZyBhcHBsaWVzIGVxdWFsbHkgdG8gdGhlIGRh dGEgYW5kIHNpZ25hdHVyZSwgYnV0IGlzbid0IGFjdHVhbGx5IGludm9sdmVkIGluIHRoZSBjcnlw dG8uDQoNCkFuIGV4dHJhIGxpdHRsZSBhZHZhbnRhZ2UgaXMgdGhhdCB0aGUgY29kZSB0byByZW1v dmUgdGhlIGFybW91ciBbZWcgYnl0ZVtdIGRlYXJtb3VyKFN0cmluZyldIGNhbiBhbHNvIHNraXAg d2hpdGVzcGFjZS4gV2l0aCB0aGUgY3VycmVudCBhcnJhbmdlbWVudCwgYSBzZXBhcmF0ZSBzdGVw IHRvIHJlbW92ZSB0aGUgd2hpdGVzcGFjZSBpcyByZXF1aXJlZCBhcyB5b3UgbmVlZCB0aGUgYmFz ZTY0dXJsIGVuY29kaW5nIHdpdGhvdXQgd2hpdGVzcGFjZSB0byB2ZXJpZnkgdGhlIHNpZ25hdHVy ZS4NCg0KVGhlIGV4YW1wbGUgdXNlZCB0aHJvdWdob3V0IHRoZSBzcGVjIGlzIHdyb25nLiBJdCBs b29rcyBsaWtlIHR3byAiLSIgY2hhcmFjdGVycyBoYXZlIGJlZW4gYWNjaWRlbnRhbGx5IGRyb3Bw ZWQgKHdoaWNoIGlzIG5vdCBhIGdvb2QgYWR2ZXJ0aXNlbWVudCBmb3IgdGhlIHJvYnVzdG5lc3Mg dGhhdCBiYXNlNjR1cmwgb2ZmZXJzISkNCjR0aCBsaW5lOiAgY2hhbmdlICJiV1VQSFZ5IiB0byAi YldVLVBIVnkiIChkZWNvZGVzIHRvICJtZT48dXIiKQ0KMTB0aCBsaW5lOiBjaGFuZ2UgIiBiR1VV MkZzIiB0byAiYkdVLVUyRnMiIChkZWNvZGVzIHRvICJsZT5TYWwiKQ0KDQpDdXJpb3VzbHksIHRo ZXJlIGFyZSBubyAiXyIgY2hhcmFjdGVycyBpbiB0aGUgZXhhbXBsZXMgKGRhdGEgb3Igc2lnKS4g Q2hhbmdpbmcgdGhlIDx0aXRsZT4gdG8gZW5kIHdpdGggYSAiPyIsIGluc3RlYWQgb2YgYSAiISIs IHdvdWxkIGludHJvZHVjZSBvbmUuIEJhc2U2NHVybCBpcyB1bmNvbW1vbiBzbyBleGFtcGxlcyB1 c2luZyBpdHMgZGlmZmVyZW5jZXMgZnJvbSBub3JtYWwgYmFzZTY0IG1pZ2h0IGhlbHAgY2F0Y2gg YSBmZXcgaW1wbGVtZW50YXRpb24gYnVncy4NClthY3R1YWxseSBJIGp1c3Qgbm90aWNlZCBhICJf IiBpbiB0aGUgZXhhbXBsZSBtb2R1bHVzLCBidXQgb25lIGluIHRoZSBleGFtcGxlIGRhdGEgd291 bGQgYmUgZXZlbiBiZXR0ZXJdDQoNClRoZSBzaWduYXR1cmUgaXMgd3JvbmcsIGJ1dCBub3QgcmFu ZG9tIHNvIGl0IGlzIG1pc2xlYWRpbmcuDQpEZWNyeXB0aW5nIHRoZSBleGFtcGxlIHNpZ25hdHVy ZSB3aXRoIHRoZSBleGFtcGxlIGtleSBwcm9kdWNlcyBhIDIwLWJ5dGUgdmFsdWUgLS0gd2hpY2gg aGFwcGVucyB0byB0aGUgYmUgU0hBLTEgaGFzaCBvZiB0aGUgZW1wdHkgc3RyaW5nIChJIGRvbid0 IHJlY29nbml6ZSBtYW55IGhhc2ggdmFsdWVzIG9uIHNpZ2h0LCBidXQgdGhpcyBpcyBvbmUgb2Yg dGhlbSEpLg0KSXQgc2hvdWxkIGJlIHRoZSBoYXNoIG9mIHRoZSAoYXJtb3VyZWQpIGRhdGEuDQpJ dCBzaG91bGQgYmUgYSBTSEEtMjU2IGhhc2gsIG5vdCBTSEEtMSBhcyBwZXIgPG1lOmFsZz5SU0Et U0hBMjU2PC9tZTphbGc+Lg0KSXQgc2hvdWxkIGJlIHdyYXBwZWQgaW4gYSBERVItZW5jb2RlZCBE aWdlc3RJbmZvIHN0cnVjdHVyZSAoYmFzaWNhbGx5IGluY2x1ZGVzIGFuIGlkIGZvciBTSEEtMjU2 KS4NCkl0IHNob3VsZCBoYXZlIHRoZSBQS0NTIzEgdjEuNSAiYmxvY2sgdHlwZSAxIiBwcmVmaXgg KDAxIEZGIEZG4oCmIDAwIDxEaWdlc3RJbmZvPiksIG1ha2luZyB0aGUgdmFsdWUgYSBzaW1pbGFy IHNpemUgdG8gdGhlIG1vZHVsdXMuDQoNClNvcnJ5IGZvciBiZWluZyBwaWNreSA7KQ0KDQotLSAN CkphbWVzIE1hbmdlcg0K From eran@hueniverse.com Wed Feb 10 23:12: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 7F0C43A7166 for ; Wed, 10 Feb 2010 23:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 4gkHdFeZUv4o for ; Wed, 10 Feb 2010 23:12: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 F10DD3A681D for ; Wed, 10 Feb 2010 23:12:08 -0800 (PST) Received: (qmail 17299 invoked from network); 11 Feb 2010 07:13:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Feb 2010 07:13:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 11 Feb 2010 00:12:55 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "OAuth WG (oauth@ietf.org)" , John Panzer Date: Thu, 11 Feb 2010 00:13:09 -0700 Thread-Topic: FW: Salmon signatures proposal - base64url Thread-Index: AcqpowibG7Ye33yNShm3FBvjTpt2ZQBPSNdgAAJX+/A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438648F8803@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112506F4872@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112506F4872@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal - base64url X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Feb 2010 07:12:10 -0000 RmVlZGJhY2sgc3BlY2lmaWMgdG8gdGhlIFNhbG1vbiBwcm9wb3NhbCBzaG91bGQgZ28gdG8gdGhl IFNhbG1vbiBsaXN0IFsxXS4NCg0KRUhMDQoNClsxXSBodHRwOi8vZ3JvdXBzLmdvb2dsZS5jb20v Z3JvdXAvc2FsbW9uLXByb3RvY29sL3N1YnNjcmliZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgTWFuZ2VyLCBKYW1lcyBIDQo+IFNlbnQ6IFdl ZG5lc2RheSwgRmVicnVhcnkgMTAsIDIwMTAgMTA6NTkgUE0NCj4gVG86IE9BdXRoIFdHIChvYXV0 aEBpZXRmLm9yZyk7IEpvaG4gUGFuemVyDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEZXOiBT YWxtb24gc2lnbmF0dXJlcyBwcm9wb3NhbCAtIGJhc2U2NHVybA0KPiANCj4gSm9obiwNCj4gDQo+ IEkgbGlrZSB5b3VyIGNob2ljZSBvZiBiYXNlNjR1cmwgYXMgYSB3YXkgdG8gYXJtb3VyIGJpbmFy eSBkYXRhIGFuZCBhdm9pZA0KPiBlc2NhcGluZyBpc3N1ZXMuDQo+IA0KPiBJdCBtaWdodCBiZSBu aWNlciB0byBzaWduIHRoZSBieXRlcyB0aGF0IGdldCBhcm1vdXJlZCwgaW5zdGVhZCBvZiB0aGUg QVNDSUkNCj4gb3V0cHV0IG9mIHRoZSBhcm1vdXJpbmcuDQo+IEkgZG9uJ3QgdGhpbmsgdGhpcyBj b21wcm9taXNlcyB0aGUgcm9idXN0bmVzcyBhaW0gb2YgTWFnaWMgU2lnbmF0dXJlcy4NCj4gSXQg d291bGQgbWVhbiB5b3Ugc2lnbiB0aGUgYmluYXJ5IG1lc3NhZ2UsIHRoZW4gdXNlIGJhc2U2NHVy bCBhcm1vdXJpbmcgdG8NCj4gZW5zdXJlIHRoZSBleGFjdCBieXRlcyBzaWduZWQgbWFrZSBpdCB1 bmFsdGVyZWQgdG8gdGhlIG90aGVyIGVuZC4gVGhlDQo+IGFybW91cmluZyBhcHBsaWVzIGVxdWFs bHkgdG8gdGhlIGRhdGEgYW5kIHNpZ25hdHVyZSwgYnV0IGlzbid0IGFjdHVhbGx5DQo+IGludm9s dmVkIGluIHRoZSBjcnlwdG8uDQo+IA0KPiBBbiBleHRyYSBsaXR0bGUgYWR2YW50YWdlIGlzIHRo YXQgdGhlIGNvZGUgdG8gcmVtb3ZlIHRoZSBhcm1vdXIgW2VnIGJ5dGVbXQ0KPiBkZWFybW91cihT dHJpbmcpXSBjYW4gYWxzbyBza2lwIHdoaXRlc3BhY2UuIFdpdGggdGhlIGN1cnJlbnQgYXJyYW5n ZW1lbnQsIGENCj4gc2VwYXJhdGUgc3RlcCB0byByZW1vdmUgdGhlIHdoaXRlc3BhY2UgaXMgcmVx dWlyZWQgYXMgeW91IG5lZWQgdGhlDQo+IGJhc2U2NHVybCBlbmNvZGluZyB3aXRob3V0IHdoaXRl c3BhY2UgdG8gdmVyaWZ5IHRoZSBzaWduYXR1cmUuDQo+IA0KPiBUaGUgZXhhbXBsZSB1c2VkIHRo cm91Z2hvdXQgdGhlIHNwZWMgaXMgd3JvbmcuIEl0IGxvb2tzIGxpa2UgdHdvICItIg0KPiBjaGFy YWN0ZXJzIGhhdmUgYmVlbiBhY2NpZGVudGFsbHkgZHJvcHBlZCAod2hpY2ggaXMgbm90IGEgZ29v ZA0KPiBhZHZlcnRpc2VtZW50IGZvciB0aGUgcm9idXN0bmVzcyB0aGF0IGJhc2U2NHVybCBvZmZl cnMhKSA0dGggbGluZTogIGNoYW5nZQ0KPiAiYldVUEhWeSIgdG8gImJXVS1QSFZ5IiAoZGVjb2Rl cyB0byAibWU+PHVyIikgMTB0aCBsaW5lOiBjaGFuZ2UgIg0KPiBiR1VVMkZzIiB0byAiYkdVLVUy RnMiIChkZWNvZGVzIHRvICJsZT5TYWwiKQ0KPiANCj4gQ3VyaW91c2x5LCB0aGVyZSBhcmUgbm8g Il8iIGNoYXJhY3RlcnMgaW4gdGhlIGV4YW1wbGVzIChkYXRhIG9yIHNpZykuIENoYW5naW5nDQo+ IHRoZSA8dGl0bGU+IHRvIGVuZCB3aXRoIGEgIj8iLCBpbnN0ZWFkIG9mIGEgIiEiLCB3b3VsZCBp bnRyb2R1Y2Ugb25lLiBCYXNlNjR1cmwNCj4gaXMgdW5jb21tb24gc28gZXhhbXBsZXMgdXNpbmcg aXRzIGRpZmZlcmVuY2VzIGZyb20gbm9ybWFsIGJhc2U2NCBtaWdodA0KPiBoZWxwIGNhdGNoIGEg ZmV3IGltcGxlbWVudGF0aW9uIGJ1Z3MuDQo+IFthY3R1YWxseSBJIGp1c3Qgbm90aWNlZCBhICJf IiBpbiB0aGUgZXhhbXBsZSBtb2R1bHVzLCBidXQgb25lIGluIHRoZSBleGFtcGxlDQo+IGRhdGEg d291bGQgYmUgZXZlbiBiZXR0ZXJdDQo+IA0KPiBUaGUgc2lnbmF0dXJlIGlzIHdyb25nLCBidXQg bm90IHJhbmRvbSBzbyBpdCBpcyBtaXNsZWFkaW5nLg0KPiBEZWNyeXB0aW5nIHRoZSBleGFtcGxl IHNpZ25hdHVyZSB3aXRoIHRoZSBleGFtcGxlIGtleSBwcm9kdWNlcyBhIDIwLWJ5dGUNCj4gdmFs dWUgLS0gd2hpY2ggaGFwcGVucyB0byB0aGUgYmUgU0hBLTEgaGFzaCBvZiB0aGUgZW1wdHkgc3Ry aW5nIChJIGRvbid0DQo+IHJlY29nbml6ZSBtYW55IGhhc2ggdmFsdWVzIG9uIHNpZ2h0LCBidXQg dGhpcyBpcyBvbmUgb2YgdGhlbSEpLg0KPiBJdCBzaG91bGQgYmUgdGhlIGhhc2ggb2YgdGhlIChh cm1vdXJlZCkgZGF0YS4NCj4gSXQgc2hvdWxkIGJlIGEgU0hBLTI1NiBoYXNoLCBub3QgU0hBLTEg YXMgcGVyIDxtZTphbGc+UlNBLQ0KPiBTSEEyNTY8L21lOmFsZz4uDQo+IEl0IHNob3VsZCBiZSB3 cmFwcGVkIGluIGEgREVSLWVuY29kZWQgRGlnZXN0SW5mbyBzdHJ1Y3R1cmUgKGJhc2ljYWxseQ0K PiBpbmNsdWRlcyBhbiBpZCBmb3IgU0hBLTI1NikuDQo+IEl0IHNob3VsZCBoYXZlIHRoZSBQS0NT IzEgdjEuNSAiYmxvY2sgdHlwZSAxIiBwcmVmaXggKDAxIEZGIEZG4oCmIDAwDQo+IDxEaWdlc3RJ bmZvPiksIG1ha2luZyB0aGUgdmFsdWUgYSBzaW1pbGFyIHNpemUgdG8gdGhlIG1vZHVsdXMuDQo+ IA0KPiBTb3JyeSBmb3IgYmVpbmcgcGlja3kgOykNCj4gDQo+IC0tDQo+IEphbWVzIE1hbmdlcg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0 aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0K From jpanzer@google.com Wed Feb 10 23:14: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 16E403A681D for ; Wed, 10 Feb 2010 23:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.543 X-Spam-Level: X-Spam-Status: No, score=-104.543 tagged_above=-999 required=5 tests=[AWL=1.434, 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 wnU0iFISsn97 for ; Wed, 10 Feb 2010 23:14:47 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E18B93A7652 for ; Wed, 10 Feb 2010 23:14:45 -0800 (PST) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o1B7FvrI011668 for ; Wed, 10 Feb 2010 23:15:57 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265872557; bh=oqx2Vnd8+12W42qKyoPjKKPsV+E=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=BTLCs/l1NbbQY/pyL/pjKhMgV35qsg8A+KKbqgjNDmrUh6EnBPhIPDZeMGmrEpTrv +hGlvCktnRmXzWOHpEPzw== 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=e4bwYxP1MmZwk4lDF+p/aRmt3WJnur9ka8MSBW4Xxja2krmYBX6Vu/udcCIu3piVD QY9VchcI1GJWwbzQ3J+Dg== Received: from ywh1 (ywh1.prod.google.com [10.192.8.1]) by kpbe16.cbf.corp.google.com with ESMTP id o1B7FtUm012717 for ; Wed, 10 Feb 2010 23:15:56 -0800 Received: by ywh1 with SMTP id 1so1724005ywh.18 for ; Wed, 10 Feb 2010 23:15:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.128.6 with SMTP id a6mr3969933ybd.281.1265872555347; Wed, 10 Feb 2010 23:15:55 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112506F4872@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112506F4872@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 10 Feb 2010 23:15:55 -0800 Message-ID: From: John Panzer To: "Manger, James H" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal - base64url X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Feb 2010 07:14:49 -0000 Thanks! On Wednesday, February 10, 2010, Manger, James H wrote: > John, > > I like your choice of base64url as a way to armour binary data and avoid = escaping issues. > > It might be nicer to sign the bytes that get armoured, instead of the ASC= II output of the armouring. > I don't think this compromises the robustness aim of Magic Signatures. > It would mean you sign the binary message, then use base64url armouring t= o ensure the exact bytes signed make it unaltered to the other end. The arm= ouring applies equally to the data and signature, but isn't actually involv= ed in the crypto. > > An extra little advantage is that the code to remove the armour [eg byte[= ] dearmour(String)] can also skip whitespace. With the current arrangement,= a separate step to remove the whitespace is required as you need the base6= 4url encoding without whitespace to verify the signature. > > The example used throughout the spec is wrong. It looks like two "-" char= acters have been accidentally dropped (which is not a good advertisement fo= r the robustness that base64url offers!) > 4th line: =A0change "bWUPHVy" to "bWU-PHVy" (decodes to "me> 10th line: change " bGUU2Fs" to "bGU-U2Fs" (decodes to "le>Sal") > > Curiously, there are no "_" characters in the examples (data or sig). Cha= nging the to end with a "?", instead of a "!", would introduce one.= Base64url is uncommon so examples using its differences from normal base64= might help catch a few implementation bugs. > [actually I just noticed a "_" in the example modulus, but one in the exa= mple data would be even better] > > The signature is wrong, but not random so it is misleading. > Decrypting the example signature with the example key produces a 20-byte = value -- which happens to the be SHA-1 hash of the empty string (I don't re= cognize many hash values on sight, but this is one of them!). > It should be the hash of the (armoured) data. > It should be a SHA-256 hash, not SHA-1 as per <me:alg>RSA-SHA256</me:alg>= . > It should be wrapped in a DER-encoded DigestInfo structure (basically inc= ludes an id for SHA-256). > It should have the PKCS#1 v1.5 "block type 1" prefix (01 FF FF=85 00 <Dig= estInfo>), making the value a similar size to the modulus. > > Sorry for being picky ;) > > -- > James Manger > --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From jpanzer@google.com Thu Feb 11 15:56:02 2010 Return-Path: <jpanzer@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4913A6E05 for <oauth@core3.amsl.com>; Thu, 11 Feb 2010 15:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.901 X-Spam-Level: X-Spam-Status: No, score=-104.901 tagged_above=-999 required=5 tests=[AWL=1.075, 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 MiTtm9apGJB6 for <oauth@core3.amsl.com>; Thu, 11 Feb 2010 15:56:01 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 5179F3A7289 for <oauth@ietf.org>; Thu, 11 Feb 2010 15:56:00 -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 o1BNvEls031614 for <oauth@ietf.org>; Thu, 11 Feb 2010 23:57:14 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265932635; bh=IDQUj9gcF35354EZtOt3oofh+bQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=BF7ZyKWRXI7z72RrjOeykmlTLf2sLyjlLmhwiyeph9LcnPA2/8C0EPx0C6xbB8tW9 PMJLtFGelvl2c44escgYg== 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=V86o0hEt0OCjfWhWe/pf8IrPrMFQgXaEn8a/6zKjfxQsmRlWb1UULqCmXB1NFPT3s NZp4xbDMirIpH1LNRmS7w== Received: from yxe38 (yxe38.prod.google.com [10.190.2.38]) by spaceape24.eur.corp.google.com with ESMTP id o1BNvCLB025325 for <oauth@ietf.org>; Thu, 11 Feb 2010 15:57:13 -0800 Received: by yxe38 with SMTP id 38so1604304yxe.4 for <oauth@ietf.org>; Thu, 11 Feb 2010 15:57:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.74.11 with SMTP id w11mr1371956yba.33.1265932630645; Thu, 11 Feb 2010 15:57:10 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112506F4872@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723437DFDDE1D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112506F4872@WSMSG3153V.srv.dir.telstra.com> From: John Panzer <jpanzer@google.com> Date: Thu, 11 Feb 2010 15:56:50 -0800 Message-ID: <cb5f7a381002111556p57970cf7wbb76c0514016d5c9@mail.gmail.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: multipart/alternative; boundary=00151747949ac25c3b047f5be8d1 X-System-Of-Record: true X-Mailman-Approved-At: Thu, 11 Feb 2010 15:58:07 -0800 Cc: "salmon-protocol@googlegroup.com" <salmon-protocol@googlegroups.com> Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal - base64url X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2010 23:56:02 -0000 --00151747949ac25c3b047f5be8d1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable James, Thanks for the feedback. +salmon-protocol@googlegroups.com bcc:oauth@ietf.org <bcc%3Aoauth@ietf.org> -- John Panzer / Google jpanzer@google.com / abstractioneer.org <http://www.abstractioneer.org/> / @jpanzer On Wed, Feb 10, 2010 at 10:59 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > John, > > I like your choice of base64url as a way to armour binary data and avoid > escaping issues. > > It might be nicer to sign the bytes that get armoured, instead of the ASC= II > output of the armouring. > I don't think this compromises the robustness aim of Magic Signatures. > It would mean you sign the binary message, then use base64url armouring t= o > ensure the exact bytes signed make it unaltered to the other end. The > armouring applies equally to the data and signature, but isn't actually > involved in the crypto. > > An extra little advantage is that the code to remove the armour [eg byte[= ] > dearmour(String)] can also skip whitespace. With the current arrangement,= a > separate step to remove the whitespace is required as you need the base64= url > encoding without whitespace to verify the signature. > > The example used throughout the spec is wrong. It looks like two "-" > characters have been accidentally dropped (which is not a good advertisem= ent > for the robustness that base64url offers!) > 4th line: change "bWUPHVy" to "bWU-PHVy" (decodes to "me><ur") > 10th line: change " bGUU2Fs" to "bGU-U2Fs" (decodes to "le>Sal") > > Curiously, there are no "_" characters in the examples (data or sig). > Changing the <title> to end with a "?", instead of a "!", would introduce > one. Base64url is uncommon so examples using its differences from normal > base64 might help catch a few implementation bugs. > [actually I just noticed a "_" in the example modulus, but one in the > example data would be even better] > > The signature is wrong, but not random so it is misleading. > Decrypting the example signature with the example key produces a 20-byte > value -- which happens to the be SHA-1 hash of the empty string (I don't > recognize many hash values on sight, but this is one of them!). > It should be the hash of the (armoured) data. > It should be a SHA-256 hash, not SHA-1 as per <me:alg>RSA-SHA256</me:alg>= . > It should be wrapped in a DER-encoded DigestInfo structure (basically > includes an id for SHA-256). > It should have the PKCS#1 v1.5 "block type 1" prefix (01 FF FF=85 00 > <DigestInfo>), making the value a similar size to the modulus. > > Sorry for being picky ;) > > -- > James Manger > --00151747949ac25c3b047f5be8d1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <div>James,</div><div><br></div><div>Thanks for the feedback.</div><div><br= ></div>+<a href=3D"mailto:salmon-protocol@googlegroups.com">salmon-protocol= @googlegroups.com</a><div><a href=3D"mailto:bcc%3Aoauth@ietf.org">bcc:oauth= @ietf.org</a></div> <div><br clear=3D"all"><div dir=3D"ltr">--<br>John Panzer / Google<br><a hr= ef=3D"mailto:jpanzer@google.com" target=3D"_blank">jpanzer@google.com</a> /= <a href=3D"http://www.abstractioneer.org/" target=3D"_blank">abstractionee= r.org</a> / @jpanzer</div> <br> <br><br><div class=3D"gmail_quote">On Wed, Feb 10, 2010 at 10:59 PM, Manger= , James H <span dir=3D"ltr"><<a href=3D"mailto:James.H.Manger@team.telst= ra.com">James.H.Manger@team.telstra.com</a>></span> wrote:<br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex;"> John,<br> <br> I like your choice of base64url as a way to armour binary data and avoid es= caping issues.<br> <br> It might be nicer to sign the bytes that get armoured, instead of the ASCII= output of the armouring.<br> I don't think this compromises the robustness aim of Magic Signatures.<= br> It would mean you sign the binary message, then use base64url armouring to = ensure the exact bytes signed make it unaltered to the other end. The armou= ring applies equally to the data and signature, but isn't actually invo= lved in the crypto.<br> <br> An extra little advantage is that the code to remove the armour [eg byte[] = dearmour(String)] can also skip whitespace. With the current arrangement, a= separate step to remove the whitespace is required as you need the base64u= rl encoding without whitespace to verify the signature.<br> <br> The example used throughout the spec is wrong. It looks like two "-&qu= ot; characters have been accidentally dropped (which is not a good advertis= ement for the robustness that base64url offers!)<br> 4th line: =A0change "bWUPHVy" to "bWU-PHVy" (decodes to= "me><ur")<br> 10th line: change " bGUU2Fs" to "bGU-U2Fs" (decodes to = "le>Sal")<br> <br> Curiously, there are no "_" characters in the examples (data or s= ig). Changing the <title> to end with a "?", instead of a &= quot;!", would introduce one. Base64url is uncommon so examples using = its differences from normal base64 might help catch a few implementation bu= gs.<br> [actually I just noticed a "_" in the example modulus, but one in= the example data would be even better]<br> <br> The signature is wrong, but not random so it is misleading.<br> Decrypting the example signature with the example key produces a 20-byte va= lue -- which happens to the be SHA-1 hash of the empty string (I don't = recognize many hash values on sight, but this is one of them!).<br> It should be the hash of the (armoured) data.<br> It should be a SHA-256 hash, not SHA-1 as per <me:alg>RSA-SHA256</= me:alg>.<br> It should be wrapped in a DER-encoded DigestInfo structure (basically inclu= des an id for SHA-256).<br> It should have the PKCS#1 v1.5 "block type 1" prefix (01 FF FF=85= 00 <DigestInfo>), making the value a similar size to the modulus.<br= > <br> Sorry for being picky ;)<br> <br> --<br> <font color=3D"#888888">James Manger<br> </font></blockquote></div><br></div> --00151747949ac25c3b047f5be8d1-- From torsten@lodderstedt.net Sat Feb 13 14:40:58 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31453A7907 for <oauth@core3.amsl.com>; Sat, 13 Feb 2010 14:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SNU2zUGo9YF for <oauth@core3.amsl.com>; Sat, 13 Feb 2010 14:40:57 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by core3.amsl.com (Postfix) with ESMTP id 79C443A773D for <oauth@ietf.org>; Sat, 13 Feb 2010 14:40:56 -0800 (PST) Received: from p4fff0225.dip.t-dialin.net ([79.255.2.37] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1NgQgt-0006Od-U6 for oauth@ietf.org; Sat, 13 Feb 2010 23:42:19 +0100 Message-ID: <4B772AC7.1090907@lodderstedt.net> Date: Sat, 13 Feb 2010 23:42:15 +0100 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: 141509 Subject: [OAUTH-WG] Feedback on draft-hammer-http-token-auth-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 13 Feb 2010 22:40:58 -0000 Hi, I have been involved in establishing token-based security in a large-scale environment with central identity management services and various web services relying on tokens for user authentication and authorization. We also tried to adopt OAuth 1.0a. Based on my experiences, I want to give you some feedback to draft-hammer-http-token-auth-01 and ask some questions. * Generally, I highly welcome the idea to strictly distinguish token issuance and token usage. The design decision not to use any consumer-related data (key, secret) in the "Token" scheme is a logical consequence. Our attempt to adopt OAuth 1.0a was hindered by the fact that the signature calculation required the consumer secret. But in environements with central identity management, neiter user nor consumer credentials shall be known to the services. So the new proposal is a step in the right direction to support such deployments. * §5.1 "The token identifier can be an opaque string or use a well-defined internal structure." Does the proposal really intend to pass token identifiers (== handles?) only? I would expect the option to pass complete tokens in the authorization header from client to server. In that way, no further communication is required between server and security systems. * How do you envision token service discovery? IMHO, a client performing an unauthorized resource request should be given a link to the token service a server trusts along with the 401 response. Or shall YADIS/XRDS be employed for that purpose and how? * From my point of view, deployments with different token types (SAML, Kerberos, SWT, ...) would benefit if the protocol explicitely supports token format descriptions. In the WWW-Authenticate-Header the server could publish the formats it supports. e.g. HTTP/1.1 401 Unauthorized WWW-Authenticate: Token realm="http://example.com/", format="saml20-base64 krb5-base64 swt" coverage="base base+body-sha-256", timestamp="137131190" The client does not need (and shouldn't be) aware of the meaning of the different formats but it could pass this information with the requests to the service issuing the required token. The token service in turn would denote the token format as part of the response parameter. The client would (again uninterpreted) pass this information with the authorized resource requests and therewith gives the receiver a hint how to handle the token. GET /resource/1 HTTP/1.1 Host: example.com Authorization: Token token="h480djs93hd8", format="swt" coverage="base", timestamp="137131200", nonce="dj83hs9s", auth="djosJKDKJSD8743243/jdk33klY=" * The protocol supports authentication of message originator, replay detection, and message integrity protection as an alternative to transport-layer security. But, why don't you include message encryption? In this way, one could abandon on HTTPS even if data privacy or confidentiality is an issue. The token secret could be employed for that purpose. A good blueprint could be Kerberos-based message-layer security. regards, Torsten. From James.H.Manger@team.telstra.com Tue Feb 16 06:36:37 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BEAE3A7AF9 for <oauth@core3.amsl.com>; Tue, 16 Feb 2010 06:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 DiDwNvDQNBLQ for <oauth@core3.amsl.com>; Tue, 16 Feb 2010 06:36:35 -0800 (PST) Received: from mailipao.ntcif.telstra.com.au (mailipao.ntcif.telstra.com.au [202.12.233.27]) by core3.amsl.com (Postfix) with ESMTP id C06BD3A77E7 for <oauth@ietf.org>; Tue, 16 Feb 2010 06:36:34 -0800 (PST) Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipai.ntcif.telstra.com.au with ESMTP; 17 Feb 2010 01:38:07 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 006FDFF81 for <oauth@ietf.org>; Wed, 17 Feb 2010 01:38:06 +1100 (EST) Received: from wsmsg3706.srv.dir.telstra.com (wsmsg3706.srv.dir.telstra.com [172.49.40.80]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 3FA1841D65 for <oauth@ietf.org>; Wed, 17 Feb 2010 01:37:36 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Wed, 17 Feb 2010 00:38:06 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Wed, 17 Feb 2010 00:38:04 +1000 Thread-Topic: ID, MAC and SIG HTTP schemes - starting point for "use a token" Thread-Index: AcqvFaXASwjv6gNZR/WqH1RJYGzLUw== Message-ID: <255B9BB34FB7D647A506DC292726F6E1125089AE62@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/mixed; boundary="_004_255B9BB34FB7D647A506DC292726F6E1125089AE62WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] ID, MAC and SIG HTTP schemes - starting point for "use a token" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 16 Feb 2010 14:36:37 -0000 --_004_255B9BB34FB7D647A506DC292726F6E1125089AE62WSMSG3153Vsrv_ Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1125089AE62WSMSG3153Vsrv_" --_000_255B9BB34FB7D647A506DC292726F6E1125089AE62WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXR0YWNoZWQgaXMgbXkgc3VnZ2VzdGVkIHN0YXJ0aW5nIHBvaW50IGZvciB0aGUg4oCcaG93IHRv IHVzZSBhIHRva2Vu4oCdIHBhcnQgb2YgT0F1dGguDQoNCg0KDQpJdCBkZWZpbmVzIDMgc2NoZW1l czoNCg0KDQoNCkF1dGhvcml6YXRpb246IElEIGE94oCd4oCm4oCdICAgIChvciBpbiBVUkkgb3Ig UE9TVCkNCg0KKiBxdWl0ZSBsaWtlIFdSQVAsIGJ1dCB3aXRoIHNob3J0ZXIgbGFiZWxzLCBhIHNt aWRnZW4gb2Yg4oCcZGlzY292ZXJ54oCdLCBhbmQgbm8gZXhwbGljaXQgdGllIHRvIE9BdXRoIGRl bGVnYXRpb24NCg0KDQoNCkF1dGhvcml6YXRpb246IE1BQyBtPeKAnWhtYWMtc2hhLTI1NuKAnSB1 PeKAnXVzZXItaWTigJ0gYT3igJ1hdXRoei1pbmZv4oCdIOKApiBzPeKAnWhnYXNkYWc3NnNhN2Fz 4oCdDQoNCiogYSBNQUMgb3ZlciBzZWxlY3RlZCBwYXJ0cyBvZiBhbiBIVFRQIHJlcXVlc3QsIHdp dGggYSBiaXQgb2YgbmVnb3RpYXRpb24sIGFuZCBubyBleHBsaWNpdCB0aWUgdG8gT0F1dGggZGVs ZWdhdGlvbg0KDQoNCg0KQXV0aG9yaXphdGlvbjogU0lHIG094oCdcnNh4oCm4oCdIOKApiBzPeKA nWhnYXNqR0hmSEdGaGdGSEdmSEdGR0ZnaGZIZGFnNzZzYTdhc+KAnQ0KDQoqIGEgZGlnaXRhbCBz aWduYXR1cmUgb3ZlciBzZWxlY3RlZCBwYXJ0cyBvZiBhbiBIVFRQIHJlcXVlc3QsIGxpa2UgTUFD IGJ1dCB3aXRoIHB1YmxpYy1rZXkgY3J5cHRvDQoNCg0KDQpQLlMuIEl0IGlzIGZvcm1hdHRlZCBh cyBhbiAoaW5jb21wbGV0ZSkgaW50ZXJuZXQtZHJhZnQgc2luY2UgdGhhdCBpcyB3aGF0IGl0IG5l ZWRzIHRvIGhlYWQgdG8sIGJ1dCBpdCBoYXMgbm90IGJlIHN1Ym1pdHRlZCB0byB0aGUgSUVURiBk cmFmdCBzeXN0ZW0uDQoNCg0KDQoNCg0KDQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQoNCg0KDQoN Cj4gLS0tLS0tLS0tLQ0KDQo+IEZyb206IEVyYW4gSGFtbWVyLUxhaGF2DQoNCj4gU2VudDogRnJp ZGF5LCA1IEZlYnJ1YXJ5IDIwMTAgNjoyOSBQTQ0KDQo+IFRvOiBPQXV0aCBXRyAob2F1dGhAaWV0 Zi5vcmcpDQoNCj4gU3ViamVjdDogW09BVVRILVdHXSBXaGljaCBkcmFmdCB0byB1c2UgYXMgYSBz dGFydGluZyBwb2ludCBmb3IgJ3VzaW5nIGEgdG9rZW4nPw0KDQo+DQoNCj4g4oCmDQoNCj4gV2Ug aGF2ZSB0aHJlZSBvcHRpb25zIGZvciBtb3ZpbmcgZm9yd2FyZCB3aXRoICdob3cgdG8gdXNlIGEg dG9rZW4nLg0KDQo+IFN0YXJ0IHdpdGg6DQoNCj4NCg0KPiAxLiBkcmFmdC1pZXRmLW9hdXRoLWF1 dGhlbnRpY2F0aW9uDQoNCj4gMi4gZHJhZnQtaGFtbWVyLWh0dHAtdG9rZW4tYXV0aA0KDQo+IDMu IHNvbWV0aGluZyBlbHNlKg0KDQo+IOKApg0KDQo+IFBpY2suDQoNCg0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E1125089AE62WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6 MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsN Cglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1BVSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdHRhY2hlZCBpcyBteSBzdWdn ZXN0ZWQgc3RhcnRpbmcgcG9pbnQgZm9yIHRoZSDigJxob3cgdG8gdXNlIGEgdG9rZW7igJ0gcGFy dCBvZiBPQXV0aC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgZGVmaW5lcyAzIHNjaGVtZXM6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF1dGhvcml6YXRpb246IElEIGE94oCd4oCm4oCdICZu YnNwOyZuYnNwOyZuYnNwOyhvciBpbiBVUkkgb3IgUE9TVCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiogcXVpdGUgbGlrZSBXUkFQLCBidXQgd2l0aCBzaG9ydGVyIGxhYmVs cywgYSBzbWlkZ2VuIG9mIOKAnGRpc2NvdmVyeeKAnSwgYW5kIG5vIGV4cGxpY2l0IHRpZSB0byBP QXV0aCBkZWxlZ2F0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF1dGhvcml6YXRpb246IE1B QyBtPeKAnWhtYWMtc2hhLTI1NuKAnSB1PeKAnXVzZXItaWTigJ0gYT3igJ1hdXRoei1pbmZv4oCd IOKApiBzPeKAnWhnYXNkYWc3NnNhN2Fz4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4qIGEgTUFDIG92ZXIgc2VsZWN0ZWQgcGFydHMgb2YgYW4gSFRUUCByZXF1ZXN0LCB3 aXRoIGEgYml0IG9mIG5lZ290aWF0aW9uLCBhbmQgbm8gZXhwbGljaXQgdGllIHRvIE9BdXRoIGRl bGVnYXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXV0aG9yaXphdGlvbjogU0lHIG094oCd cnNh4oCm4oCdIOKApiBzPeKAnWhnYXNqR0hmSEdGaGdGSEdmSEdGR0ZnaGZIZGFnNzZzYTdhc+KA nTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBhIGRpZ2l0YWwgc2lnbmF0 dXJlIG92ZXIgc2VsZWN0ZWQgcGFydHMgb2YgYW4gSFRUUCByZXF1ZXN0LCBsaWtlIE1BQyBidXQg d2l0aCBwdWJsaWMta2V5IGNyeXB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QLlMuIEl0IGlz IGZvcm1hdHRlZCBhcyBhbiAoaW5jb21wbGV0ZSkgaW50ZXJuZXQtZHJhZnQgc2luY2UgdGhhdCBp cyB3aGF0IGl0IG5lZWRzIHRvIGhlYWQgdG8sIGJ1dCBpdCBoYXMgbm90IGJlIHN1Ym1pdHRlZCB0 byB0aGUgSUVURiBkcmFmdCBzeXN0ZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPHNwYW4gbGFuZz0iRU4tVVMi Pi0tLS0tLS0tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IDxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOiBFcmFuIEhhbW1lci1MYWhhdjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPHNwYW4gbGFuZz0i RU4tVVMiPlNlbnQ6IEZyaWRheSwgNSBGZWJydWFyeSAyMDEwIDY6MjkgUE08L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxzcGFuIGxhbmc9IkVOLVVT Ij5UbzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPHNwYW4gbGFuZz0iRU4tVVMiPlN1YmplY3Q6IFtP QVVUSC1XR10gV2hpY2ggZHJhZnQgdG8gdXNlIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yICd1c2lu ZyBhPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ dG9rZW4nPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IOKApjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBXZSBoYXZlIHRocmVlIG9w dGlvbnMgZm9yIG1vdmluZyBmb3J3YXJkIHdpdGggJ2hvdyB0byB1c2UgYSB0b2tlbicuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFN0YXJ0IHdpdGg6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAxLiBkcmFmdC1pZXRmLW9hdXRoLWF1dGhlbnRp Y2F0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDIuIGRy YWZ0LWhhbW1lci1odHRwLXRva2VuLWF1dGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgMy4gc29tZXRoaW5nIGVsc2UqPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IOKApiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgUGljay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_255B9BB34FB7D647A506DC292726F6E1125089AE62WSMSG3153Vsrv_-- --_004_255B9BB34FB7D647A506DC292726F6E1125089AE62WSMSG3153Vsrv_ Content-Type: text/plain; name="draft-manger-id-mac-sig.txt" Content-Description: draft-manger-id-mac-sig.txt Content-Disposition: attachment; filename="draft-manger-id-mac-sig.txt"; size=10557; creation-date="Sat, 13 Feb 2010 21:26:45 GMT"; modification-date="Wed, 17 Feb 2010 00:23:03 GMT" Content-Transfer-Encoding: base64 TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgSmFtZXMgTWFuZ2VyDQpJbnRlcm5ldC1EcmFmdA0KSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFy ZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDEzLCAyMDEwDQpFeHBpcmVz OiBBdWd1c3QgMTcsIDIwMTANCg0KDQogICAgICAgICAgICBJRCwgTUFDIGFuZCBTSUcgYXV0aGVu dGljYXRpb24gc2NoZW1lcyBmb3IgSFRUUA0KICAgICAgICAgICAgICAgICAgICBkcmFmdC1tYW5n ZXItaWQtbWFjLXNpZw0KDQpBYnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0 aHJlZSBzY2hlbWVzIGZvciBjYXJyeWluZyBhdXRoZW50aWNhdGlvbg0KICAgYW5kL29yIGF1dGhv cml6YXRpb24gaW5mb3JtYXRpb24gaW4gSFRUUCByZXF1ZXN0cy4NCiAgIFRoZSBNQUMgc2NoZW1l IHNpZ25zIGFuIEhUVFAgcmVxdWVzdCB3aXRoIGEgc3ltbWV0cmljIHNoYXJlZCBzZWNyZXQuDQog ICBUaGUgU0lHIHNjaGVtZSBzaWducyBhbiBIVFRQIHJlcXVlc3Qgd2l0aCBhbiBhc3ltbWV0cmlj IGtleSwNCiAgIGllIHVzaW5nIHB1YmxpYyBrZXkgY3J5cHRvZ3JhcGh5Lg0KICAgVGhlIElEIHNj aGVtZSBkb2VzIG5vdCBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCwgYnV0IHRyYW5zcG9ydHMNCiAg IHNvbWUgYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbiAoZWcgYSBiZWFyZXIgdG9rZW4pLg0KDQpT dGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGlkZWFzIGZv ciB0aGUgInVzZSBhIHRva2VuIiAoYS5rLmENCiAgIGF1dGhlbnRpY2F0aW9uKSBwYXJ0IG9mIHRo ZSBJRVRGIE9BdXRoIGdyb3VwcyB3b3JrDQogICAoYXMgb3Bwb3NlZCB0byB0aGUgImdldCBhIHRv a2VuIiAoYXV0aG9yaXphdGlvbikgcGFydCB0aGF0DQogICBpcyB0aGUgZ3JvdXBzIHByaW1hcnkg cHVycG9zZSkuDQogICBJdCBpcyBmb3JtYXR0ZWQgbGlrZSBhbiBpbnRlcm5ldC1kcmFmdCwgYnV0 IGhhcyBub3QgYmVlbg0KICAgc3VibWl0dGVkIGFzIG9uZS4NCg0KDQoxLiAgSW50cm9kdWN0aW9u DQoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRocmVlIHNjaGVtZXMgZm9yIGNhcnJ5aW5n IGF1dGhlbnRpY2F0aW9uDQogICBhbmQvb3IgYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbiBpbiBI VFRQIHJlcXVlc3RzLg0KDQogICBUaGUgTUFDIHNjaGVtZSBzaWducyBhbiBIVFRQIHJlcXVlc3Qg d2l0aCBhIHN5bW1ldHJpYyBzaGFyZWQgc2VjcmV0Lg0KICAgVGhlIFNJRyBzY2hlbWUgc2lnbnMg YW4gSFRUUCByZXF1ZXN0IHdpdGggYW4gYXN5bW1ldHJpYyBrZXksDQogICBpZSB1c2luZyBwdWJs aWMga2V5IGNyeXB0b2dyYXBoeS4NCiAgIFRoZSBJRCBzY2hlbWUgZG9lcyBub3QgYXV0aGVudGlj YXRlIHRoZSBjbGllbnQsIGJ1dCBpcyBzdGlsbCB1c2VmdWwNCiAgIHdoZXJlIGJlaW5nIHRoZSBi ZWFyZXIgb2YgYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbiBpcyBzdWZmaWNpZW50Lg0KDQogICBU aGUgc2NoZW1lcyBvcGVyYXRlIGluIDEgcGFzcy4gVGhhdCBpcywgdGhleSBkbyBub3QgcmVxdWly ZSBhDQogICBjaGFsbGVuZ2UgZnJvbSB0aGUgc2VydmVyIGJlZm9yZSBhIHJlcXVlc3QgY2FuIGJl IG1hZGUuDQogICBUaGlzIGlzIGltcG9ydGFudCBmb3IgZWZmaWNpZW50IG9wZXJhdGlvbiBpbiBz b21lIHNpdHVhdGlvbnMsDQogICBidXQgaXQgZG9lcyBsaW1pdCB0aGUgc2VjdXJpdHkgcHJvcGVy dGllcyB0aGF0IHRoZSBzY2hlbWVzIGNhbiBvZmZlci4NCiAgIEZvciBpbnN0YW5jZSwgdGhlIHNj aGVtZXMgZG8gbm90IGF1dGhlbnRpY2F0ZSB0aGUgc2VydmVyIHRvIHRoZQ0KICAgY2xpZW50LiBJ dCBhbHNvIGxpbWl0cyB0aGUgcmVwbGF5IHByb3RlY3Rpb24gdGhhdCBpcyBsaWtlbHkgdG8gYmUN CiAgIHByb3ZpZGVkIGJ5IG1hbnkgc2VydmVycy4gDQoNCg0KMi4gIElEIHNjaGVtZQ0KDQogICBU aGUgSUQgc2NoZW1lIGNvbnZleXMgYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbiBmcm9tIGEgY2xp ZW50IHRvDQogICBhIHNlcnZlci4NCg0KICAgQSBzZXJ2ZXIgY2FuIGluZGljYXRlIHRoYXQgaXQg c3VwcG9ydHMgdGhlIElEIHNjaGVtZSBieSByZXR1cm5pbmcNCiAgIGEgV1dXLUF1dGhlbnRpY2F0 aW9uIHJlc3BvbnNlIGhlYWRlciwgdHlwaWNhbGx5IGluIGENCiAgICI0MDEgVW5hdXRob3JpemVk IiByZXNwb25zZSB0byBhIHJlcXVlc3QgbWlzc2luZyBhbnkgYXV0aG9yaXphdGlvbg0KICAgaW5m b3JtYXRpb24uDQogICANCiAgICAgV1dXLUF1dGhlbnRpY2F0ZTogSUQgcmVhbG09Ii4uLiIgW3E9 Ii4uLiJdIFtwPSIuLi4iXQ0KDQogICBUaGUgInJlYWxtIiBwYXJhbWV0ZXIgaXMgc3BlY2lmaWVk IGluIFJGQzI2MTcuDQoNCiAgIFRoZSAicSIgcGFyYW1ldGVyIHNwZWNpZmllcyB0aGUgbmFtZSBv ZiBhIFVSSSBxdWVyeSBwYXJhbWV0ZXIuDQogICBUaGUgcHJlc2VuY2Ugb2YgdGhlICJxIiBwYXJh bWV0ZXIgaW5kaWNhdGVzIHRoYXQgdGhlIGNsaWVudCBNQVkNCiAgIHByb3ZpZGUgdGhlIGF1dGhv cml6YXRpb24gaW5mb3JtYXRpb24gYXMgdGhlIHZhbHVlIG9mIGEgVVJJIHF1ZXJ5DQogICBwYXJh bWV0ZXIgd2l0aCB0aGUgZ2l2ZW4gbmFtZS4NCg0KICAgVGhlICJwIiBwYXJhbWV0ZXIgc3BlY2lm aWVzIHRoZSBuYW1lIG9mIGEgZm9ybSBwYXJhbWV0ZXIuDQogICBUaGUgcHJlc2VuY2Ugb2YgdGhl ICJwIiBwYXJhbWV0ZXIgaW5kaWNhdGVzIHRoYXQgdGhlIGNsaWVudCBNQVkNCiAgIHByb3ZpZGUg dGhlIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24gYXMgdGhlIHZhbHVlIG9mIGEgcGFyYW1ldGVy DQogICB3aXRoIHRoZSBnaXZlbiBuYW1lIGluIGEgYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxl bmNvZGVkDQogICByZXF1ZXN0IGJvZHkuDQoNCiAgIFRoZSBjbGllbnQgTUFZIGFsd2F5cyBzZW5k IHRoZSBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9uIGluIGFuDQogICBBdXRob3JpemF0aW9uIHJl cXVlc3QgaGVhZGVyLCByZWdhcmRsZXNzIG9mIHRoZSBwcmVzZW5jZSBvciBhYnNlbmNlDQogICBv ciB0aGUgInEiIGFuZCAicCIgcGFyYW1ldGVycyBpbiBhIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVy Lg0KICAgQ2xpZW50cyBhcmUgUkVDT01NRU5ERUQgdG8gdXNlIHRoZSBBdXRob3JpemF0aW9uIHJl cXVlc3QgaGVhZGVyDQogICB3aGVuZXZlciBwb3NzaWJsZSBzbyBhbnkgaW50ZXJtZWRpYXJ5IGNv bXBvbmVudHMgY2FuIHJlY29nbml6ZQ0KICAgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBpbmZvcm1h dGlvbiBpcyBzZWN1cml0eS1yZWxhdGVkLg0KDQogICAgIEF1dGhvcml6YXRpb246IElEIGE9Ii4u LiINCg0KICAgVGhlICJhIiBwYXJhbWV0ZXIgaG9sZHMgdGhlIGF1dGhvcml6YXRpb24gaW5mb3Jt YXRpb24uDQoNCiAgIFRoZSBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9uIFNIQUxMIG9ubHkgdXNl IHRoZSBmb2xsb3dpbmcNCiAgIDY1IGNoYXJhY3RlcnM6IEEtWiBhLXogMC05IC4gLSBfDQogICBU aGlzIGF2b2lkcyB0aGUgbmVlZCB0byBlc2NhcGUgdGhlIGF1dGhvcml6YXRpb24gaW5mb3JtYXRp b24NCiAgIHJlZ2FyZGxlc3Mgb2YgaG93IGl0IGlzIHRyYW5zcG9ydGVkLiBUaGlzIGNoYXJhY3Rl ciByZXN0cmljdGlvbg0KICAgYXBwbGllcyBldmVuIGlmIHRoZSBzZXJ2ZXIgZG9lcyBub3Qgc3Vw cG9ydCB0aGUgInAiIG9yICJxIiBvcHRpb25zLg0KDQogICBUaGUgYmFzZTY0dXJsIGVuY29kaW5n IFtSRkM0NjQ4XSBjYW4gYmUgdXNlZCB0byBjb252ZXJ0IGFyYml0cmFyeQ0KICAgYnl0ZXMgaW50 byBhIHN0cmluZyB1c2luZyBvbmx5IHRoZSBjaGFyYWN0ZXJzIGFsbG93ZWQgZm9yIHRoZQ0KICAg YXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbi4NCg0KDQozLiAgTUFDIHNjaGVtZQ0KDQogICBUaGUg TUFDIHNjaGVtZSBjYWxjdWxhdGVzIGEgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlIG92ZXIN CiAgIHNlbGVjdGVkIHBvcnRpb25zIG9mIGFuIEhUVFAgcmVxdWVzdCwgdXNpbmcgYSBzeW1tZXRy aWMgc2hhcmVkDQogICBzZWNyZXQuDQoNCjMuMS4gV1dXLUF1dGhlbnRpY2F0ZSByZXNwb25zZSBo ZWFkZXINCg0KICAgQSBzZXJ2ZXIgY2FuIGluZGljYXRlIHRoYXQgaXQgc3VwcG9ydHMgdGhlIE1B QyBzY2hlbWUgYnkgcmV0dXJuaW5nDQogICBhIFdXVy1BdXRoZW50aWNhdGlvbiByZXNwb25zZSBo ZWFkZXIsIHR5cGljYWxseSBpbiBhDQogICAiNDAxIFVuYXV0aG9yaXplZCIgcmVzcG9uc2UgdG8g YW4gdW5hdXRoZW50aWNhdGVkIHJlcXVlc3QuDQogICANCiAgICAgV1dXLUF1dGhlbnRpY2F0ZTog TUFDIHJlYWxtPSIuLi4iDQogICAgICAgbT0iYWxnIFthbGddLi4uIg0KICAgICAgIGM9InBhcnQg W3BhcnRdLi4uIg0KICAgICAgW289InBhcnQgW3BhcnRdLi4uIl0NCg0KICAgICBwYXJ0ID0gIl9i YXNlIiB8ICJfaG9zdCIgfCAiX2JvZHkiIHwgaGVhZGVyLW5hbWUgfCBoZWFkZXItcHJlZml4ICIq Ig0KDQogICBUaGUgInJlYWxtIiBwYXJhbWV0ZXIgaXMgc3BlY2lmaWVkIGluIFJGQzI2MTcuDQoN CiAgIFRoZSAibSIgcGFyYW1ldGVyIGlzIGEgc3BhY2Utc2VwYXJhdGVkIGxpc3Qgb2YgTUFDIGFs Z29yaXRobXMNCiAgIGFuZCBoYXNoIGFsZ29yaXRobXMgc3VwcG9ydGVkIGJ5IHRoZSBzZXJ2ZXIu IEhhc2ggYWxnb3JpdGhtcyBuZWVkDQogICB0byBiZSBpbmNsdWRlZCBpZiwgYW5kIG9ubHkgaWYs IHRoZSAiYyIgb3IgIm8iIHBhcmFtZXRlcnMgaW5jbHVkZQ0KICAgdGhlICJfYm9keSIgcGFydC4N Cg0KICAgVGhlICJjIiBwYXJhbWV0ZXIgaXMgYSBzcGFjZS1zZXBhcmF0ZWQgbGlzdCBvZiBwYXJ0 cyBvZiB0aGUgcmVxdWVzdA0KICAgdGhhdCBTSEFMTCBiZSBjb3ZlcmVkIGJ5IHRoZSBNQUMuDQoN CiAgIFRoZSAibyIgcGFyYW1ldGVyIGlzIGEgc3BhY2Utc2VwYXJhdGVkIGxpc3Qgb2YgcGFydHMg b2YgdGhlIHJlcXVlc3QNCiAgIHRoYXQgTUFZIGJlIGNvdmVyZWQgYnkgdGhlIE1BQywgYXQgdGhl IGNsaWVudCdzIGRpc2NyZXRpb24uDQoNCiAgIEEgY2xpZW50IFNIQUxMIGlnbm9yZSBhbnkgYWRk aXRpb25hbCB1bnJlY29nbml6ZWQgcGFyYW1ldGVycy4NCg0KMy4yLiBBdXRob3JpemF0aW9uIHJl cXVlc3QgaGVhZGVyDQoNCiAgIFRoZSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUgU0hBTEwg YmUgY29udmV5ZWQgaW4gYW4NCiAgIEF1dGhvcml6YXRpb24gaGVhZGVyLg0KDQogICAgIEF1dGhv cml6YXRpb246IE1BQw0KICAgICAgIG09Im1hY19hbGciDQogICAgICAgYz0icGFydCBbcGFydF0u Li4iDQogICAgICAgdD0ieXl5eS1tbS1kZFRoaDptbTpzc1sucy4uLl1aIg0KICAgICAgIHU9Imtl eV9pZCINCiAgICAgIFthPSJhdXRoel9pbmZvIl0NCiAgICAgIFtjYj0iY2hhbm5lbF9iaW5kaW5n Il0NCiAgICAgIFtoPSJoYXNoX2FsZyIgYj0iYm9keV9oYXNoIl0NCiAgICAgICBzPSJzaWciDQoN CiAgIFRoZSAibSIgcGFyYW1ldGVyIGlzIHRoZSBuYW1lIG9mIHRoZSBNQUMgYWxnb3JpdGhtLg0K DQogICBUaGUgImMiIHBhcmFtZXRlciBpcyBhIHNwYWNlLXNlcGFyYXRlZCBsaXN0IG9mIHRoZSBw YXJ0cyBvZiB0aGUgcmVxdWVzdA0KICAgY292ZXJlZCBieSB0aGUgTUFDLg0KDQogICBUaGUgInQi IHBhcmFtZXRlciBpcyB0aGUgdGltZSB0aGUgcmVxdWVzdCB3YXMgbWFkZS4gVGhlIHZhbHVlIFNI QUxMIGJlDQogICB1bmlxdWUgKHRvIGhpZ2ggcHJvYmFiaWxpdHkpIGZvciBhbGwgcmVxdWVzdHMg c2lnbmVkIHdpdGggYSBnaXZlbiBrZXkuDQogICBBIGNsaWVudCBtYXkgbmVlZCB0byBtYWtlIHVw IGV4dHJhIGRpZ2l0cyBiZXlvbmQgdGhlIHByZWNpc2lvbiBvZiBpdHMNCiAgIGNsb2NrIHRvIGFj aGlldmUgdGhpcywgZWl0aGVyIHJhbmRvbWx5IG9yIHdpdGggYSBjb3VudGVyLg0KICAgVGhlIHNl cnZlciBjYW4gdXNlIHRoaXMgcGFyYW1ldGVyIHRvIGRldGVjdCAoYW5kIHJlamVjdCkgcmVwbGF5 cy4NCg0KICAgVGhlICJ1IiBwYXJhbWV0ZXIgaXMgYW4gaWRlbnRpZmllciBmb3IgdGhlIHN5bW1l dHJpYyBzaGFyZWQga2V5IHVzZWQNCiAgIHRvIHNpZ24gdGhlIHJlcXVlc3QuIFR5cGljYWxseSBp dCBpcyBhIHVzZXItaWQuDQoNCiAgIFRoZSBvcHRpb25hbCAiYSIgcGFyYW1ldGVyIGlzIGF1dGhv cml6YXRpb24gaW5mb3JtYXRpb24gYWJvdXQgdGhlDQogICBpZGVudGl0eSBvciBwZXJtaXNzaW9u IHRoYXQgdGhlIGNsaWVudCB3YW50cyB0byBhY3QgYXMgb3Igd2l0aC4NCiAgIFRoZSBzZXJ2ZXIg aXMgcmVzcG9uc2libGUgZm9yIHZlcmlmeWluZyB0aGF0IHRoZSBhdXRob3JpemF0aW9uDQogICBp bmZvcm1hdGlvbiBpcyBhbGxvd2VkIGZvciB0aGUgYXV0aGVudGljYXRlZCBpZGVudGl0eSAoInUi IHBhcmFtZXRlcikuDQoNCiAgIFRoZSBvcHRpb25hbCAiY2IiIHBhcmFtZXRlciBpZGVudGlmaWVz IGFuIHVuZGVybHlpbmcgc2VjdXJlIGNoYW5uZWwNCiAgIGNhcnJ5aW5nIHRoZSByZXF1ZXN0IChl ZyBUTFMgb3IgSVBzZWMgY2hhbm5lbCkuDQoNCiAgIFRoZSBvcHRpb25hbCAiaCIgcGFyYW1ldGVy IGlzIGhhc2ggYWxnb3JpdGhtIHVzZWQgdG8gY2FsY3VsYXRlIHRoZQ0KICAgdmFsdWUgb2YgdGhl ICJiIiBwYXJhbWV0ZXIuDQoNCiAgIFRoZSBvcHRpb25hbCAiYiIgcGFyYW1ldGVyIGlzIHRoZSBi YXNlNjR1cmwtZW5jb2RlZCBbUkZDNDY0OF0gaGFzaA0KICAgb2YgdGhlIGJ5dGVzIG9mIHRoZSBy ZXF1ZXN0IGJvZHksIGFmdGVyIHJlbW92aW5nIGFueSB0cmFuc2Zlci1lbmNvZGluZy4NCg0KICAg VGhlICJzIiBwYXJhbWV0ZXIgaXMgdGhlIGJhc2U2NHVybC1lbmNvZGVkIE1BQyBjYWxjdWxhdGVk IG92ZXIgc2VsZWN0ZWQNCiAgIHBhcnRzIG9mIHRoZSByZXF1ZXN0IGZvcm1hdHRlZCBhcyBkZXNj cmliZWQgaW4gc2VjdGlvbiA1Lg0KDQogICBBIHNlcnZlciBTSEFMTCBpZ25vcmUgYW55IGFkZGl0 aW9uYWwgdW5yZWNvZ25pemVkIHBhcmFtZXRlcnMsDQogICB0aG91Z2ggdGhleSBhcmUgaW5jbHVk ZWQgaW4gdGhlIE1BQyBjYWxjdWxhdGlvbi4NCg0KDQo0LiAgU0lHIHNjaGVtZQ0KDQogICBUaGUg U0lHIHNjaGVtZSBkaWdpdGFsbHkgc2lnbnMgc2VsZWN0ZWQgcG9ydGlvbnMgb2YgYW4gSFRUUCBy ZXF1ZXN0LA0KICAgdXNpbmcgYW4gYXN5bW1ldHJpYyBrZXkuDQoNCjQuMS4gV1dXLUF1dGhlbnRp Y2F0ZSByZXNwb25zZSBoZWFkZXINCg0KICAgQSBzZXJ2ZXIgY2FuIGluZGljYXRlIHRoYXQgaXQg c3VwcG9ydHMgdGhlIFNJRyBzY2hlbWUgYnkgcmV0dXJuaW5nDQogICBhIFdXVy1BdXRoZW50aWNh dGlvbiByZXNwb25zZSBoZWFkZXIsIHR5cGljYWxseSBpbiBhDQogICAiNDAxIFVuYXV0aG9yaXpl ZCIgcmVzcG9uc2UgdG8gYW4gdW5hdXRoZW50aWNhdGVkIHJlcXVlc3QuDQogICANCiAgICAgV1dX LUF1dGhlbnRpY2F0ZTogU0lHIHJlYWxtPSIuLi4iDQogICAgICAgbT0iYWxnIFthbGddLi4uIg0K ICAgICAgIGM9InBhcnQgW3BhcnRdLi4uIg0KICAgICAgW289InBhcnQgW3BhcnRdLi4uIl0NCg0K ICAgVGhlIHBhcmFtZXRlcnMgaGF2ZSB0aGUgc2FtZSBtZWFuaW5ncyBhcyBmb3IgdGhlIE1BQyBz Y2hlbWUsDQogICBleGNlcHQgdGhlIGFsZ29yaXRobXMgYXJlIHNpZ25hdHVyZSBhbGdvcml0aG1z LCBpbnN0ZWFkIG9mIE1BQyBhbGdvcml0aG1zLg0KDQogICBBIGNsaWVudCBTSEFMTCBpZ25vcmUg YW55IGFkZGl0aW9uYWwgdW5yZWNvZ25pemVkIHBhcmFtZXRlcnMuDQoNCjQuMi4gQXV0aG9yaXph dGlvbiByZXF1ZXN0IGhlYWRlcg0KDQogICBUaGUgZGlnaXRhbCBzaWduYXR1cmUgU0hBTEwgYmUg Y29udmV5ZWQgaW4gYW4NCiAgIEF1dGhvcml6YXRpb24gaGVhZGVyLg0KDQogICAgIEF1dGhvcml6 YXRpb246IFNJRw0KICAgICAgIG09InNpZ19hbGciDQogICAgICAgYz0icGFydCBbcGFydF0uLi4i DQogICAgICAgdD0ieXl5eS1tbS1kZFRoaDptbTpzc1sucy4uLl1aIg0KICAgICAgIHU9ImtleV9p ZCINCiAgICAgIFtwPSJjZXJ0X3VybCJdDQogICAgICBbYT0iYXV0aHpfaW5mbyJdDQogICAgICBb Y2I9ImNoYW5uZWxfYmluZGluZyJdDQogICAgICBbaD0iaGFzaF9hbGciIGI9ImJvZHlfaGFzaCJd DQogICAgICAgcz0ic2lnIg0KDQogICBUaGUgcGFyYW1ldGVycyBoYXZlIHRoZSBzYW1lIG1lYW5p bmdzIGFzIGZvciB0aGUgTUFDIHNjaGVtZSwNCiAgIGV4Y2VwdCB0aGUgYWxnb3JpdGhtcyBhcmUg c2lnbmF0dXJlIGFsZ29yaXRobXMsIGluc3RlYWQgb2YgTUFDIGFsZ29yaXRobXMuDQoNCiAgIFRo ZSBvcHRpb25hbCAicCIgcGFyYW1ldGVyIGlzIGEgVVJJIG9mIGEgY2VydGlmaWNhdGUgZm9yIHRo ZSBwdWJsaWMta2V5DQogICB0aGF0IGNhbiB2ZXJpZnkgdGhlIHNpZ25lZCByZXF1ZXN0Lg0KDQog ICBBIHNlcnZlciBTSEFMTCBpZ25vcmUgYW55IGFkZGl0aW9uYWwgdW5yZWNvZ25pemVkIHBhcmFt ZXRlcnMsDQogICB0aG91Z2ggdGhleSBhcmUgaW5jbHVkZWQgaW4gdGhlIHNpZ25hdHVyZSB2ZXJp ZmljYXRpb24uDQoNCg0KNS4gIFJlcXVlc3QgcGFydHMgdG8gYmUgc2lnbmVkDQoNCiAgIFRoaXMg c2VjdGlvbiBkZXNjcmliZXMgaG93IHRvIGNvbnRydWN0IGEgbm9ybWFsaXplZCBieXRlIHN0cmlu ZyBmcm9tDQogICBzZWxlY3RlZCBwYXJ0cyBvZiBhIHJlcXVlc3QuIFRoZSByZXN1bHRpbmcgYnl0 ZXMgY2FuIGJlIHNpZ25lZCB3aXRoDQogICBhIE1BQyBvciBzaWduYXR1cmUgYWxnb3JpdGhtLg0K DQogICBbWw0KICAgICAgUGVyaGFwcyAxIGxpbmUgZm9yIDxtZXRob2Q+IDx1cmwgLSBpbmNsdWRp bmcgaG9zdCAmIHBvcnQgKGV2ZW4gZGVmYXVsdCk+DQogICAgICBUaGVuIGEgc29ydGVkIGxpc3Qg b2Ygc2VsZWN0ZWQgbm9ybWFsaXplZCBoZWFkZXIgbGluZXMuDQogICAgICBUaGUgQXV0aG9yaXph dGlvbiBoZWFkZXIgaXMgYWx3YXlzIGluY2x1ZGVkLCB3aXRoIHRoZSAicyIgcGFyYW1ldGVyDQog ICAgICBzZXQgdG8gYW4gZW1wdHkgc3RyaW5nIChlZyBzPSIiKS4NCiAgICAgIEFueSBvdGhlciBo ZWFkZXJzIHdob3NlIG5hbWUgb3IgcHJlZml4IGlzIGxpc3RlZCBpbiB0aGUgImMiIHBhcmFtZXRl cg0KICAgICAgaXMgYWxzbyBpbmNsdWRlZC4NCiAgICAgIE5vcm1hbGl6YXRpb24gY29uc2lzdHMg b2Y6IGNvbnZlcnRpbmcgaGVhZGVyIG5hbWVzIHRvIGxvd2VyIGNhc2U7DQogICAgICBjb2xsYXBp bmcgaGVhZGVyIHZhbHVlcyB0aGF0IGV4dGVuZCBvdmVyIG11bHRpcGxlIGxpbmVzIG9udG8gYQ0K ICAgICAgc2luZ2xlIGxpbmU7IHN0cmlwcGluZyBsZWFkaW5nIGFuZCB0cmFpbGluZyBzcGFjZSBm cm9tIGhlYWRlciB2YWx1ZXMuDQogICBdXQ0KDQoNCjcuICBTaWduaW5nIGFsZ29yaXRobXMNCg0K Ny4xLiBNQUMgYWxnb3JpdGhtIGhtYWMtc2hhLTENCg0KNy4yLiBNQUMgYWxnb3JpdGhtIGhtYWMt c2hhLTI1Ng0KDQo3LjMuIFNJRyBhbGdvcml0aG0gcnNhc3NhLXBrY3MxLXYxLjUtc2hhLTI1Ng0K DQoNCjguICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBbWw0KICAgICBBbiBXV1ctQXV0 aGVudGljYXRlIGhlYWRlciBmcm9tIGEgc2VydmVyIGFyZSBub3QgcHJvdGVjdGVkDQogICAgIGJ5 IHRoZSBNQUMgb3IgU0lHIHNjaGVtZS4gTmVpdGhlciB0aGUgY2xpZW50IG5vciB0aGUgc2VydmVy DQogICAgIHNob3VsZCBhc3N1bWUgdGhhdCB0aGUgdmFsdWUgdGhleSByZWNlaXZlZCBvciBzZW50 IGlzIHRoZSBzYW1lDQogICAgIGFzIHRoZSB2YWx1ZSB0aGUgb3RoZXIgcGFydHkgc2VudCBvciBy ZWNlaXZlZC4NCiAgICAgDQogICAgIENvbnNlcXVlbnRseSwgYSBzZXJ2ZXIgbXVzdCBjaGVjayB0 aGF0IHRoZSBhbGdvcml0aG0gYW5kIHBhcnRzDQogICAgIHJlY2VpdmVkIGluIGEgcmVxdWVzdCBh cmUgc3VmZmljaWVudCwgaW5zdGVhZCBvZiBhc3N1bWluZyB0aGV5DQogICAgIGFyZSBzdWZmaWNp ZW50IGJlY2F1c2Ugb25seSBzdWZmaWNpZW50IHZhbHVlcyBhcmUgYWR2ZXJ0aXNlZA0KICAgICBp biBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlcy4NCg0KICAgICBTaW1pbGFybHksIGEgY2xpZW50 IG11c3QgY2hlY2sgdGhhdCBhbnkgYWxnb3JpdGhtIGFuZCBwYXJ0cw0KICAgICBpbiBhIFdXVy1B dXRoZW50aWNhdGUgcmVzcG9uc2UgYXJlIHN1ZmZpY2llbnQsIGluc3RlYWQgb2YNCiAgICAgYXNz dW1pbmcgdGhleSBjb21lIGZyb20gYSB0cnVzdGVkIHNlcnZlci4NCg0KICAgICBMb3RzIG9mIG90 aGVyIGdvb2Qgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZnJvbSBvdGhlciBPQXV0aCBkcmFmdHMN CiAgICAgYW5kIHNwZWNzLg0KICAgXV0NCg0KDQo5LiAgUmVmZXJlbmNlcw0KDQo5LjEuICBOb3Jt YXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDNDY0OF0gICJUaGUgQmFzZTE2LCBCYXNlMzIsIGFu ZCBCYXNlNjQgRGF0YSBFbmNvZGluZ3MiLA0KICAgICAgICAgICAgICBSRkMgNDY0OCwgYnkgUy4g Sm9zZWZzc29uLCBPY3RvYmVyIDIwMDYuDQoNCg0KDQpBdXRob3IncyBBZGRyZXNzDQoNCiAgIEph bWVzIE1hbmdlcg0KICAgVGVsc3RyYQ0KDQogICBFbWFpbDogSmFtZXMuSC5NYW5nZXJAdGVhbS50 ZWxzdHJhLmNvbQ0K --_004_255B9BB34FB7D647A506DC292726F6E1125089AE62WSMSG3153Vsrv_-- From stpeter@stpeter.im Tue Feb 16 14:03:42 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83AA03A7BF1 for <oauth@core3.amsl.com>; Tue, 16 Feb 2010 14:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 322mCQnOwDTg for <oauth@core3.amsl.com>; Tue, 16 Feb 2010 14:03:41 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5FE0B28C115 for <oauth@ietf.org>; Tue, 16 Feb 2010 14:03:41 -0800 (PST) Received: from dhcp-64-101-72-201.cisco.com (dhcp-64-101-72-201.cisco.com [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D77FF40329 for <oauth@ietf.org>; Tue, 16 Feb 2010 15:05:16 -0700 (MST) Message-ID: <4B7B169B.8060709@stpeter.im> Date: Tue, 16 Feb 2010 15:05:15 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: OAuth WG <oauth@ietf.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020906070001070809050508" Subject: [OAUTH-WG] recording of second interim meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 16 Feb 2010 22:03:42 -0000 This is a cryptographically signed message in MIME format. --------------ms020906070001070809050508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable https://workgreen.webex.com/workgreen/lsr.php?AT=3Dpb&SP=3DMC&rID=3D38177= 42&rKey=3D16101011613cafec Blaine and I were supposed to send out the minutes 10 days after the meeting but we will do that in the next 24 hours. Sorry about the delay. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020906070001070809050508 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 hvcNAQkFMQ8XDTEwMDIxNjIyMDUxNVowIwYJKoZIhvcNAQkEMRYEFOsPt+8nMdnMjXusLBgI clKdSt/lMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAOMHCsJFvdbjps1gTgUOxJuaWbEVXn6giptEz4Uuq RIkyPf8nUSfJf4hqQ/3GBk8YDPIdFTKeH0Tvzi47ky5zllJdnfjE/uZRr0pBTImYgD+NOM6U soz6Hr/veTMsTLcute0FmYxiIRgCli5DeYf9Tx/PRKksC3xfdD1xY1ZtRpQXtjNu7UgnN6H0 ISb+hoAVrfoBmp5Cawg6dAWxjTrUQ3IDqP9WXGmljmnH1IOvxI5GcZMXOzD7baFs5PAB1ONT iHHBn1bgnnd23+qEyAZUiCN4GY3gdCe6PKpDAZNVJ1hVGRzds8EXbs3l8qazJ0Pkvp5AwCaJ bue5/6WkaHE1PwAAAAAAAA== --------------ms020906070001070809050508-- From stpeter@stpeter.im Tue Feb 16 16:25:18 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7649E28C108 for <oauth@core3.amsl.com>; Tue, 16 Feb 2010 16:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 i9RYlDLfY+-n for <oauth@core3.amsl.com>; Tue, 16 Feb 2010 16:25:17 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 797DF3A773D for <oauth@ietf.org>; Tue, 16 Feb 2010 16:25:17 -0800 (PST) Received: from squire.local (dsl-175-1.dynamic-dsl.frii.net [216.17.175.1]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1C70E40329 for <oauth@ietf.org>; Tue, 16 Feb 2010 17:26:52 -0700 (MST) Message-ID: <4B7B37CB.8060505@stpeter.im> Date: Tue, 16 Feb 2010 17:26:51 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: OAuth WG <oauth@ietf.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030906070700030107040901" Subject: [OAUTH-WG] meeting logistics for Thursday, February 18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 17 Feb 2010 00:25:18 -0000 This is a cryptographically signed message in MIME format. --------------ms030906070700030107040901 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here is the logistics information for our third interim meeting on Thursday, February 18, 2010... -------- Original Message -------- Hello , IETF Secretariat invites you to attend this online meeting. Topic: OAuth WG Virtual Meeting Date: Thursday, February 18, 2010 Time: 6:30 pm, GMT Time (London, GMT) Meeting Number: 962 808 950 Meeting Password: OAUTH ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D131809927&UID=3D11144626= 32&PW=3DNYjMyMWYyNzFi&RT=3DMiMyMQ%3D%3D <https://workgreen.webex.com/workgreen/j.php?ED=3D131809927&UID=3D1114462= 632&PW=3DNYjMyMWYyNzFi&RT=3DMiMyMQ%3D%3D> 2. Enter your name and email address. 3. Enter the meeting password: OAUTH 4. Click "Join Now". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=3D131809927&UID=3D11144626= 32&PW=3DNYjMyMWYyNzFi&ORT=3DMiMyMQ%3D%3D <https://workgreen.webex.com/workgreen/j.php?ED=3D131809927&UID=3D1114462= 632&PW=3DNYjMyMWYyNzFi&ORT=3DMiMyMQ%3D%3D> ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): 866-699-3239 Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&E= D=3D131809927&tollFree=3D1 <https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&= ED=3D131809927&tollFree=3D1> Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:962 808 950 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com <mailto:amorris@amsl.com> 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=3D131809927&UID=3D11144626= 32&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DE2RBteeDr8TVdA6eAMaM2T3fUHAeFb4FV= 1psDxJ5/Iw=3D&RT=3DMiMyMQ%3D%3D <https://workgreen.webex.com/workgreen/j.php?ED=3D131809927&UID=3D1114462= 632&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DE2RBteeDr8TVdA6eAMaM2T3fUHAeFb4F= V1psDxJ5/Iw=3D&RT=3DMiMyMQ%3D%3D> The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. --------------ms030906070700030107040901 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 hvcNAQkFMQ8XDTEwMDIxNzAwMjY1MVowIwYJKoZIhvcNAQkEMRYEFMjbMYjVDu5j9upxn0er NOWVL1hjMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAW0SjliIT+q6+Qb1SAfOgw3ohqY6PIr+vL9vLNAYO q9phsSfeQe6enNopKHHfWbiWq7xGdkKvxXMP1ryUDXqqLGhUG6A/zrt3hxUVjjNrxca6+hQf pn7oH720aV5s2Ek8wpldSeeux6zxtkihgNqor2w/O5qkinaKdYbJD6xq1UZHdGMTkUHLwPn4 3xVeak44Ks3M33ESypgfjV+6ubc+F9yZ0//mqTKTHlWusE2rKOBWUKzKwXr2iKmSD6KIDaGO M9xHgueqwBpZRe1dCS/pgOwtJgX0u9Pgj72sU1CJDaWkuaPXRduLYWDZMX9p3o5NqaLs4cIe 5TQ2AUIQ4RzdXAAAAAAAAA== --------------ms030906070700030107040901-- From romeda@gmail.com Wed Feb 17 06:16:35 2010 Return-Path: <romeda@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E328D3A72EC for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 06:16:35 -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 d17KVLdyFq-s for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 06:16:35 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.190]) by core3.amsl.com (Postfix) with ESMTP id C4FA53A72B4 for <oauth@ietf.org>; Wed, 17 Feb 2010 06:16:34 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id p33so4278gvf.15 for <oauth@ietf.org>; Wed, 17 Feb 2010 06:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=1w3wXA8QYHs5yjwE/SFjbxckicYq0RVYQvpmvc7NUqM=; b=Sg7kfbTKg9sfv/ieyNR6PO6ZS88zP8vBKmyv+AjmHf+DZCcAQ13bx2Rhfdib8T2XnH U4So0/7Np5azx8SqIodACgpGSUYEhnY7Eeyz1CUQg3KVAWM4XIgMzTy22Ve5KQv7X0P8 /tI7q2CmbaLlDtbJPppHHq0EoJla7jVCAzeO4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=gJ7T3Gg2h51PMoelHc21PEAyJckKTj1ci3rRE2bsVrr7UTwuKCTOQYL1fmCg5Hc10H lkX4X98xdyETA6wkQASJ7gIhaQwwsvgMk55dqjH/gdj5aMlrDAD+sw2cY1Tz6rZ4QerM ASGeqD+sHeaXF+T1H1Dfd6q0A2lIAGnvs/HeQ= MIME-Version: 1.0 Received: by 10.103.126.25 with SMTP id d25mr5851461mun.47.1266416289720; Wed, 17 Feb 2010 06:18:09 -0800 (PST) From: Blaine Cook <romeda@gmail.com> Date: Wed, 17 Feb 2010 14:17:48 +0000 Message-ID: <d37b4b431002170617r2e9f45a9md33cf926f25985e7@mail.gmail.com> To: oauth@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [OAUTH-WG] Proposed agenda for third interim meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 17 Feb 2010 14:16:36 -0000 Hi all, Below is a very rough agenda for Thursday's interim meeting. Your feedback is very welcome to improve this agenda, either on the list or during the meeting ("agenda bashing"). Peter and I have included a request for a scribe; if anyone would like to volunteer beforehand, we'd be very grateful as it will maximize our time on the call. The logistics are available here: http://www.ietf.org/mail-archive/web/oauth/current/msg01166.html - Please note the time, which is earlier than the last call, at 18:30 GMT, 10:30 PST, and 13:30 EST. ***** AGENDA * Intro * NOTE WELL * request for a scribe * Agenda bashing * Chair announcements * impending Area Director change * wiki pages (use cases, terminology) * call for agenda items at Anaheim meeting * Continuation of "use a token" discussion * Continuation of use case discussion * Scheduling of next interim meeting * Other business? From beaton@google.com Wed Feb 17 07:07:26 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E3C3A7D11 for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 07:07:26 -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 gZVU27poKiN3 for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 07:07:25 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 647243A7D10 for <oauth@ietf.org>; Wed, 17 Feb 2010 07:07:24 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o1HF91aH008490 for <oauth@ietf.org>; Wed, 17 Feb 2010 15:09:01 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1266419342; bh=Rul8WeCsLDSN/aLaqLJu5gAOZWk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=e1KYt9qe4jwEoVKpebZ/7H6xnyrdejp5S5jmgirMVdgfpcjV7jwH0Rj5RECZbjBgf KVQn5bESw0mibB7EfvkRA== 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=is+DXUNtazmpazNM9c2BsPKkmAEWZ3bN9p5/Sx8YoUbE//rMGHmamgaaDlv4DDM0d FghMJxsjcfrSOF7XtoUwg== Received: from vws19 (vws19.prod.google.com [10.241.21.147]) by wpaz24.hot.corp.google.com with ESMTP id o1HF8eIn006227 for <oauth@ietf.org>; Wed, 17 Feb 2010 07:09:00 -0800 Received: by vws19 with SMTP id 19so388861vws.32 for <oauth@ietf.org>; Wed, 17 Feb 2010 07:08:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.124.194 with SMTP id v2mr1971626vcr.114.1266419339486; Wed, 17 Feb 2010 07:08:59 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1125089AE62@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1125089AE62@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 17 Feb 2010 07:08:59 -0800 Message-ID: <daf5b9571002170708s6e60b215je562e992df65edd4@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] ID, MAC and SIG HTTP schemes - starting point for "use a token" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 17 Feb 2010 15:07:26 -0000 On Tue, Feb 16, 2010 at 6:38 AM, Manger, James H <James.H.Manger@team.telstra.com> wrote: > Attached is my suggested starting point for the =93how to use a token=94 = part of > OAuth. Hey James - Before I read the draft, can you comment on your use cases for the HMAC and RSA schemes? Cheers, Brian From eran@hueniverse.com Wed Feb 17 07:41:40 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D593A7EE8 for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 07:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 odu+uoFvecxG for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 07:41:39 -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 9EFB93A7EE2 for <oauth@ietf.org>; Wed, 17 Feb 2010 07:41:39 -0800 (PST) Received: (qmail 31885 invoked from network); 17 Feb 2010 15:43:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Feb 2010 15:43:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 17 Feb 2010 08:43:16 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Blaine Cook <romeda@gmail.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Wed, 17 Feb 2010 08:43:26 -0700 Thread-Topic: [OAUTH-WG] Proposed agenda for third interim meeting Thread-Index: Acqv3A41hoWwaK1xSgO2CcCy69YuYQAC3i1g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343864B4762F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <d37b4b431002170617r2e9f45a9md33cf926f25985e7@mail.gmail.com> In-Reply-To: <d37b4b431002170617r2e9f45a9md33cf926f25985e7@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 17 Feb 2010 15:41:40 -0000 It would be great to have a discussion about how people would like to move = forward given that we don't yet have consensus on which drafts to use. We n= ow have 3 alternatives but practically no discussion. I am ready to put in = editorial work but I don't know how the WG wants to proceed. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Blaine Cook > Sent: Wednesday, February 17, 2010 6:18 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Proposed agenda for third interim meeting >=20 > Hi all, >=20 > Below is a very rough agenda for Thursday's interim meeting. Your feedbac= k > is very welcome to improve this agenda, either on the list or during the > meeting ("agenda bashing"). >=20 > Peter and I have included a request for a scribe; if anyone would like to > volunteer beforehand, we'd be very grateful as it will maximize our time = on > the call. >=20 > The logistics are available here: > http://www.ietf.org/mail-archive/web/oauth/current/msg01166.html - > Please note the time, which is earlier than the last call, at 18:30 GMT, = 10:30 > PST, and 13:30 EST. >=20 > ***** >=20 > AGENDA >=20 > * Intro > * NOTE WELL > * request for a scribe >=20 > * Agenda bashing >=20 > * Chair announcements > * impending Area Director change > * wiki pages (use cases, terminology) > * call for agenda items at Anaheim meeting >=20 > * Continuation of "use a token" discussion >=20 > * Continuation of use case discussion >=20 > * Scheduling of next interim meeting >=20 > * Other business? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From tonynad@microsoft.com Wed Feb 17 12:05:12 2010 Return-Path: <tonynad@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C23F3A7D8A for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 12:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.33 X-Spam-Level: X-Spam-Status: No, score=-10.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp-Q0y1TnhYG for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 12:05:11 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 3B0C03A738A for <oauth@ietf.org>; Wed, 17 Feb 2010 12:05:11 -0800 (PST) Received: from TK5EX14CASC129.redmond.corp.microsoft.com (157.54.52.7) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 17 Feb 2010 12:07:47 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.92]) by TK5EX14CASC129.redmond.corp.microsoft.com ([157.54.52.7]) with mapi; Wed, 17 Feb 2010 12:06:27 -0800 From: Anthony Nadalin <tonynad@microsoft.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, Blaine Cook <romeda@gmail.com>, "oauth@ietf.org" <oauth@ietf.org> Thread-Topic: [OAUTH-WG] Proposed agenda for third interim meeting Thread-Index: AQHKr9w584KL5fmgsk2xKJyUAjB9UZHK9kcA///DB3A= Date: Wed, 17 Feb 2010 20:06:21 +0000 Message-ID: <A08279DC79B11C48AD587060CD9397711AFB83F8@TK5EX14MBXC101.redmond.corp.microsoft.com> References: <d37b4b431002170617r2e9f45a9md33cf926f25985e7@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B4762F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B4762F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 17 Feb 2010 20:05:12 -0000 Why is this binary choice? Looks like there are communities around each of = these -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Wednesday, February 17, 2010 7:43 AM To: Blaine Cook; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting It would be great to have a discussion about how people would like to move = forward given that we don't yet have consensus on which drafts to use. We n= ow have 3 alternatives but practically no discussion. I am ready to put in = editorial work but I don't know how the WG wants to proceed. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Blaine Cook > Sent: Wednesday, February 17, 2010 6:18 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Proposed agenda for third interim meeting >=20 > Hi all, >=20 > Below is a very rough agenda for Thursday's interim meeting. Your=20 > feedback is very welcome to improve this agenda, either on the list or=20 > during the meeting ("agenda bashing"). >=20 > Peter and I have included a request for a scribe; if anyone would like=20 > to volunteer beforehand, we'd be very grateful as it will maximize our=20 > time on the call. >=20 > The logistics are available here: > http://www.ietf.org/mail-archive/web/oauth/current/msg01166.html -=20 > Please note the time, which is earlier than the last call, at 18:30=20 > GMT, 10:30 PST, and 13:30 EST. >=20 > ***** >=20 > AGENDA >=20 > * Intro > * NOTE WELL > * request for a scribe >=20 > * Agenda bashing >=20 > * Chair announcements > * impending Area Director change > * wiki pages (use cases, terminology) > * call for agenda items at Anaheim meeting >=20 > * Continuation of "use a token" discussion >=20 > * Continuation of use case discussion >=20 > * Scheduling of next interim meeting >=20 > * Other business? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From zachary.zeltsan@alcatel-lucent.com Wed Feb 17 12:54:02 2010 Return-Path: <zachary.zeltsan@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E300628C137 for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 12:54:02 -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 e7NDD69rl+IM for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 12:54:02 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id D51593A7F1E for <oauth@ietf.org>; Wed, 17 Feb 2010 12:54:01 -0800 (PST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o1HKtbpn018201; Wed, 17 Feb 2010 14:55:37 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o1HKtbGq001937; Wed, 17 Feb 2010 14:55:37 -0600 (CST) Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 17 Feb 2010 14:55:19 -0600 From: "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> To: Blaine Cook <romeda@gmail.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Wed, 17 Feb 2010 14:55:17 -0600 Thread-Topic: [OAUTH-WG] Proposed agenda for third interim meeting Thread-Index: Acqv3BnlVvdpwLlsT5iZTUWrk9An0wANzMpA Message-ID: <5710F82C0E73B04FA559560098BF95B124EFF68397@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <d37b4b431002170617r2e9f45a9md33cf926f25985e7@mail.gmail.com> In-Reply-To: <d37b4b431002170617r2e9f45a9md33cf926f25985e7@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 17 Feb 2010 20:54:03 -0000 I volunteer to be a scribe. Zachary=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Blaine Cook > Sent: Wednesday, February 17, 2010 9:18 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Proposed agenda for third interim meeting >=20 > Hi all, >=20 > Below is a very rough agenda for Thursday's interim meeting.=20 > Your feedback is very welcome to improve this agenda, either=20 > on the list or during the meeting ("agenda bashing"). >=20 > Peter and I have included a request for a scribe; if anyone=20 > would like to volunteer beforehand, we'd be very grateful as=20 > it will maximize our time on the call. >=20 > The logistics are available here: > http://www.ietf.org/mail-archive/web/oauth/current/msg01166.ht ml - Please note the time, which is earlier than the last call, > at 18:30 = GMT, 10:30 PST, and 13:30 EST. >=20 > ***** >=20 > AGENDA >=20 > * Intro > * NOTE WELL > * request for a scribe >=20 > * Agenda bashing >=20 > * Chair announcements > * impending Area Director change > * wiki pages (use cases, terminology) > * call for agenda items at Anaheim meeting >=20 > * Continuation of "use a token" discussion >=20 > * Continuation of use case discussion >=20 > * Scheduling of next interim meeting >=20 > * Other business? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > = From eran@hueniverse.com Wed Feb 17 18:49:49 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBE628C0E0 for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 18:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 5iaSwUnbnLAQ for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 18:49:48 -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 99AD13A7A03 for <oauth@ietf.org>; Wed, 17 Feb 2010 18:49:48 -0800 (PST) Received: (qmail 22167 invoked from network); 18 Feb 2010 02:51:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Feb 2010 02:51:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 17 Feb 2010 19:51:28 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Anthony Nadalin <tonynad@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Wed, 17 Feb 2010 19:51:40 -0700 Thread-Topic: [OAUTH-WG] Proposed agenda for third interim meeting Thread-Index: AQHKr9w584KL5fmgsk2xKJyUAjB9UZHK9kcA///DB3CAAHCbkA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343864B4788E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <d37b4b431002170617r2e9f45a9md33cf926f25985e7@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B4762F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <A08279DC79B11C48AD587060CD9397711AFB83F8@TK5EX14MBXC101.redmond.corp.microsoft.com> In-Reply-To: <A08279DC79B11C48AD587060CD9397711AFB83F8@TK5EX14MBXC101.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 02:49:49 -0000 And I am not sure what your comment is about or what communities you are re= ferring to given that of the three options we have, one is half of OAuth 1.= 0, one I proposed, and one James proposed. The last two have not built a co= mmunity just yet... Our goal is to come up with a single protocol, and I need to work on a sing= le draft by collecting feedback and incorporating it. EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Wednesday, February 17, 2010 12:06 PM > To: Eran Hammer-Lahav; Blaine Cook; oauth@ietf.org > Subject: RE: [OAUTH-WG] Proposed agenda for third interim meeting >=20 > Why is this binary choice? Looks like there are communities around each o= f > these >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Wednesday, February 17, 2010 7:43 AM > To: Blaine Cook; oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting >=20 > It would be great to have a discussion about how people would like to mov= e > forward given that we don't yet have consensus on which drafts to use. We > now have 3 alternatives but practically no discussion. I am ready to put = in > editorial work but I don't know how the WG wants to proceed. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Blaine Cook > > Sent: Wednesday, February 17, 2010 6:18 AM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] Proposed agenda for third interim meeting > > > > Hi all, > > > > Below is a very rough agenda for Thursday's interim meeting. Your > > feedback is very welcome to improve this agenda, either on the list or > > during the meeting ("agenda bashing"). > > > > Peter and I have included a request for a scribe; if anyone would like > > to volunteer beforehand, we'd be very grateful as it will maximize our > > time on the call. > > > > The logistics are available here: > > http://www.ietf.org/mail-archive/web/oauth/current/msg01166.html - > > Please note the time, which is earlier than the last call, at 18:30 > > GMT, 10:30 PST, and 13:30 EST. > > > > ***** > > > > AGENDA > > > > * Intro > > * NOTE WELL > > * request for a scribe > > > > * Agenda bashing > > > > * Chair announcements > > * impending Area Director change > > * wiki pages (use cases, terminology) > > * call for agenda items at Anaheim meeting > > > > * Continuation of "use a token" discussion > > > > * Continuation of use case discussion > > > > * Scheduling of next interim meeting > > > > * Other business? > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From tonynad@microsoft.com Wed Feb 17 19:22:43 2010 Return-Path: <tonynad@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389853A78FD for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 19:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHu1trst7KzA for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 19:22:42 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 57E563A6BFC for <oauth@ietf.org>; Wed, 17 Feb 2010 19:22:42 -0800 (PST) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 17 Feb 2010 19:25:16 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.92]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi; Wed, 17 Feb 2010 19:24:16 -0800 From: Anthony Nadalin <tonynad@microsoft.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Thread-Topic: [OAUTH-WG] Proposed agenda for third interim meeting Thread-Index: AQHKr9w584KL5fmgsk2xKJyUAjB9UZHK9kcA///DB3CAAHCbkIAAkBmA Date: Thu, 18 Feb 2010 03:23:59 +0000 Message-ID: <7A5A683E-9380-4595-8317-EBCDE4B0F328@microsoft.com> References: <d37b4b431002170617r2e9f45a9md33cf926f25985e7@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B4762F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <A08279DC79B11C48AD587060CD9397711AFB83F8@TK5EX14MBXC101.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343864B4788E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B4788E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <18244282-b70b-4b04-820f-72285d49f132> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 03:22:43 -0000 Very odd. The other community is WRAP unless you have already excluded =20 that. On Feb 17, 2010, at 6:51 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> =20 wrote: > And I am not sure what your comment is about or what communities you =20 > are referring to given that of the three options we have, one is =20 > half of OAuth 1.0, one I proposed, and one James proposed. The last =20 > two have not built a community just yet... > > Our goal is to come up with a single protocol, and I need to work on =20 > a single draft by collecting feedback and incorporating it. > > EHL > >> -----Original Message----- >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] >> Sent: Wednesday, February 17, 2010 12:06 PM >> To: Eran Hammer-Lahav; Blaine Cook; oauth@ietf.org >> Subject: RE: [OAUTH-WG] Proposed agenda for third interim meeting >> >> Why is this binary choice? Looks like there are communities around =20 >> each of >> these >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =20 >> Behalf >> Of Eran Hammer-Lahav >> Sent: Wednesday, February 17, 2010 7:43 AM >> To: Blaine Cook; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting >> >> It would be great to have a discussion about how people would like =20 >> to move >> forward given that we don't yet have consensus on which drafts to =20 >> use. We >> now have 3 alternatives but practically no discussion. I am ready =20 >> to put in >> editorial work but I don't know how the WG wants to proceed. >> >> EHL >> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =20 >>> Behalf >>> Of Blaine Cook >>> Sent: Wednesday, February 17, 2010 6:18 AM >>> To: oauth@ietf.org >>> Subject: [OAUTH-WG] Proposed agenda for third interim meeting >>> >>> Hi all, >>> >>> Below is a very rough agenda for Thursday's interim meeting. Your >>> feedback is very welcome to improve this agenda, either on the =20 >>> list or >>> during the meeting ("agenda bashing"). >>> >>> Peter and I have included a request for a scribe; if anyone would =20 >>> like >>> to volunteer beforehand, we'd be very grateful as it will maximize =20 >>> our >>> time on the call. >>> >>> The logistics are available here: >>> http://www.ietf.org/mail-archive/web/oauth/current/msg01166.html - >>> Please note the time, which is earlier than the last call, at 18:30 >>> GMT, 10:30 PST, and 13:30 EST. >>> >>> ***** >>> >>> AGENDA >>> >>> * Intro >>> * NOTE WELL >>> * request for a scribe >>> >>> * Agenda bashing >>> >>> * Chair announcements >>> * impending Area Director change >>> * wiki pages (use cases, terminology) >>> * call for agenda items at Anaheim meeting >>> >>> * Continuation of "use a token" discussion >>> >>> * Continuation of use case discussion >>> >>> * Scheduling of next interim meeting >>> >>> * Other business? >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > From stpeter@stpeter.im Wed Feb 17 19:37:18 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189A828C282 for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 19:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 LWtIbTegE6ki for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 19:37:17 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 19E3D28C12C for <oauth@ietf.org>; Wed, 17 Feb 2010 19:37:17 -0800 (PST) Received: from squire.local (dsl-205-54.dynamic-dsl.frii.net [216.17.205.54]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3101C40337 for <oauth@ietf.org>; Wed, 17 Feb 2010 20:38:57 -0700 (MST) Message-ID: <4B7CB650.70300@stpeter.im> Date: Wed, 17 Feb 2010 20:38:56 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <d37b4b431002170617r2e9f45a9md33cf926f25985e7@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B4762F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <A08279DC79B11C48AD587060CD9397711AFB83F8@TK5EX14MBXC101.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343864B4788E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7A5A683E-9380-4595-8317-EBCDE4B0F328@microsoft.com> In-Reply-To: <7A5A683E-9380-4595-8317-EBCDE4B0F328@microsoft.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020808060408020102030708" Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 03:37:18 -0000 This is a cryptographically signed message in MIME format. --------------ms020808060408020102030708 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <hat type=3D'individual'/> On 2/17/10 8:23 PM, Anthony Nadalin wrote: > Very odd. The other community is WRAP unless you have already excluded = =20 > that. Extraordinarily odd. Aren't we one community that happens to be communicating on several different lists? :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020808060408020102030708 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 hvcNAQkFMQ8XDTEwMDIxODAzMzg1NlowIwYJKoZIhvcNAQkEMRYEFOLbfoEmycQjfqUUdUq3 ePjXTyIoMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAJxs1AZGZ7ejhqYnA6OnrXdBD13ruNY47W8sVxqmv VKWsEZLuWTjIJlHduubX7zp9frWhSkFApP4aQYSrLdeH3AiUxliZc14sw3HOJDq15R1RCKiO U8tij8zFpbhAo38xhb8+ZqS95zKrkeOIcPupqygTZ/ptJK1tU84SRpMGaS+TCLlyPa01NZ5S SVoThjO5MI7KalufKaBv7h4mduKF1PpuDppgENkp00NW4S35D8r6S2DSx5DNmlDALeq42S6o Uin1IQnZ6gpRmDEWdu962Kg1/tkCYqgvh7AwKfoaK59SnHNutvhYi092NB2kd8OR4XZFYIYQ kYUMDGgj1MLgRgAAAAAAAA== --------------ms020808060408020102030708-- From James.H.Manger@team.telstra.com Wed Feb 17 21:08:49 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DE53A75C8 for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 21:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBhMTwx2OngW for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 21:08:48 -0800 (PST) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id 194A128C0EE for <oauth@ietf.org>; Wed, 17 Feb 2010 21:08:47 -0800 (PST) Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipbi.ntcif.telstra.com.au with ESMTP; 18 Feb 2010 16:10:28 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id A53A3FF86; Thu, 18 Feb 2010 16:10:27 +1100 (EST) Received: from WSMSG3704.srv.dir.telstra.com (wsmsg3704.srv.dir.telstra.com [172.49.40.197]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 6FD4942122; Thu, 18 Feb 2010 16:09:21 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Thu, 18 Feb 2010 16:09:51 +1100 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Brian Eaton <beaton@google.com>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Thu, 18 Feb 2010 16:09:49 +1100 Thread-Topic: [OAUTH-WG] ID, MAC and SIG HTTP schemes - starting point for "use a token" Thread-Index: Acqv4yitl60oDWENRialyCKk9YXwUgAcI+kA Message-ID: <255B9BB34FB7D647A506DC292726F6E1125094F28A@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1125089AE62@WSMSG3153V.srv.dir.telstra.com> <daf5b9571002170708s6e60b215je562e992df65edd4@mail.gmail.com> In-Reply-To: <daf5b9571002170708s6e60b215je562e992df65edd4@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] ID, MAC and SIG HTTP schemes - starting point for "use a token" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 05:08:49 -0000 PiBCZWZvcmUgSSByZWFkIHRoZSBkcmFmdCwgY2FuIHlvdSBjb21tZW50IG9uIHlvdXIgdXNlIGNh c2VzIGZvciB0aGUNCj4gSE1BQyBhbmQgUlNBIHNjaGVtZXM/DQoNCkkgZG9u4oCZdCBoYXZlIGEg Y3VycmVudCBkZXNpcmUgdG8gdXNlIHRoZSBITUFDIG9yIFJTQSBzY2hlbWVzLg0KSSBkbyBoYXZl IGEgc3Ryb25nIGRlc2lyZSBOT1QgdG8gZGVmaW5lIGFuIE9BdXRoLXNwZWNpZmljIHdheSB0byBz aWduIEhUVFAgcmVxdWVzdHMsIHRoYXQgaXNuJ3QgYXBwbGljYWJsZSB0byBhbnkgYXBwIHRoYXQg d2FudHMgdG8gYXV0aGVudGljYXRlICJpbXBvcnRhbnQiIHBhcnRzIG9mIGEgSFRUUCByZXF1ZXN0 IHdpdGggYSBrZXksIG9yIGRvZXNuJ3QgZm9sbG93IHRoZSBleGlzdGluZyBtb2RlbCBmb3IgSFRU UCBhdXRoZW50aWNhdGlvbiAoaW5jbHVkaW5nIGludGVyb3AgZ2l2ZW4ganVzdCBhIHVzZXItaWQg YW5kIGtleSkuDQoNCk15ICJ1c2UgY2FzZSIgZm9yIEhNQUMgYW5kIFJTQSBzY2hlbWVzIGlzIHRo YXQgT0F1dGggMSAoc3BlY3MgYW5kIGltcGxlbWVudGF0aW9ucyksIHBsdXMgRXJhbuKAmXMgZHJh ZnRzLCB1c2UgaXQuDQoNCkkgd291bGQgYmUgaGFwcHkgdG8gc2VlIEhNQUMgYW5kIFJTQSBzY2hl bWVzIGRyb3BwZWQgZnJvbSBmdXR1cmUgT0F1dGggc3BlY3MgY29tcGxldGVseSAoYSBsYSBXUkFQ LCBidXQgd2ViLXN0eWxlKS4NCg0KLS0gDQpKYW1lcyBNYW5nZXINCg== From eran@hueniverse.com Wed Feb 17 22:11:31 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7ED28C0CF for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 22:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 q9v6NaN258tt for <oauth@core3.amsl.com>; Wed, 17 Feb 2010 22:11:25 -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 A39B63A792E for <oauth@ietf.org>; Wed, 17 Feb 2010 22:11:20 -0800 (PST) Received: (qmail 6357 invoked from network); 18 Feb 2010 06:13:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Feb 2010 06:13:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 17 Feb 2010 23:13:00 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Anthony Nadalin <tonynad@microsoft.com> Date: Wed, 17 Feb 2010 23:13:11 -0700 Thread-Topic: [OAUTH-WG] Proposed agenda for third interim meeting Thread-Index: AQHKr9w584KL5fmgsk2xKJyUAjB9UZHK9kcA///DB3CAAHCbkIAAkBmA//+fVpA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343864B478B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <d37b4b431002170617r2e9f45a9md33cf926f25985e7@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B4762F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <A08279DC79B11C48AD587060CD9397711AFB83F8@TK5EX14MBXC101.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343864B4788E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7A5A683E-9380-4595-8317-EBCDE4B0F328@microsoft.com> In-Reply-To: <7A5A683E-9380-4595-8317-EBCDE4B0F328@microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 06:11:32 -0000 I don't know why you feel like I am dismissing WRAP (or its community). I w= as the one asking and pushing Dick to submit it to the WG, and have been th= e first to propose we use it as the foundation of the 'how to get a token' = part of the protocol. I have a lot of criticism about the how WRAP came to be, but I have only ma= de a single complaint about its technical properties (using bearer tokens o= ver an insecure channel, in which I am far from being alone). In other word= s, I think WRAP is a positive contribution and a significant part of what I= envision OAuth 2.0 to be. As for the specification itself, WRAP doesn't include any signature algorit= hm which means there is nothing there to build on when it comes to the main= focus of the 'using a token' part. We had previous WG rough consensus on d= ropping support for POST parameters and (for now) URI query parameters (whi= ch we can revisit). This leaves very little to work with in section 4 of dr= aft-hardt-oauth. I didn't see anything back from Dick (or anyone else) about my response to = his proposal to start off WRAP, so I assumed there was no objection to excl= uding it from this specific discussion. If you want to bring it back to the= table, please do, but explain why you feel that it's a better choice than = the other three proposals. As the specification editor, I have no interest in starting from scratch ag= ain. We have three texts offering a good starting point, each with a differ= ent set of pluses and minuses. We need to pick one and start picking at it,= making iterative changes towards consensus. When we are done, we can alway= s cut and paste it into the WRAP draft to replace section 4 if we feel it i= s the most effective way forward. But that's for later. If we can't agree on the process, I don't know how we can agree on the tech= nical details. EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Wednesday, February 17, 2010 7:24 PM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting >=20 > Very odd. The other community is WRAP unless you have already excluded > that. >=20 >=20 >=20 > On Feb 17, 2010, at 6:51 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> > wrote: >=20 > > And I am not sure what your comment is about or what communities you > > are referring to given that of the three options we have, one is half > > of OAuth 1.0, one I proposed, and one James proposed. The last two > > have not built a community just yet... > > > > Our goal is to come up with a single protocol, and I need to work on a > > single draft by collecting feedback and incorporating it. > > > > EHL > > > >> -----Original Message----- > >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] > >> Sent: Wednesday, February 17, 2010 12:06 PM > >> To: Eran Hammer-Lahav; Blaine Cook; oauth@ietf.org > >> Subject: RE: [OAUTH-WG] Proposed agenda for third interim meeting > >> > >> Why is this binary choice? Looks like there are communities around > >> each of these > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Eran Hammer-Lahav > >> Sent: Wednesday, February 17, 2010 7:43 AM > >> To: Blaine Cook; oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting > >> > >> It would be great to have a discussion about how people would like to > >> move forward given that we don't yet have consensus on which drafts > >> to use. We now have 3 alternatives but practically no discussion. I > >> am ready to put in editorial work but I don't know how the WG wants > >> to proceed. > >> > >> EHL > >> > >>> -----Original Message----- > >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>> Behalf Of Blaine Cook > >>> Sent: Wednesday, February 17, 2010 6:18 AM > >>> To: oauth@ietf.org > >>> Subject: [OAUTH-WG] Proposed agenda for third interim meeting > >>> > >>> Hi all, > >>> > >>> Below is a very rough agenda for Thursday's interim meeting. Your > >>> feedback is very welcome to improve this agenda, either on the list > >>> or during the meeting ("agenda bashing"). > >>> > >>> Peter and I have included a request for a scribe; if anyone would > >>> like to volunteer beforehand, we'd be very grateful as it will > >>> maximize our time on the call. > >>> > >>> The logistics are available here: > >>> http://www.ietf.org/mail-archive/web/oauth/current/msg01166.html - > >>> Please note the time, which is earlier than the last call, at 18:30 > >>> GMT, 10:30 PST, and 13:30 EST. > >>> > >>> ***** > >>> > >>> AGENDA > >>> > >>> * Intro > >>> * NOTE WELL > >>> * request for a scribe > >>> > >>> * Agenda bashing > >>> > >>> * Chair announcements > >>> * impending Area Director change > >>> * wiki pages (use cases, terminology) > >>> * call for agenda items at Anaheim meeting > >>> > >>> * Continuation of "use a token" discussion > >>> > >>> * Continuation of use case discussion > >>> > >>> * Scheduling of next interim meeting > >>> > >>> * Other business? > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > From tonynad@microsoft.com Thu Feb 18 07:38:57 2010 Return-Path: <tonynad@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB333A7ED1 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 07:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.438 X-Spam-Level: X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyVfrYid+Zvb for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 07:38:53 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 9CF453A7AEA for <oauth@ietf.org>; Thu, 18 Feb 2010 07:38:53 -0800 (PST) Received: from TK5EX14CASC130.redmond.corp.microsoft.com (157.54.52.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 18 Feb 2010 07:41:33 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.92]) by TK5EX14CASC130.redmond.corp.microsoft.com ([157.54.52.9]) with mapi; Thu, 18 Feb 2010 07:40:12 -0800 From: Anthony Nadalin <tonynad@microsoft.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Thread-Topic: [OAUTH-WG] Proposed agenda for third interim meeting Thread-Index: AQHKr9w584KL5fmgsk2xKJyUAjB9UZHK9kcA///DB3CAAHCbkIAAkBmA//+fVpCAAKbGcA== Date: Thu, 18 Feb 2010 15:40:06 +0000 Message-ID: <A08279DC79B11C48AD587060CD9397711AFB963A@TK5EX14MBXC101.redmond.corp.microsoft.com> References: <d37b4b431002170617r2e9f45a9md33cf926f25985e7@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B4762F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <A08279DC79B11C48AD587060CD9397711AFB83F8@TK5EX14MBXC101.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343864B4788E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7A5A683E-9380-4595-8317-EBCDE4B0F328@microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343864B478B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B478B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 15:38:57 -0000 I was not aware that anyone had to bring WRAP back to the table, as I never= realized that you dismissed this as a starting point. So I thought the pro= cess was to go through the use cases which will help distill out some of th= e function/features/requirements and I'm sure that will help use choose a s= trating point. -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Wednesday, February 17, 2010 10:13 PM To: Anthony Nadalin Cc: OAuth WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Proposed agenda for third interim meeting I don't know why you feel like I am dismissing WRAP (or its community). I w= as the one asking and pushing Dick to submit it to the WG, and have been th= e first to propose we use it as the foundation of the 'how to get a token' = part of the protocol. I have a lot of criticism about the how WRAP came to be, but I have only ma= de a single complaint about its technical properties (using bearer tokens o= ver an insecure channel, in which I am far from being alone). In other word= s, I think WRAP is a positive contribution and a significant part of what I= envision OAuth 2.0 to be. As for the specification itself, WRAP doesn't include any signature algorit= hm which means there is nothing there to build on when it comes to the main= focus of the 'using a token' part. We had previous WG rough consensus on d= ropping support for POST parameters and (for now) URI query parameters (whi= ch we can revisit). This leaves very little to work with in section 4 of dr= aft-hardt-oauth. I didn't see anything back from Dick (or anyone else) about my response to = his proposal to start off WRAP, so I assumed there was no objection to excl= uding it from this specific discussion. If you want to bring it back to the= table, please do, but explain why you feel that it's a better choice than = the other three proposals. As the specification editor, I have no interest in starting from scratch ag= ain. We have three texts offering a good starting point, each with a differ= ent set of pluses and minuses. We need to pick one and start picking at it,= making iterative changes towards consensus. When we are done, we can alway= s cut and paste it into the WRAP draft to replace section 4 if we feel it i= s the most effective way forward. But that's for later. If we can't agree on the process, I don't know how we can agree on the tech= nical details. EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Wednesday, February 17, 2010 7:24 PM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting >=20 > Very odd. The other community is WRAP unless you have already excluded=20 > that. >=20 >=20 >=20 > On Feb 17, 2010, at 6:51 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> > wrote: >=20 > > And I am not sure what your comment is about or what communities you=20 > > are referring to given that of the three options we have, one is=20 > > half of OAuth 1.0, one I proposed, and one James proposed. The last=20 > > two have not built a community just yet... > > > > Our goal is to come up with a single protocol, and I need to work on=20 > > a single draft by collecting feedback and incorporating it. > > > > EHL > > > >> -----Original Message----- > >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] > >> Sent: Wednesday, February 17, 2010 12:06 PM > >> To: Eran Hammer-Lahav; Blaine Cook; oauth@ietf.org > >> Subject: RE: [OAUTH-WG] Proposed agenda for third interim meeting > >> > >> Why is this binary choice? Looks like there are communities around=20 > >> each of these > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > >> Behalf Of Eran Hammer-Lahav > >> Sent: Wednesday, February 17, 2010 7:43 AM > >> To: Blaine Cook; oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Proposed agenda for third interim meeting > >> > >> It would be great to have a discussion about how people would like=20 > >> to move forward given that we don't yet have consensus on which=20 > >> drafts to use. We now have 3 alternatives but practically no=20 > >> discussion. I am ready to put in editorial work but I don't know=20 > >> how the WG wants to proceed. > >> > >> EHL > >> > >>> -----Original Message----- > >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > >>> Behalf Of Blaine Cook > >>> Sent: Wednesday, February 17, 2010 6:18 AM > >>> To: oauth@ietf.org > >>> Subject: [OAUTH-WG] Proposed agenda for third interim meeting > >>> > >>> Hi all, > >>> > >>> Below is a very rough agenda for Thursday's interim meeting. Your=20 > >>> feedback is very welcome to improve this agenda, either on the=20 > >>> list or during the meeting ("agenda bashing"). > >>> > >>> Peter and I have included a request for a scribe; if anyone would=20 > >>> like to volunteer beforehand, we'd be very grateful as it will=20 > >>> maximize our time on the call. > >>> > >>> The logistics are available here: > >>> http://www.ietf.org/mail-archive/web/oauth/current/msg01166.html -=20 > >>> Please note the time, which is earlier than the last call, at=20 > >>> 18:30 GMT, 10:30 PST, and 13:30 EST. > >>> > >>> ***** > >>> > >>> AGENDA > >>> > >>> * Intro > >>> * NOTE WELL > >>> * request for a scribe > >>> > >>> * Agenda bashing > >>> > >>> * Chair announcements > >>> * impending Area Director change > >>> * wiki pages (use cases, terminology) > >>> * call for agenda items at Anaheim meeting > >>> > >>> * Continuation of "use a token" discussion > >>> > >>> * Continuation of use case discussion > >>> > >>> * Scheduling of next interim meeting > >>> > >>> * Other business? > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > From eran@hueniverse.com Thu Feb 18 09:12:33 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97BE3A7FBB for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 09:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 F95-Nk93Bdym for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 09:12:32 -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 9D10E3A7EE3 for <oauth@ietf.org>; Thu, 18 Feb 2010 09:12:31 -0800 (PST) Received: (qmail 24451 invoked from network); 18 Feb 2010 17:14:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Feb 2010 17:14:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 18 Feb 2010 10:14:12 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Thu, 18 Feb 2010 10:14:25 -0700 Thread-Topic: WG Survey Thread-Index: AcqwvdIpwql/pJksQI6hDRprwnPDjA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 17:12:34 -0000 A few questions we should answer before moving forward. Considering *your* = use cases and reasons for being here: 1. Why are you here? What are you trying to solve that is not already addre= ssed by existing specifications (OAuth 1.0a, WRAP, etc)? 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? = Something else? 3. If we start from draft-hammer-oauth, what needs to change to turn it int= o OAuth 2.0? 4. If we start from draft-hardt-oauth, what needs to change to turn it into= OAuth 2.0? 5. Do you think the approach of working first on 'how to use a token' and t= hen on 'how to get a token' is right? 6. Should we go back to working on a single specification? 7. Do you think the protocol should include a signature-based authenticatio= n scheme? EHL From email@pbryan.net Thu Feb 18 10:19:27 2010 Return-Path: <email@pbryan.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200513A7FEA for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 10:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 QFTidXe87rXu for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 10:19:26 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 533153A7FE0 for <oauth@ietf.org>; Thu, 18 Feb 2010 10:19:26 -0800 (PST) Received: from [192.168.0.5] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 225F8EA022 for <oauth@ietf.org>; Thu, 18 Feb 2010 18:21:09 +0000 (UTC) From: "Paul C. Bryan" <email@pbryan.net> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 18 Feb 2010 10:20:46 -0800 Message-ID: <1266517246.31725.59.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 18:19:27 -0000 On Thu, 2010-02-18 at 10:14 -0700, Eran Hammer-Lahav wrote: > A few questions we should answer before moving forward. Considering > *your* use cases and reasons for being here: > > 1. Why are you here? I have built and plan to continue building OAuth implementations. I am also working on the UMA protocol, which currently relies heavily on OAuth. > What are you trying to solve that is not already addressed by existing > specifications (OAuth 1.0a, WRAP, etc)? OAuth 1.x currently requires signatures that include consumer key and secret, which is problematic when (distributed) policy enforcement points need consumer key material to verify signatures. OAuth has a lot of potential for securing resources, beyond its current scope of delegating access. Separating delegation from authentication further supports this. > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting > point? Something else? OAuth 1.0a. > 3. If we start from draft-hammer-oauth, what needs to change to turn > it into OAuth 2.0? Off the top of my head: - separation of token issuance (delegation) and request authentication - abstract token format w. concrete minimum supportable set - token usage profiles (e.g. bearer vs. symmetric key vs. asymmetric) > 4. If we start from draft-hardt-oauth, what needs to change to turn it > into OAuth 2.0? No comment. > 5. Do you think the approach of working first on 'how to use a token' > and then on 'how to get a token' is right? Yes. > 6. Should we go back to working on a single specification? Yes. > 7. Do you think the protocol should include a signature-based > authentication scheme? Yes. Paul > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Thu Feb 18 10:41:46 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6A93A8021 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 10:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoVu6rSCbeyz for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 10:41:45 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4D1683A801B for <oauth@ietf.org>; Thu, 18 Feb 2010 10:41:45 -0800 (PST) Received: from dhcp-64-101-72-201.cisco.com (dhcp-64-101-72-201.cisco.com [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7B71040D03 for <oauth@ietf.org>; Thu, 18 Feb 2010 11:43:28 -0700 (MST) Message-ID: <4B7D8A4F.3030308@stpeter.im> Date: Thu, 18 Feb 2010 11:43:27 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: OAuth WG <oauth@ietf.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010702030904010809000006" Subject: [OAUTH-WG] Fwd: Document Action: 'The OAuth 1.0 Protocol' to Informational RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 18:41:46 -0000 This is a cryptographically signed message in MIME format. --------------ms010702030904010809000006 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI. Thanks to Eran for his work on this. Now let's make progress on OAuth 2.0. :) -------- Original Message -------- Subject: Document Action: 'The OAuth 1.0 Protocol' to Informational RFC Date: Wed, 17 Feb 2010 15:01:36 -0800 (PST) From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org> The IESG has approved the following document: - 'The OAuth 1.0 Protocol ' <draft-hammer-oauth-10.txt> as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hammer-oauth-10.txt Technical Summary OAuth provides a method for Web clients to access Web server resources= on behalf of a resource owner (such as a different client or an end- user). It also provides a process for end-users to authorize third party access to their server resources without sharing their credentials (typically, a username and password pair), using user- agent redirections. Working Group Summary This is not a WG product. However, it was reviewed by the OAUTH WG. The OAUTH WG is working on a standards track revision of OAUTH, but in the meantime, this is a useful work product because it fixes several errata in the pre-IETF version of the protocol and establishes= an IETF-reviewed specification for the community-implemented protocol.= Document Quality There are many existing implementations of this specification, because it was the subject of an ad-hoc "standardization" effort involving quite a few individuals and implementors. Personnel Lisa Dusseault is the sponsor of the document. Note to RFC Editor Please make the following changes in the published RFC OLD: The OAuth protocol was originally created by a small community of web developers from a variety of websites and other Internet services, who wanted to solve the common problem of enabling delegated access to protected resources. The resulting OAuth protocol was stabilized at version 1.0 in October 2007 and published at the oauth.net website [1]. This specification provides an informational documentation of OAuth Core 1.0 Revision A as finalized in June 2009, addressing several errata reported since that time, as well as numerous editorial clarifications. It is not an item of the IETF's OAuth Working Group, which at the time of writing is working on an OAuth version that can be appropriate for publication on the standards track. NEW: The OAuth protocol was originally created by a small community of web developers from a variety of websites and other Internet services, who wanted to solve the common problem of enabling delegated access to protected resources. The resulting OAuth protocol was stabilized at version 1.0 in October 2007, and revised in June 2009 (revision A) a= s published at <http://oauth.net/core/1.0a>. This specification provides an informational documentation of OAuth Core 1.0 Revision A, addressing several errata reported since that time= , as well as numerous editorial clarifications. While this specification= is not an item of the IETF's OAuth Working Group, which at the time of writing= is working on an OAuth version that can be appropriate for publication on the standards track, it has been transferred to the IETF for change control= by authors of the original work. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------ms010702030904010809000006 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 hvcNAQkFMQ8XDTEwMDIxODE4NDMyN1owIwYJKoZIhvcNAQkEMRYEFLQhSJyCgBL5vDJZkyS1 Hl913iD/MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAiYcTYr/3JFeP7YAl6hlpZ6Rp6Io34HcdDib74y7e xmM1cX0Xtb0pTZwu/ryFYBUnGrnXbw+buc85X0YmYISPQTdBqWpDwU4ugjUoyws8BnMoV5JJ 6ZtOjHALNmv8Vu3OyR4JgKAJ4hcdHZJnlcODj1o8wxMOLA3yiiM8Y6iKaOwoVl+A3T5BWUsJ gxctCGlf61S7TN4+LbIkwdIfw0O7FFJRGBEJkLv6KbeWuo1PPik8qjXjthLm6KTTM/h25qLv 1CRHoZtpAY+6lsRCNlN7NUNBrfKjj4QcHV8KaSr+U+kRC1cHcRvU2WrELCL7/8+fuOHExxff ht3gdJkRsvnyRAAAAAAAAA== --------------ms010702030904010809000006-- From torsten@lodderstedt.net Thu Feb 18 12:27:01 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048A928C16F for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 12:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u36ky5KVJI8P for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 12:27:00 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by core3.amsl.com (Postfix) with ESMTP id A29E63A805B for <oauth@ietf.org>; Thu, 18 Feb 2010 12:26:58 -0800 (PST) Received: from p4fff1386.dip.t-dialin.net ([79.255.19.134] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1NiCzJ-0001sv-GG; Thu, 18 Feb 2010 21:28:41 +0100 Message-ID: <4B7DA2EF.9080606@lodderstedt.net> Date: Thu, 18 Feb 2010 21:28:31 +0100 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Eran Hammer-Lahav <eran@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 20:27:01 -0000 Hi, > A few questions we should answer before moving forward. Considering *your* use cases and reasons for being here: > > 1. Why are you here? I'm interested to learn about status and directions of upcomming OAuth 2.0 standard and to contribute my experiences with token based web service security infrastructures. > What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)? > I would appreciate improved support for environments with central authorization services and an "open triangle" style architecture (no direct communication between web service and authorization server) . OAuth 1.0a requires the protected resource to know consumer key and secret, which is a security issue in our environment (central authorization server, various services exposing protected resources outside of our control). It should be sufficent to use token related data in order to verify a token (or a message carrying the token, respectively). Just passing the token (bearer tokens) to a service should be an option (typically over HTTPS). It is difficult to revoke access tokens in our environment. I see the following options: a) Force the protected resource to check the token validity on each request (requires remote calls - imperformant) b) Push revocations to all services (complex) c) Use a combination of long (months)- and short-living (minutes-hours) tokens, long-living tokens are exchanged for short living tokens, which in turn are used for service invocation. The revocation is checked by the authorization server when issuing short-living tokens. The coming OAuth spec should support option (c) > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? Something else? > draft-hammer-http-token-auth + WRAP > 3. If we start from draft-hammer-oauth, what needs to change to turn it into OAuth 2.0? > > 4. If we start from draft-hardt-oauth, what needs to change to turn it into OAuth 2.0? > authorization servers should optionally issue token secrets in order to support message signing. > 5. Do you think the approach of working first on 'how to use a token' and then on 'how to get a token' is right? > Both topics interdependent on each other, so building the big picture first and elaborate the specification in two steps later on might be better > 6. Should we go back to working on a single specification? > yes. > 7. Do you think the protocol should include a signature-based authentication scheme? > yes. regards, Torsten. > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From stpeter@stpeter.im Thu Feb 18 12:27:41 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA34628C105 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 12:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDZhV0tLJDqJ for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 12:27:40 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7D3793A8061 for <oauth@ietf.org>; Thu, 18 Feb 2010 12:27:40 -0800 (PST) Received: from dhcp-64-101-72-201.cisco.com (dhcp-64-101-72-201.cisco.com [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8439640337 for <oauth@ietf.org>; Thu, 18 Feb 2010 13:29:23 -0700 (MST) Message-ID: <4B7DA322.60807@stpeter.im> Date: Thu, 18 Feb 2010 13:29:22 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: OAuth WG <oauth@ietf.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080705080305050309050203" Subject: [OAUTH-WG] good meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 20:27:42 -0000 This is a cryptographically signed message in MIME format. --------------ms080705080305050309050203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That was a helpful discussion just now -- thanks to everyone who participated. Jeff Hodges and I made some *rough* notes via EtherPad at http://etherpad.com/n2jOXo3WTY and I paste them below. Real minutes will follow once we've had a chance to listen to the recording. --Peter ## OAuth interim #3 [notes picked up in progress] Blaine: cert chains often aren't checked in libraries, but I like the elegance of no distinction between consumer and access token -- instead SP decides what token means (James Manger's proposal to separate tokens from signatures) Brian: IETF OAuth work should try to provide security for those who are not able or willing to use SSL? Blaine: I think so Brian: how much security can we reasonably provide for those people? need to be really clear about threat models Blaine: e.g. in Twitter originally were concerned about replay attacks, also concerns about refresh tokens Brian: let's explore the Twitter example -- they send cookies over HTTP but passwords over HTTPS, but when they have issues it's usually operational issues, weak passwords, etc. Hannes: re-use of an eavesdropped token depends on the application, but how much concern is there about off-path attacks? Blaine: I definitely support bearer tokens Brian: my point is that it's silly to use OAuth as a replacement for HTTPS -- what are the threat models that HTTPS doesn't protect against? Hannes: I wouldn't put that as a design constraint -- this is true for everything, not just OAuth over HTTPS JeffH: TLS/SSL doesn't give you message integrity and replay protection (if you keep the message around) -- secure channels provide integrity (and encryption) of the channel but not integrity outside the context of the channel Hannes: the same is true of an OAuth token once unbundled, if you share it with other entities JeffH: my point is only that the secure channel doesn't protect a token outside the channel Hannes: distinction between transport layer security and application layer security (yes, this is a good way to put it) Peter: it seems that we don't have a clear threat model Blaine: is the threat developers? people are lazy... Brian: we have a real problem with operational security (e.g., credentials kept in plaintext on the service provider) -- if we have a bearer token model then we won't need to keep credentials in plaintext Hannes: I have a proposal -- we won't be able to have one approach that satisfies everyone, but we can at least describe the threat model more clearly and let people choose which features solve those problems Peter: that might make sense Hannes: what are people's constraints in implementation and deployment? Brian: all widely deployed security technologies use transport security or bearer tokens Blaine: I somewhat disagree -- percentages might be larger at a service like Twitter or Flickr than at a broader service like Google or Yahoo! Blaine: my observation is that no one has ever deployed a bearer token system that works, other than cookies -- I think that OAuth tokens that can be signed can work quite well [scribal note: we will have an audio recording] Brian: Microsoft and Kerberos support Blaine: not on the web Brian: how about OpenID? Blaine: but no one uses that Brian: how about SSO systems between Yahoo and Flickr? Blaine: Flickr people complain about that :) Blaine: bearer tokens like Flickr's capability URLs don't have strong security Blaine: do we need [lost] JeffH: OAuth as toolkit that gets profiled for different use cases -- the current split among the documents makes sense -- the Token I-D is the basic toolkit, and the "delegation" I-D is an example of a particular profile for a (small) range of use cases. Hannes: what is the disagreement at that point? [the chair falls down on note-taking] Brian: we were trying something that had never been done before Blaine: maybe it is that the signatures are too hard, but we don't really know Eve: we have existence proofs of it working, but maybe not wide interop Brian: what is the threat model behind signatures? what are signatures fo= r? Eve: signatures are not there to substitute for channel security, but provide attestations or other features that can't be derived from channel security -- might need strong identity proofing Brian: is a bearer token that lasts one minute OK? Eve: interested in data origin authentication and fact attestation Paul: a bearer token might not show intention, signatures provide a strong indication Brian: not sufficient that bearer token have a short lifetime -- need to sign the whole message? Paul: yes, the body would need to be protected Brian: in that case, it seems as if the IETF OAuth draft doesn't give you what you need because it secures only the URL and the time, not the post body Paul: might need an extension for that Brian: what if the URL was not integrity-protected but the body was -- would that be enough? Paul: yes we'd want to sign it all Brian: that's hard Brian: I'm hearing that different people need different things signed Hannes: the bearer signing token is like the null profile Brian: how many optional signing methods do we need? Blaine: I disagree with the assertion that the use cases are not overlapp= ing Hannes: do you think that there's only one signing profile needed? Blaine: I'm hearing that "there's so much fragmentation that we should just use bearer tokens" Brian: the solution I'd like to see is (1) bearer tokens with good operational security characteristics and (2) a second layer that formats a message in a canonical way (e.g., a set of bytes) that would separate it from the details of the HTTP protocol Hannes: (1) it won't help to say in the spec that you shouldn't have infinite lifetimes (2) might want a more flexible signing approach, more like DKIM than SIP signing Justin: if we feel strongly about signing, we need to have clarity on the use cases -- can we have three or four paragraphs on each signing scenario? i.e., what exactly needs to be signed (does the timestamp need to be signed? the nonce? the body? etc.) Agreement to discuss this on the list -- Brian, Blaine, and Paul will post about several scenarios. ## END --------------ms080705080305050309050203 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 hvcNAQkFMQ8XDTEwMDIxODIwMjkyMlowIwYJKoZIhvcNAQkEMRYEFBP3uoPos3i563+YicS3 jMV19pbPMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAjp02YSPX2aJ27cpXk1Hhmvmi0TZOM7BvaVTisFU+ VaFjedhU67SBrZewQNle/FuAXEGrmDPV7Lqs5b4VsQKTo/87pAZu6i2GL4Tt92weQDPrL4mi bqMwT2nSkgMxaACDUJoL7JNfKjCfkeQVUikxTbxMjEqgKH7TPSNCFBN458askACzLZ8wMBQz HAYKmuMoFO/F3cAF9MMZr6EHs9CvyFdiHLXw9uSJf8tN1MXQ+8T2oSFlpcnBo+nFc83v0nOs 56MhIOzWO7aBEN/GC/d95QtVN/oDjzjcMDOiLqY0OOWozlLGfa4RRRzqK3RuL7PV7bF2cr7N 8qiNuGHQRtSJfQAAAAAAAA== --------------ms080705080305050309050203-- From beaton@google.com Thu Feb 18 12:33:53 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E7B3A7F0A for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 12:33:53 -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 FULiwd-hP-hX for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 12:33:52 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8C3163A7B89 for <oauth@ietf.org>; Thu, 18 Feb 2010 12:33:52 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o1IKZZYa021361 for <oauth@ietf.org>; Thu, 18 Feb 2010 12:35:35 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1266525335; bh=ByqWnrDJ1R1/2bCxRjvXi8d07bM=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=LQivImmfS+nE8Q1Ew4d6tmtQr3h7Rtmn9oxNzjVqFkojUYCodURVID3pxcP4ohag0 XCoJoVHi1J66urKuc0J/w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=TYwJdeeQc5XFOe/CCW6eBhLOOufLFaVfRmbRp8s2HdHUXaJBsiELiSaxggJ60Xcd8 mvS1yTlNY/4GT9gnWHRQQ== Received: from vws2 (vws2.prod.google.com [10.241.21.130]) by wpaz17.hot.corp.google.com with ESMTP id o1IKZYbv023377 for <oauth@ietf.org>; Thu, 18 Feb 2010 12:35:35 -0800 Received: by vws2 with SMTP id 2so737285vws.16 for <oauth@ietf.org>; Thu, 18 Feb 2010 12:35:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.121.139 with SMTP id h11mr3425085vcr.147.1266525334165; Thu, 18 Feb 2010 12:35:34 -0800 (PST) Date: Thu, 18 Feb 2010 12:35:34 -0800 Message-ID: <daf5b9571002181235u73fd3b0ar3a8ded512167907a@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] operational security X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 20:33:53 -0000 On the call people wanted me to clarify what I meant when I talked about operational security. In a nutshell, I mean: - what systems and what people have access to long-lived secrets? Keep this to a reasonable level, where reasonable is defined by different use cases. - what systems and what people have access to shorter-lived secrets? Repeat above caveat about reasonable protection. - how are those secrets protected? Repeat above caveat about reasonable protection. - deal with practical considerations of systems that people really build. Issues like latency, scalability, functionality, and complexity impact all of the above. Cheers, Brian From stpeter@stpeter.im Thu Feb 18 12:49:37 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9004C28C0E2 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 12:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GV1YAV3t5K+G for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 12:49:36 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 72A9E3A735F for <oauth@ietf.org>; Thu, 18 Feb 2010 12:49:36 -0800 (PST) Received: from dhcp-64-101-72-201.cisco.com (dhcp-64-101-72-201.cisco.com [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CD78240337 for <oauth@ietf.org>; Thu, 18 Feb 2010 13:51:19 -0700 (MST) Message-ID: <4B7DA846.5090300@stpeter.im> Date: Thu, 18 Feb 2010 13:51:18 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: OAuth WG <oauth@ietf.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020900020305050406090603" Subject: [OAUTH-WG] Fwd: Fwd: Your recording "OAuth WG Virtual Meeting-20100218 1858-1" is available for viewing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 20:49:37 -0000 This is a cryptographically signed message in MIME format. --------------ms020900020305050406090603 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI for those who missed today's meeting or need to write the minutes. -------- Original Message -------- Subject: Fwd: Your recording "OAuth WG Virtual Meeting-20100218 1858-1" is available for viewing Date: Thu, 18 Feb 2010 12:32:08 -0800 From: Alexa Morris <amorris@amsl.com> To: Peter Saint-Andre <stpeter@stpeter.im> Your recording... Begin forwarded message: > *From: *messenger@webex.com <mailto:messenger@webex.com> > *Date: *February 18, 2010 12:30:40 PM PST > *To: *amorris@amsl.com <mailto:amorris@amsl.com> > *Subject: **Your recording "OAuth WG Virtual Meeting-20100218 1858-1" > is available for viewing* > *Reply-To: *messenger@webex.com <mailto:messenger@webex.com> > > IETF Secretariat, > > Your recording is now available on the WebEx service site. Click the > link below to play it: > > https://workgreen.webex.com/workgreen/lsr.php?AT=3Dpb&SP=3DMC&rID=3D396= 2067&rKey=3D89c1736f33e5687f > <https://workgreen.webex.com/workgreen/lsr.php?AT=3Dpb&SP=3DMC&rID=3D39= 62067&rKey=3D89c1736f33e5687f> > > > OAuth WG Virtual Meeting-20100218 1858-1 > Thursday, February 18, 2010 12:58 pm Chicago Time > 1 Hour 28 Minutes > > * You can forward this message to others to allow them to play back > the recording. * > > ------------------------------------- > Additional Options > ------------------------------------- > > To edit recording information and playback control options, click the > link below: > https://workgreen.webex.com/workgreen/editrd.php?rID=3D3962067&SP=3DMC > <https://workgreen.webex.com/workgreen/editrd.php?rID=3D3962067&SP=3DMC= > > > To view more options for this recording, such as downloading, click > the link below: > https://workgreen.webex.com/workgreen/viewrd.php?rID=3D3962067&SP=3DMC > <https://workgreen.webex.com/workgreen/viewrd.php?rID=3D3962067&SP=3DMC= > > > To view all your WebEx Meeting Center recordings, click the link below:= > https://workgreen.webex.com/workgreen/servicerds.php?SP=3DMC > > http://www.webex.com ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com <mailto:amorris@amsl.com> Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com <http://www.amsl.com/> --------------ms020900020305050406090603 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 hvcNAQkFMQ8XDTEwMDIxODIwNTExOFowIwYJKoZIhvcNAQkEMRYEFPexzg0WjvuWBL7ZzYUj ueiryi/SMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAChot7UivlGmkn17L944cdItne4Tvke5WwbK0MuOO wtWMPTTgQb7U6fOoROJWNv0NZdw39C0aA3JxSdlRZRiLktD1rMAvUTayNxJhXVBufSgQF1nU IepICwgprJLarA30IWB4B1R0hlOrbFhSvaaB8H+ulE/DU4WazGe+6lZr2xonx8j9jTzExlz2 KZQT7UL0Nls+iA2OO0xjOk9cSwHW4b0vNmEHpEEf+H6oO5OnXirNAmuq66S7NTmSeac0B6/X h1FJqbZnsLuJE9rAfggmj3ywQiArdAACC4s/dkDPQKi5nZ/9JaC2xpQ+DycFdIjue4cyo2gk cfrbSws5RdVrIQAAAAAAAA== --------------ms020900020305050406090603-- From stpeter@stpeter.im Thu Feb 18 15:41:22 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005CC28C16F; Thu, 18 Feb 2010 15:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 CbwU6LmtDggZ; Thu, 18 Feb 2010 15:41:21 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 429EC28C106; Thu, 18 Feb 2010 15:41:21 -0800 (PST) Received: from dhcp-64-101-72-201.cisco.com (dhcp-64-101-72-201.cisco.com [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3809F40337; Thu, 18 Feb 2010 16:43:05 -0700 (MST) Message-ID: <4B7DD088.5070905@stpeter.im> Date: Thu, 18 Feb 2010 16:43:04 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: OAuth WG <oauth@ietf.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030005080102040906000600" Cc: IESG Secretary <iesg-secretary@ietf.org> Subject: [OAUTH-WG] OAuth interim meeting #4 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 18 Feb 2010 23:41:22 -0000 This is a cryptographically signed message in MIME format. --------------ms030005080102040906000600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On March 4 2010, the OAuth WG will hold its fourth interim conference call leading up to IETF 77. Scheduling details and logistics to follow. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030005080102040906000600 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 hvcNAQkFMQ8XDTEwMDIxODIzNDMwNFowIwYJKoZIhvcNAQkEMRYEFHGMX3cSTg9kO/n4DeWJ FrdJy9IYMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAjBICctg8P0s5B5ifof+kzWE1spJgmUZDD8iz/4W4 uyyl0snJngH3kLWftcVfT0XJD7xWnskYvCb90Mug8oA46NzNWSZPU88UOSSe9BVVc02uwGq4 GbFd1D4nK4hAjdANfD+NdY0SdGn9wSG5Lk0HWf1AUuVyXX2WYGk+E18l2Ca4yu6asKyrCR8W 8JQABZzHK2R2TRHD+TXgrbrPldZYlZwL3xs8iDBFsQwo1ogdnUvFoT8jmNHSAAk+XQ2UwOln 6ixeZjcoxGh8l+pgHMBitskEwaA2IgGIkGvfrQ//pyYdVJowM61VmjIqSGsnWLFQ/HmdOdCU x7Audj2xBvLklQAAAAAAAA== --------------ms030005080102040906000600-- From zachary.zeltsan@alcatel-lucent.com Thu Feb 18 17:14:59 2010 Return-Path: <zachary.zeltsan@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A6728C19B for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 17:14:59 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZNUV9UqHfLB for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 17:14:56 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id C796C28C187 for <oauth@ietf.org>; Thu, 18 Feb 2010 17:14:55 -0800 (PST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o1J1GcYh024678; Thu, 18 Feb 2010 19:16:38 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o1J1AC8m022361; Thu, 18 Feb 2010 19:16:36 -0600 (CST) Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 18 Feb 2010 17:41:39 -0600 From: "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> To: Peter Saint-Andre <stpeter@stpeter.im>, OAuth WG <oauth@ietf.org> Date: Thu, 18 Feb 2010 17:41:37 -0600 Thread-Topic: [OAUTH-WG] good meeting Thread-Index: Acqw2RMItBaS2kL0Q/mWnwvS0ZFAJgAEHHTQ Message-ID: <5710F82C0E73B04FA559560098BF95B124EFF689CB@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4B7DA322.60807@stpeter.im> In-Reply-To: <4B7DA322.60807@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [OAUTH-WG] good meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 01:14:59 -0000 Peter, I think, you have captured the meeting's discussion well.=20 I tried to document the meeting's agreements. Below is my summary of the ma= in points on which, in my opinion, the participants have agreed (or, at lea= st, were close to an agreement). * OAuth should develop specifications that provide security for the impleme= ntations that do not use SSL. There is a need for describing the threats ag= ainst which the protection is provided in such cases. The developers need t= o understand a level of protection. * TLS/SSL cannot address all security issues as it protects only the messag= es that are in transit (i.e., inside the channel). * There is a need to specify what should be signed. The various use cases m= ay have different requirements on that. It is unlikely to find one approach= that will satisfy all scenarios. The different signing profiles may be nee= ded. * People have different use cases that they particularly care about and the= ir favorite security solutions for them. Input on the use cases is invited.= =20 * A description of a use case should explain the case's threat model and wh= at needs to be signed (and why) if the signatures are used. Everybody's corrections of and additions to this summary are welcome. Zachary > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Peter Saint-Andre > Sent: Thursday, February 18, 2010 3:29 PM > To: OAuth WG > Subject: [OAUTH-WG] good meeting >=20 > That was a helpful discussion just now -- thanks to everyone=20 > who participated. Jeff Hodges and I made some *rough* notes=20 > via EtherPad at http://etherpad.com/n2jOXo3WTY and I paste=20 > them below. Real minutes will follow once we've had a chance=20 > to listen to the recording. >=20 > --Peter >=20 > ## >=20 > OAuth interim #3 >=20 > [notes picked up in progress] >=20 > Blaine: cert chains often aren't checked in libraries, but I=20 > like the elegance of no distinction between consumer and=20 > access token -- instead SP decides what token means (James=20 > Manger's proposal to separate tokens from signatures) >=20 > Brian: IETF OAuth work should try to provide security for=20 > those who are not able or willing to use SSL? >=20 > Blaine: I think so >=20 > Brian: how much security can we reasonably provide for those people? > need to be really clear about threat models >=20 > Blaine: e.g. in Twitter originally were concerned about=20 > replay attacks, also concerns about refresh tokens >=20 > Brian: let's explore the Twitter example -- they send cookies=20 > over HTTP but passwords over HTTPS, but when they have issues=20 > it's usually operational issues, weak passwords, etc. >=20 > Hannes: re-use of an eavesdropped token depends on the=20 > application, but how much concern is there about off-path attacks? >=20 > Blaine: I definitely support bearer tokens >=20 > Brian: my point is that it's silly to use OAuth as a=20 > replacement for HTTPS -- what are the threat models that=20 > HTTPS doesn't protect against? >=20 > Hannes: I wouldn't put that as a design constraint -- this is=20 > true for everything, not just OAuth over HTTPS >=20 > JeffH: TLS/SSL doesn't give you message integrity and replay=20 > protection (if you keep the message around) -- secure=20 > channels provide integrity (and encryption) of the channel=20 > but not integrity outside the context of the channel >=20 > Hannes: the same is true of an OAuth token once unbundled, if=20 > you share it with other entities >=20 > JeffH: my point is only that the secure channel doesn't=20 > protect a token outside the channel >=20 > Hannes: distinction between transport layer security and=20 > application layer security (yes, this is a good way to put it) >=20 > Peter: it seems that we don't have a clear threat model >=20 > Blaine: is the threat developers? people are lazy... >=20 > Brian: we have a real problem with operational security=20 > (e.g., credentials kept in plaintext on the service provider)=20 > -- if we have a bearer token model then we won't need to keep=20 > credentials in plaintext >=20 > Hannes: I have a proposal -- we won't be able to have one=20 > approach that satisfies everyone, but we can at least=20 > describe the threat model more clearly and let people choose=20 > which features solve those problems >=20 > Peter: that might make sense >=20 > Hannes: what are people's constraints in implementation and=20 > deployment? >=20 > Brian: all widely deployed security technologies use=20 > transport security or bearer tokens >=20 > Blaine: I somewhat disagree -- percentages might be larger at=20 > a service like Twitter or Flickr than at a broader service=20 > like Google or Yahoo! >=20 > Blaine: my observation is that no one has ever deployed a=20 > bearer token system that works, other than cookies -- I think=20 > that OAuth tokens that can be signed can work quite well >=20 > [scribal note: we will have an audio recording] >=20 > Brian: Microsoft and Kerberos support >=20 > Blaine: not on the web >=20 > Brian: how about OpenID? >=20 > Blaine: but no one uses that >=20 > Brian: how about SSO systems between Yahoo and Flickr? >=20 > Blaine: Flickr people complain about that :) >=20 > Blaine: bearer tokens like Flickr's capability URLs don't=20 > have strong security >=20 > Blaine: do we need [lost] >=20 > JeffH: OAuth as toolkit that gets profiled for different use=20 > cases -- the current split among the documents makes sense --=20 > the Token I-D is the basic toolkit, and the "delegation" I-D=20 > is an example of a particular profile for a (small) range of=20 > use cases. >=20 > Hannes: what is the disagreement at that point? >=20 > [the chair falls down on note-taking] >=20 > Brian: we were trying something that had never been done before >=20 > Blaine: maybe it is that the signatures are too hard, but we=20 > don't really know >=20 > Eve: we have existence proofs of it working, but maybe not=20 > wide interop >=20 > Brian: what is the threat model behind signatures? what are=20 > signatures for? >=20 > Eve: signatures are not there to substitute for channel=20 > security, but provide attestations or other features that=20 > can't be derived from channel security -- might need strong=20 > identity proofing >=20 > Brian: is a bearer token that lasts one minute OK? >=20 > Eve: interested in data origin authentication and fact attestation >=20 > Paul: a bearer token might not show intention, signatures=20 > provide a strong indication >=20 > Brian: not sufficient that bearer token have a short lifetime=20 > -- need to sign the whole message? >=20 > Paul: yes, the body would need to be protected >=20 > Brian: in that case, it seems as if the IETF OAuth draft=20 > doesn't give you what you need because it secures only the=20 > URL and the time, not the post body >=20 > Paul: might need an extension for that >=20 > Brian: what if the URL was not integrity-protected but the=20 > body was -- would that be enough? >=20 > Paul: yes we'd want to sign it all >=20 > Brian: that's hard >=20 > Brian: I'm hearing that different people need different things signed >=20 > Hannes: the bearer signing token is like the null profile >=20 > Brian: how many optional signing methods do we need? >=20 > Blaine: I disagree with the assertion that the use cases are=20 > not overlapping >=20 > Hannes: do you think that there's only one signing profile needed? >=20 > Blaine: I'm hearing that "there's so much fragmentation that=20 > we should just use bearer tokens" >=20 > Brian: the solution I'd like to see is (1) bearer tokens with=20 > good operational security characteristics and (2) a second=20 > layer that formats a message in a canonical way (e.g., a set=20 > of bytes) that would separate it from the details of the HTTP protocol >=20 > Hannes: (1) it won't help to say in the spec that you=20 > shouldn't have infinite lifetimes (2) might want a more=20 > flexible signing approach, more like DKIM than SIP signing >=20 > Justin: if we feel strongly about signing, we need to have=20 > clarity on the use cases -- can we have three or four=20 > paragraphs on each signing scenario? i.e., what exactly needs=20 > to be signed (does the timestamp need to be signed? the=20 > nonce? the body? etc.) >=20 > Agreement to discuss this on the list -- Brian, Blaine, and=20 > Paul will post about several scenarios. >=20 > ## END >=20 >=20 > = From eran@hueniverse.com Thu Feb 18 19:34:48 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C446A3A7F3D for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 19:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 Ccn4hchseWsq for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 19:34:48 -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 EA92E3A7F39 for <oauth@ietf.org>; Thu, 18 Feb 2010 19:34:47 -0800 (PST) Received: (qmail 10365 invoked from network); 19 Feb 2010 03:36:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Feb 2010 03:36:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 18 Feb 2010 20:36:28 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Thu, 18 Feb 2010 20:36:41 -0700 Thread-Topic: Use case for signature w/ asymmetric secret Thread-Index: AcqxFL/tGGY6oOHQRWWxJ/LudYGHPQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343864B47BC4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Ci4= AY0c AoxC ApGC Axop ECiE FDKF GSC7 HoRV I7Ei J6bV KI0L KMGI K0nD LkJw LogO; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {E313CC37-F50F-4770-A1B3-51931C2B7977}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Fri, 19 Feb 2010 03:36:41 GMT; VQBzAGUAIABjAGEAcwBlACAAZgBvAHIAIABzAGkAZwBuAGEAdAB1AHIAZQAgAHcALwAgAGEAcwB5AG0AbQBlAHQAcgBpAGMAIABzAGUAYwByAGUAdAA= x-cr-puzzleid: {E313CC37-F50F-4770-A1B3-51931C2B7977} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Use case for signature w/ asymmetric secret X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 03:34:48 -0000 I have a scenario in which a service provider is offering an API for incomi= ng messages. It is not possible for this service to require pre-registratio= n of clients because of the number of possible clients, or the type of clie= nts. In this scenario, the server is most likely a small site, while the cl= ients are large providers. It is not likely that these large providers will= bother to register with the server. In addition, the server might want to = maintain a white or black list of allowed clients. The way this works is: 1. Client makes a signed request to deliver a message to a user on the serv= er. The request is signed using the client's private key, and includes the = account of the sender which is under the control of the client (i.e. acct:j= oe@example.com). 2. The server receives the message and obtains the host-meta document for e= xample.com using SSL/TLS. The host-meta document either includes the corres= ponding public key for the client (for this purpose) or links to one. 3. The server verifies the request by checking the signature using the publ= ic key. This can be modified to include delegation, in which the client uses a priv= ate-key signed request to obtain a token with the usual flows involving a u= ser. The purpose of this flow is to avoid client registration while still v= erifying the client's identity and potentially agreement to terms of servic= e (assuming they can be represented in a machine readable way in the client= 's host-meta document). This flow uses SSL/TLS for obtaining the host-meta document (which will lik= ely include more steps to verify trust), as well as likely to use SSL/TLS f= or making API calls to maintain message privacy in transit. EHL From eran@hueniverse.com Thu Feb 18 19:58:49 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4E6228C0EC for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 19:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 0-NW1-b3oqA8 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 19:58:48 -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 9EA4E3A7A55 for <oauth@ietf.org>; Thu, 18 Feb 2010 19:58:48 -0800 (PST) Received: (qmail 31697 invoked from network); 19 Feb 2010 04:00:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Feb 2010 04:00:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 18 Feb 2010 21:00:33 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Thu, 18 Feb 2010 21:00:48 -0700 Thread-Topic: WG Survey Thread-Index: AcqwvdIpwql/pJksQI6hDRprwnPDjAAVwKGg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343864B47BC7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 03:58:49 -0000 > 1. Why are you here? What are you trying to solve that is not already > addressed by existing specifications (OAuth 1.0a, WRAP, etc)? I would like to see OAuth 1.0 extended to support more methods for obtainin= g tokens to optimize usability for non-web-based clients. I also want to cl= ean the overall architecture and simplify parts of the spec that were origi= nally designed to work on very limited platforms. I am also concerned about= the security implications of WRAP adoption as currently written.=20 =20 > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point= ? > Something else? Strictly from an editor's perspective, OAuth 1.0a (as documented in the rec= ently approved draft-hammer-oauth RFC) offers the best narrative to build o= n. The document has gone through many revisions and reflects over a year of= work on top of the original OAuth specification. It would be easier to add= the new methods of obtaining a token into OAuth, than to rewrite WRAP to r= each the same level of document maturity. =20 > 3. If we start from draft-hammer-oauth, what needs to change to turn it i= nto > OAuth 2.0? To start with, adding all the new flows in WRAP to make it feature complete= . The authentication section needs to be cleaned up and incorporate a new m= essage format for signing (similar to Brian's proposal), as well as remove = the need to use the client credentials for accessing resources. It also nee= ds to replace PLAINTEXT with a simpler, cleaner bearer token solution that = does not require reading the entire specification to implement. =20 > 4. If we start from draft-hardt-oauth, what needs to change to turn it in= to > OAuth 2.0? The primary issues are similar to the OAuth specification in how parameters= are sent, named, as well as lacking any support for signatures. Ignoring the early stage of the draft, the document needs more clarity in i= ts terminology. It uses an architecture that is not fully explained or spec= ified, leaving too much for the implementer to figure out. For example, WRA= P doesn't directly support the separation of the token issuer from the reso= urce server because it doesn't explain how such a decoupling can be impleme= nted in practice. =20 > 5. Do you think the approach of working first on 'how to use a token' and > then on 'how to get a token' is right? I am not sure anymore. It has not worked so far, and it seems people are no= t motivated to engage this effort because they don't see how all the pieces= come together. It looks like taking one of the two specs (1.0a or WRAP) an= d starting to revise it frequently until it is feature complete is going to= get people more engaged. =20 > 6. Should we go back to working on a single specification? Yes. Same as the previous answer. I am still not sure if we should end up p= ublishing a single specification, but when we are done, we can ask the oppo= site question if the 'how to use a token' section is more useful on its own= . > 7. Do you think the protocol should include a signature-based authenticat= ion > scheme? Yes. I agree that a bearer token over SSL/TLS offers more than an HMAC-based sig= nature over non-secure channel. I personally don't see much value in the HM= AC signature because any token-issuing server will have to support SSL/TLS = for sending tokens in the first place. So the argument that we need to supp= ort servers without SSL/TLS is false (note that draft-hammer-oauth as appro= ved requires SSL/TLS for all plaintext secrets). I don't know enough to say= if the argument that HMAC is cheaper/faster/easier than always using SSL/T= LS is true or not. What I am interested in is support for asymmetric secrets because that's th= e only way I know to avoid the need for client registration, without giving= up completely on client identity verification. But since this requires a s= ignature process, defining an HMAC option becomes just a matter of a few mo= re lines. In other words, if we support an RSA-SHA1-like method, we might a= s well also support HMAC. I posted my use case for this separately. EHL From eran@hueniverse.com Thu Feb 18 20:00:40 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D34E3A8094 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 20:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86Y1vfZSAKiX for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 20:00: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 69A483A8041 for <oauth@ietf.org>; Thu, 18 Feb 2010 20:00:39 -0800 (PST) Received: (qmail 850 invoked from network); 19 Feb 2010 04:02:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Feb 2010 04:02:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 18 Feb 2010 21:02:24 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Brian Eaton <beaton@google.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Thu, 18 Feb 2010 21:02:39 -0700 Thread-Topic: [OAUTH-WG] operational security Thread-Index: Acqw2fF7t2unbZkzTvi4/XrQtZa6cAAPkmGw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343864B47BC9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <daf5b9571002181235u73fd3b0ar3a8ded512167907a@mail.gmail.com> In-Reply-To: <daf5b9571002181235u73fd3b0ar3a8ded512167907a@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] operational security X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 04:00:40 -0000 Can you apply this (without too much detail) to both WRAP and OAuth 1.0a? I= think it would be useful to see how each comply with these goals (which lo= ok pretty important to me). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Thursday, February 18, 2010 12:36 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] operational security >=20 > On the call people wanted me to clarify what I meant when I talked about > operational security. In a nutshell, I mean: >=20 > - what systems and what people have access to long-lived secrets? > Keep this to a reasonable level, where reasonable is defined by differ= ent > use cases. >=20 > - what systems and what people have access to shorter-lived secrets? > Repeat above caveat about reasonable protection. >=20 > - how are those secrets protected? > Repeat above caveat about reasonable protection. >=20 > - deal with practical considerations of systems that people really build. > Issues like latency, scalability, functionality, and complexity impact= all of the > above. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Thu Feb 18 21:49:21 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE993A80C1 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 21:49:21 -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 GpGlxe188A6V for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 21:49:19 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id D86513A80BD for <oauth@ietf.org>; Thu, 18 Feb 2010 21:49:18 -0800 (PST) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o1J5p1QV014017 for <oauth@ietf.org>; Fri, 19 Feb 2010 05:51:02 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1266558662; bh=rjNhWvSCO8TvG+Knd3aBs+0PnUE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=KC459nCrKb3gNYZfx+3DMGKBoNOj3gi/CTGc7b1eqBw4p2iEq99UqGwg2wQpRypGN kwCRvzAHStQCR+nCDYcjw== 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=RbTqAVEnlCYpevi4I0Cun6DnJK7qSyEVlhdKvBWzeRnVKKeNcrMMFdjuA8M9sTzw2 1Gv5kdU0Pk5mcQ6jl39Lw== Received: from vws14 (vws14.prod.google.com [10.241.21.142]) by wpaz1.hot.corp.google.com with ESMTP id o1J5p0Vu026872 for <oauth@ietf.org>; Thu, 18 Feb 2010 21:51:01 -0800 Received: by vws14 with SMTP id 14so1081850vws.27 for <oauth@ietf.org>; Thu, 18 Feb 2010 21:51:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.128.1 with SMTP id i1mr3817437vcs.143.1266558660527; Thu, 18 Feb 2010 21:51:00 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B47BC9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <daf5b9571002181235u73fd3b0ar3a8ded512167907a@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BC9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 18 Feb 2010 21:51:00 -0800 Message-ID: <daf5b9571002182151n773234aaj3137ef23f970c854@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] operational security X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 05:49:21 -0000 On Thu, Feb 18, 2010 at 8:02 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > Can you apply this (without too much detail) to both WRAP and OAuth 1.0a? I think it > would be useful to see how each comply with these goals (which look pretty important to me). In OAuth 1.0a, every system that needs to create or verify signatures needs access to long-lived secrets. This gives implementers a choice: - let all their machines have those secrets, which increases attack surface - add more RPCs (and thus latency and availability headaches) to every request OAuth 1.0a also encourages servers to keep secrets in plaintext, which creates exposure from other directions. There may be some tricks you can do to avoid this, but they are non-trivial. (I'm not even sure they would work, haven't thought them through entirely.) Token revocation in OAuth 1.0a is also tricky, as it forces another database lookup on every request. WRAP doesn't do those things. (Not saying this is the end-all/be-all of security for WRAP or OAuth. Just additional security considerations.) Cheers, Brian From eran@hueniverse.com Thu Feb 18 21:54:19 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7B73A80C2 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 21:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uhr9YyZQNcSM for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 21:54:18 -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 58D4A3A80C1 for <oauth@ietf.org>; Thu, 18 Feb 2010 21:54:18 -0800 (PST) Received: (qmail 2344 invoked from network); 19 Feb 2010 05:56:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Feb 2010 05:56:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 18 Feb 2010 22:56:02 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Brian Eaton <beaton@google.com> Date: Thu, 18 Feb 2010 22:56:18 -0700 Thread-Topic: [OAUTH-WG] operational security Thread-Index: AcqxJ4W2d1ZB5MMqTiSURXpTlLYyiwAAFNkg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343864B47BDC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <daf5b9571002181235u73fd3b0ar3a8ded512167907a@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BC9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9571002182151n773234aaj3137ef23f970c854@mail.gmail.com> In-Reply-To: <daf5b9571002182151n773234aaj3137ef23f970c854@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] operational security X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 05:54:19 -0000 I understand the removal of the client credentials for accessing resources.= That's one less set of credentials accessible by all servers which we alre= ady have consensus. And by not having signatures, there are no secrets to v= erify. But isn't the bearer token itself a sort of plain text secret? I think what this brings up is the need for an HMAC / symmetric secret opti= on because it is not clear what benefits it really offers over bearer token= with SSL/TLS. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Thursday, February 18, 2010 9:51 PM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] operational security >=20 > On Thu, Feb 18, 2010 at 8:02 PM, Eran Hammer-Lahav > <eran@hueniverse.com> wrote: > > Can you apply this (without too much detail) to both WRAP and OAuth > > 1.0a? I think it would be useful to see how each comply with these goal= s > (which look pretty important to me). >=20 > In OAuth 1.0a, every system that needs to create or verify signatures nee= ds > access to long-lived secrets. >=20 > This gives implementers a choice: > - let all their machines have those secrets, which increases attack surfa= ce > - add more RPCs (and thus latency and availability headaches) to every > request >=20 > OAuth 1.0a also encourages servers to keep secrets in plaintext, which > creates exposure from other directions. There may be some tricks you can > do to avoid this, but they are non-trivial. (I'm not even sure they woul= d > work, haven't thought them through entirely.) >=20 > Token revocation in OAuth 1.0a is also tricky, as it forces another datab= ase > lookup on every request. >=20 > WRAP doesn't do those things. >=20 > (Not saying this is the end-all/be-all of security for WRAP or OAuth. > Just additional security considerations.) >=20 > Cheers, > Brian From beaton@google.com Thu Feb 18 21:58:45 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0EC3A80C4 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 21:58:45 -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 FlgGhJYpbUK6 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 21:58:45 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id CF2B23A80C1 for <oauth@ietf.org>; Thu, 18 Feb 2010 21:58:44 -0800 (PST) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o1J60Svg022288 for <oauth@ietf.org>; Fri, 19 Feb 2010 06:00:28 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1266559229; bh=13z9voMMgYXGmAGp9ukkKyEiB4U=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=gLRubYedTwCj3fRPTeDe1DC7FENpdGizmSNnhEzWOY3/PYTSwB0/9O2racfE1Y6Hs wTUjy8iQ9wvrvZru3tofw== 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=iGwQNXXOEcndEPxsUage1AB5SF/EtAZMN2FlX1oiRyQPgYjs21RgOVUXwpESEAbrP v/MqJJjCb22Ci+ZQzGUlg== Received: from vws6 (vws6.prod.google.com [10.241.21.134]) by kpbe12.cbf.corp.google.com with ESMTP id o1J60RvW009408 for <oauth@ietf.org>; Thu, 18 Feb 2010 22:00:27 -0800 Received: by vws6 with SMTP id 6so876675vws.11 for <oauth@ietf.org>; Thu, 18 Feb 2010 22:00:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.48.22 with SMTP id p22mr7165719vcf.159.1266559225404; Thu, 18 Feb 2010 22:00:25 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 18 Feb 2010 22:00:25 -0800 Message-ID: <daf5b9571002182200o20e2e685g481870041c5c8dd4@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 05:58:46 -0000 On Thu, Feb 18, 2010 at 9:14 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > A few questions we should answer before moving forward. Considering *your* use cases and reasons for being here: > > 1. Why are you here? What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)? WRAP solves almost all of them. I see a need for passing signed claims about identity around, and I don't think SWT or SAML are good choices for that. I don't think the signed identity claims are necessary in the core OAuth spec, they are an advanced use case that most OAuth implementers (client and server) should completely ignore. > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? Something else? WRAP. > 5. Do you think the approach of working first on 'how to use a token' and then on 'how to get a token' is right? I think "how to use a token" should be about two lines. =) > 7. Do you think the protocol should include a signature-based authentication scheme? See above about signed claims about identity. From brent@facebook.com Thu Feb 18 22:00:56 2010 Return-Path: <brent@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA6E28C143 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 22:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 pbNVcUrNE4S1 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 22:00:56 -0800 (PST) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 0D5BB3A80C5 for <oauth@ietf.org>; Thu, 18 Feb 2010 22:00:56 -0800 (PST) Received: from mail.thefacebook.com ([192.168.18.104]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o1J62ArB029930 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Feb 2010 22:02:10 -0800 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Thu, 18 Feb 2010 22:02:38 -0800 From: Brent Goldman <brent@facebook.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Date: Thu, 18 Feb 2010 22:02:34 -0800 Thread-Topic: [OAUTH-WG] WG Survey Thread-Index: AcqxKSLtJXx3PuBvQ7mJ2esmfdAxCA== Message-ID: <EF51377B-5593-4EAE-9E0C-2F39B8FDED6B@facebook.com> References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-02-19_06:2010-02-06, 2010-02-19, 2010-02-19 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 06:00:57 -0000 On Feb 18, 2010, at 9:14 AM, Eran Hammer-Lahav wrote: > A few questions we should answer before moving forward. Considering *your= * use cases and reasons for being here: >=20 > 1. Why are you here? What are you trying to solve that is not already add= ressed by existing specifications (OAuth 1.0a, WRAP, etc)? I'm here because I believe that openness can make the internet a better pla= ce. In a perfect world, an app developer wouldn't have to write code for ea= ch new service provider; everything would just work. More concretely, I'm h= ere because I want to help develop OAuth into something suitable not only f= or the average-sized site, but suitable even for a site as large and compli= cated as Facebook to adopt as its main authorization protocol. The problems with OAuth 1.0a are that the flow is too complicated, the prot= ocol is non-performant (specifically, too many roundtrips), and it doesn't = support non-website use cases such as desktop or mobile as effectively as o= ther protocols. >=20 > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point= ? Something else? By focusing on actual use cases, I believe WRAP has more potential as a sta= rting point. However, OAuth 1.0a is more mature. Either would be fine as a = starting point. >=20 > 5. Do you think the approach of working first on 'how to use a token' and= then on 'how to get a token' is right? Yes. >=20 > 6. Should we go back to working on a single specification? I'm not sure if working on a single specification is the right answer (e.g.= , we might want one specification for obtaining tokens and another one for = how to use them), but I believe we should unify efforts on a set of interop= erable standards instead of working on competing ones. >=20 > 7. Do you think the protocol should include a signature-based authenticat= ion scheme? Yes. From beaton@google.com Thu Feb 18 22:07:29 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258C428C143 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 22:07:29 -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 7jBzFE-3CjV6 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 22:07:27 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 1ACCD3A80C9 for <oauth@ietf.org>; Thu, 18 Feb 2010 22:07:26 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o1J69AP6015906 for <oauth@ietf.org>; Fri, 19 Feb 2010 06:09:11 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1266559751; bh=S7sA71Z8cM/l6ZJEl4Un052WWag=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=c4tyxSNELevzgk+8xzssHB79bclSslIFeIy3aU9GDv6WzlaHNJawIpx7eDMmbyN2o 8l8bL2hfG3ZoQdazGJxVA== 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=JyZr0K7RiSYDHghhWeAfyBVb3unjaMxzHqtdvhIYWzrRq3JIkzOitcxvgdfn4w9uf 8qNZO3PlgNfOICDXBkPnA== Received: from vws2 (vws2.prod.google.com [10.241.21.130]) by kpbe14.cbf.corp.google.com with ESMTP id o1J699EO016586 for <oauth@ietf.org>; Thu, 18 Feb 2010 22:09:09 -0800 Received: by vws2 with SMTP id 2so872451vws.30 for <oauth@ietf.org>; Thu, 18 Feb 2010 22:09:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.48.22 with SMTP id p22mr7170970vcf.159.1266559749101; Thu, 18 Feb 2010 22:09:09 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B47BDC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <daf5b9571002181235u73fd3b0ar3a8ded512167907a@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BC9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9571002182151n773234aaj3137ef23f970c854@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BDC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 18 Feb 2010 22:09:08 -0800 Message-ID: <daf5b9571002182209v42a9942fyd3caed7da20a9d37@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] operational security X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 06:07:31 -0000 On Thu, Feb 18, 2010 at 9:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > But isn't the bearer token itself a sort of plain text secret? Yes, it is. The WRAP access token is short-lived, which mitigates some of the risks. Also note that servers do not need to store access tokens at all. The WRAP refresh token is long-lived, but it does not need to be stored in plain-text on the server. You don't end up creating massive databases of credentials server-side. (Clients that hold lots of refresh tokens still need them in plain text, unfortunately.) The WRAP refresh token only needs to be accessible to a limited number of systems. So you can use that to improve the client-side security. There are WRAP profiles that leverage existing trust relationships to eliminate the need for refresh tokens entirely. Cheers, Brian From recordond@gmail.com Thu Feb 18 22:23:42 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E1C28C1D9 for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 22:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.275, 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 EpsZs0VNevpm for <oauth@core3.amsl.com>; Thu, 18 Feb 2010 22:23:35 -0800 (PST) Received: from mail-iw0-f178.google.com (mail-iw0-f178.google.com [209.85.223.178]) by core3.amsl.com (Postfix) with ESMTP id F2E903A7721 for <oauth@ietf.org>; Thu, 18 Feb 2010 22:23:33 -0800 (PST) Received: by iwn8 with SMTP id 8so622663iwn.17 for <oauth@ietf.org>; Thu, 18 Feb 2010 22:24:38 -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=JgZViGkddq/SG/vpMMA0QUUP85HlgIhHxdlKjzrNay4=; b=VuwN5IXh9bc118CqWttDEuqN4m8OGgLdFuCv00Tzekuy/TbOdVkX4+5TqGdfQpHAEb aGM+0W1awS5VuEQ0MSgEq4TJs2TYzNplgF/vpmB9qGEwDVDYOHzMu7wAGo1Z/gSkE3Eu jAwthOq0qPkabcPY5E/5z1L8QAzaoCuyi30Pc= 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=TL6RgMSJehBxkAawDv25qHgI3sFjxmfQ1lp36aUry9X7uOIq5r80QeJM2tSueLpxEA 5LbCxDK7C5UhL/ZQr/RttYyjsbRUVDfPVdBprcO1DyybKWe7/zRITakcaYMZtoINZMha BwML64nC42udszyZtGszo/h3bnNl+/hBUorTk= MIME-Version: 1.0 Received: by 10.231.160.205 with SMTP id o13mr1380358ibx.13.1266560677004; Thu, 18 Feb 2010 22:24:37 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 18 Feb 2010 22:24:36 -0800 Message-ID: <fd6741651002182224g39f6c453u6dfc27396e856bd8@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: multipart/alternative; boundary=00504502f6813d46d2047fee2348 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 06:23:42 -0000 --00504502f6813d46d2047fee2348 Content-Type: text/plain; charset=ISO-8859-1 Glad to see this thread. :) On Thu, Feb 18, 2010 at 9:14 AM, Eran Hammer-Lahav <eran@hueniverse.com>wrote: > A few questions we should answer before moving forward. Considering *your* > use cases and reasons for being here: > > 1. Why are you here? What are you trying to solve that is not already > addressed by existing specifications (OAuth 1.0a, WRAP, etc)? > OAuth has been insanely successful the past few years in terms of almost eliminating new password-based APIs. That said, developers both large and small have found it to be complex and not as simple to implement as possible. We now have the opportunity to develop OAuth 2.0 based on what we've learned and new methodologies in APIs that weren't prevalent two years ago. Overall, I want to modernize OAuth so that it's not just "FooCo supports OAuth" but rather "FooCo has a million developers using OAuth". > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? > Something else? > I think that WRAP has a lot of the right ideas (multiple ways to get tokens and relies on SSL), but ultimately wasn't created in an open process and was shaped by small number of implementors. I also think that there are lessons to be learned from OAuth 1.0 which haven't made their way into the current WRAP draft. If I were to write a draft, I'd start with an empty document and merge in appropriate sections from draft-hammer-oauth, draft-hammer-http-token-auth, and WRAP. I'd then probably rewrite half of the text as it gets merged together. 3. If we start from draft-hammer-oauth, what needs to change to turn it into > OAuth 2.0? > Eran had a good answer here. 4. If we start from draft-hardt-oauth, what needs to change to turn it into > OAuth 2.0? > Eran had a good answer here. > 5. Do you think the approach of working first on 'how to use a token' and > then on 'how to get a token' is right? > I think it's hard to compare text from this split approach to the WRAP draft spec. > 6. Should we go back to working on a single specification? > Yes. We can split it apart later, but should optimize for a single easy to understand document. 7. Do you think the protocol should include a signature-based authentication > scheme? > Yes. See http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html. > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00504502f6813d46d2047fee2348 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Glad to see this thread. :)<br><br><div class=3D"gmail_quote">On Thu, Feb 1= 8, 2010 at 9:14 AM, Eran Hammer-Lahav <span dir=3D"ltr"><<a href=3D"mail= to:eran@hueniverse.com">eran@hueniverse.com</a>></span> wrote:<br><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex;"> A few questions we should answer before moving forward. Considering *your* = use cases and reasons for being here:<br> <br> 1. Why are you here? What are you trying to solve that is not already addre= ssed by existing specifications (OAuth 1.0a, WRAP, etc)?<br></blockquote><d= iv><br></div><div>OAuth has been insanely successful the past few years in = terms of almost eliminating new password-based APIs. =A0That said, develope= rs both large and small have found it to be complex and not as simple to im= plement as possible. =A0We now have the=A0opportunity=A0to develop OAuth 2.= 0 based on what we've learned and new methodologies in APIs that weren&= #39;t prevalent=A0two years ago. =A0Overall, I want to modernize OAuth so t= hat it's not just "FooCo supports OAuth" but rather "Foo= Co has a million developers using OAuth".</div> <div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2. Should the = WG start by taking WRAP or OAuth 1.0a as its starting point? Something else= ?<br> </blockquote><div><br></div><div>I think that WRAP has a lot of the right i= deas (multiple ways to get tokens and relies on SSL), but ultimately wasn&#= 39;t created in an open process and was shaped by small number of implement= ors. =A0I also think that there are lessons to be learned from OAuth 1.0 wh= ich haven't made their way into the current WRAP draft.</div> <div><br></div><div>If I were to write a draft, I'd start with an empty= document and merge in appropriate sections from draft-hammer-oauth,=A0<spa= n class=3D"Apple-style-span" style=3D"font-family: arial, sans-serif; font-= size: 13px; border-collapse: collapse; ">draft-hammer-http-token-auth, and = WRAP. =A0I'd then=A0probably=A0rewrite half of the text as it gets merg= ed together.</span></div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">3. If we star= t from draft-hammer-oauth, what needs to change to turn it into OAuth 2.0?<= br> </blockquote><div><br></div><div>Eran had a good answer here.</div><div>=A0= </div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">4. If we start from dr= aft-hardt-oauth, what needs to change to turn it into OAuth 2.0?<br> </blockquote><div><br></div><div><div>Eran had a good answer here.</div><di= v><br></div></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 5. Do you think the approach of working first on 'how to use a token= 9; and then on 'how to get a token' is right?<br></blockquote><div>= <br></div><div>I think it's hard to compare text from this split approa= ch to the WRAP draft spec.</div> <div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 6. Should we go back to working on a single specification?<br></blockquote>= <div><br></div><div>Yes. =A0We can split it apart later, but should optimiz= e for a single easy to understand document.</div><div>=A0</div><div><br></d= iv> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">7. Do you think the protocol should include= a signature-based authentication scheme?<br></blockquote><div><br></div><d= iv> Yes. =A0See=A0<a href=3D"http://www.ietf.org/mail-archive/web/oauth/current= /msg01049.html">http://www.ietf.org/mail-archive/web/oauth/current/msg01049= .html</a>.</div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quo= te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;= "> <font color=3D"#888888">EHL<br> </font><div><div></div><div class=3D"h5">__________________________________= _____________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </div></div></blockquote></div><br> --00504502f6813d46d2047fee2348-- From torsten@lodderstedt.net Fri Feb 19 00:00:18 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF0228C18C for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 00:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKFfQtwIXKqZ for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 00:00:17 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id 2FF6528C14B for <oauth@ietf.org>; Fri, 19 Feb 2010 00:00:16 -0800 (PST) Received: from tmo-101-254.customers.d1-online.com ([80.187.101.254] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1NiNoH-0006f2-2o; Fri, 19 Feb 2010 09:02:01 +0100 Message-ID: <4B7E4572.50307@lodderstedt.net> Date: Fri, 19 Feb 2010 09:01:54 +0100 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Eran Hammer-Lahav <eran@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E72343864B47BC4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B47BC4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Use case for signature w/ asymmetric secret X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 08:00:18 -0000 Hi Eran, can you please give more details on how the client identity shall be verified and what information are presented to the user in the delegation process. thanks in advance, Torsten. > I have a scenario in which a service provider is offering an API for incoming messages. It is not possible for this service to require pre-registration of clients because of the number of possible clients, or the type of clients. In this scenario, the server is most likely a small site, while the clients are large providers. It is not likely that these large providers will bother to register with the server. In addition, the server might want to maintain a white or black list of allowed clients. > > The way this works is: > > 1. Client makes a signed request to deliver a message to a user on the server. The request is signed using the client's private key, and includes the account of the sender which is under the control of the client (i.e. acct:joe@example.com). > 2. The server receives the message and obtains the host-meta document for example.com using SSL/TLS. The host-meta document either includes the corresponding public key for the client (for this purpose) or links to one. > 3. The server verifies the request by checking the signature using the public key. > > This can be modified to include delegation, in which the client uses a private-key signed request to obtain a token with the usual flows involving a user. The purpose of this flow is to avoid client registration while still verifying the client's identity and potentially agreement to terms of service (assuming they can be represented in a machine readable way in the client's host-meta document). > > This flow uses SSL/TLS for obtaining the host-meta document (which will likely include more steps to verify trust), as well as likely to use SSL/TLS for making API calls to maintain message privacy in transit. > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Fri Feb 19 00:08:51 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98143A80E5 for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 00:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fmWI8a2gNIm for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 00:08:50 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id B50A63A7851 for <oauth@ietf.org>; Fri, 19 Feb 2010 00:08:50 -0800 (PST) Received: from tmo-101-254.customers.d1-online.com ([80.187.101.254] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1NiNwZ-0007YQ-7u; Fri, 19 Feb 2010 09:10:35 +0100 Message-ID: <4B7E4779.7030804@lodderstedt.net> Date: Fri, 19 Feb 2010 09:10:33 +0100 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Brian Eaton <beaton@google.com> References: <daf5b9571002181235u73fd3b0ar3a8ded512167907a@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BC9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9571002182151n773234aaj3137ef23f970c854@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BDC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9571002182209v42a9942fyd3caed7da20a9d37@mail.gmail.com> In-Reply-To: <daf5b9571002182209v42a9942fyd3caed7da20a9d37@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] operational security X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 08:08:51 -0000 Hi Brian, > On Thu, Feb 18, 2010 at 9:56 PM, Eran Hammer-Lahav<eran@hueniverse.com> wrote: > >> But isn't the bearer token itself a sort of plain text secret? >> > Yes, it is. > > The WRAP access token is short-lived, which mitigates some of the > risks. Also note that servers do not need to store access tokens at > all. > > The WRAP refresh token is long-lived, but it does not need to be > stored in plain-text on the server. You don't end up creating massive > databases of credentials server-side. (Clients that hold lots of > refresh tokens still need them in plain text, unfortunately.) > > The WRAP refresh token only needs to be accessible to a limited number > of systems. So you can use that to improve the client-side security. > > There are WRAP profiles that leverage existing trust relationships to > eliminate the need for refresh tokens entirely. > Is this the point where OpenID and OAuth converge? regards, Torsten. > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Fri Feb 19 06:33:58 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87FD3A7E93 for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 06:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dU22x1M3mT4 for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 06:33:58 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) by core3.amsl.com (Postfix) with ESMTP id E88233A6A3D for <oauth@ietf.org>; Fri, 19 Feb 2010 06:33:57 -0800 (PST) Received: from tmo-101-254.customers.d1-online.com ([80.187.101.254] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1NiTxF-00062Q-0p; Fri, 19 Feb 2010 15:35:41 +0100 Message-ID: <4B7EA1AD.9020003@lodderstedt.net> Date: Fri, 19 Feb 2010 15:35:25 +0100 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <daf5b9571002181235u73fd3b0ar3a8ded512167907a@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BC9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9571002182151n773234aaj3137ef23f970c854@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BDC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9571002182209v42a9942fyd3caed7da20a9d37@mail.gmail.com> <4B7E4779.7030804@lodderstedt.net> <4B7E97D8.6050107@alcatel-lucent.com> In-Reply-To: <4B7E97D8.6050107@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] operational security X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 14:33:58 -0000 .... >>> >>> The WRAP refresh token only needs to be accessible to a limited number >>> of systems. So you can use that to improve the client-side security. >>> >>> There are WRAP profiles that leverage existing trust relationships to >>> eliminate the need for refresh tokens entirely. >> Is this the point where OpenID and OAuth converge? >> > > I am completely missing the relation to OpenID here... What is it? > Suppose a webite wants to (1) login users interactively and (2) access web services on behalf of those users which are secured by tokens. From my point of view, one could integrate token issuance into the login process. So the application might perform login via Openid and request access tokens as additional results of the login process from the identity provider. Does this make sense? regards, Torsten. From igor.faynberg@alcatel-lucent.com Fri Feb 19 05:51:49 2010 Return-Path: <igor.faynberg@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA26B3A8164 for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 05:51:49 -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 ruWlYPPB+2+h for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 05:51:49 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id EF6D43A687C for <oauth@ietf.org>; Fri, 19 Feb 2010 05:51:48 -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 o1JDrUAT015294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Feb 2010 07:53:31 -0600 (CST) Received: from [135.244.0.49] (faynberg.lra.lucent.com [135.244.0.49]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o1JDrTO1008973; Fri, 19 Feb 2010 07:53:30 -0600 (CST) Message-ID: <4B7E97D8.6050107@alcatel-lucent.com> Date: Fri, 19 Feb 2010 08:53:28 -0500 From: Igor Faynberg <igor.faynberg@alcatel-lucent.com> Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Torsten Lodderstedt <torsten@lodderstedt.net> References: <daf5b9571002181235u73fd3b0ar3a8ded512167907a@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BC9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9571002182151n773234aaj3137ef23f970c854@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BDC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9571002182209v42a9942fyd3caed7da20a9d37@mail.gmail.com> <4B7E4779.7030804@lodderstedt.net> In-Reply-To: <4B7E4779.7030804@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Mailman-Approved-At: Fri, 19 Feb 2010 06:53:24 -0800 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] operational security X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 13:51:50 -0000 Torsten Lodderstedt wrote: > .... >> >> The WRAP refresh token only needs to be accessible to a limited number >> of systems. So you can use that to improve the client-side security. >> >> There are WRAP profiles that leverage existing trust relationships to >> eliminate the need for refresh tokens entirely. >> > Is this the point where OpenID and OAuth converge? > I am completely missing the relation to OpenID here... What is it? Igor From chris.messina@gmail.com Fri Feb 19 07:58:18 2010 Return-Path: <chris.messina@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3613A817E for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 07:58:18 -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 U6WMaYC903w5 for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 07:58:09 -0800 (PST) Received: from mail-qy0-f177.google.com (mail-qy0-f177.google.com [209.85.221.177]) by core3.amsl.com (Postfix) with ESMTP id C13DA3A7DE4 for <oauth@ietf.org>; Fri, 19 Feb 2010 07:58:08 -0800 (PST) Received: by qyk8 with SMTP id 8so106814qyk.14 for <oauth@ietf.org>; Fri, 19 Feb 2010 07:59:52 -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=8ySnK3bGhJqmP9de5mvx/MjkbeuML2Bvim1wSDT9Avs=; b=Vd9O2DfN8qv43BJD+T9cizqsIbngZ4ZhxmxIyGjIfIpZZBaLlfNMAxpFKXf2dXzQSM RlC3RvNwKEmDlXpAVrfNELOs+ItUmg6P7jzcf0ruNQE0LrIgLZnrGnVCW3Yr9kwTFUJF D6M5Yx/fDc6v3eybSfnTOyKoJchhdpYO83IhA= 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=qN/Eplw+y58aj9SnpighH0lHh08KjP37cYZt4/TcnIJ/npuRWyssFLqgrMjmH/MOnW uZ76Z5J1NBaJWrtVk30S2AVmAqHmZ3vFZymQ5/3pX6r8VTXCcOS+ACNfDL/3fyilt+Vq IsG6bYIuWx1m4G0B4pU4GbnOQEHXuHcTSMFMM= Received: by 10.224.109.1 with SMTP id h1mr2457983qap.131.1266595192568; Fri, 19 Feb 2010 07:59:52 -0800 (PST) Received: from ?67.218.107.201? ([67.218.107.201]) by mx.google.com with ESMTPS id 23sm160924qyk.3.2010.02.19.07.59.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Feb 2010 07:59:51 -0800 (PST) References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <fd6741651002182224g39f6c453u6dfc27396e856bd8@mail.gmail.com> Message-Id: <45E4EADB-D1C9-40C7-AA24-F1E0A1212F2C@gmail.com> From: Chris Messina <chris.messina@gmail.com> To: David Recordon <recordond@gmail.com> In-Reply-To: <fd6741651002182224g39f6c453u6dfc27396e856bd8@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2-525171259 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 19 Feb 2010 07:59:33 -0800 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 15:58:18 -0000 --Apple-Mail-2-525171259 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit +1 to what Dave said. I almost wrote the same thing (though admittedly with less technical insight). To me, the needs are: 1. Consolidate the needs for OAuth 2.0 2. Merge the documents as necessary; rinse, wash, repeat until we have a satisfactorially readable and comprehensible document (2.0 should be one of Eran's "editor's drafts"). 3. We need more flow diagrams methinks (I'll volunteer to prettify any ASCII drawings). 4. This document needs to tell the marketplace that OAuth is: evolving, stable, secure, and getting easier to implement in more diverse (and realistic) environments. And that 2.0 isn't abandoning 1.0a, but improving on that foundation to solve the problems that have become clearer to us in the past several years since 1.0 was released. 5. I would volunteer to write a context-setting document to help people who aren't active in these lists understand the goals, context, and purpose behind revving OAuth. Managing the transition and outreach for the next rev of OAuth will be nearly as important as getting to a final document in my mind. Chris Sent from my iPhone 2G On Feb 18, 2010, at 10:24 PM, David Recordon <recordond@gmail.com> wrote: > Glad to see this thread. :) > > On Thu, Feb 18, 2010 at 9:14 AM, Eran Hammer-Lahav <eran@hueniverse.com > > wrote: > A few questions we should answer before moving forward. Considering > *your* use cases and reasons for being here: > > 1. Why are you here? What are you trying to solve that is not > already addressed by existing specifications (OAuth 1.0a, WRAP, etc)? > > OAuth has been insanely successful the past few years in terms of > almost eliminating new password-based APIs. That said, developers > both large and small have found it to be complex and not as simple > to implement as possible. We now have the opportunity to develop > OAuth 2.0 based on what we've learned and new methodologies in APIs > that weren't prevalent two years ago. Overall, I want to modernize > OAuth so that it's not just "FooCo supports OAuth" but rather "FooCo > has a million developers using OAuth". > > > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting > point? Something else? > > I think that WRAP has a lot of the right ideas (multiple ways to get > tokens and relies on SSL), but ultimately wasn't created in an open > process and was shaped by small number of implementors. I also > think that there are lessons to be learned from OAuth 1.0 which > haven't made their way into the current WRAP draft. > > If I were to write a draft, I'd start with an empty document and > merge in appropriate sections from draft-hammer-oauth, draft-hammer- > http-token-auth, and WRAP. I'd then probably rewrite half of the > text as it gets merged together. > > > 3. If we start from draft-hammer-oauth, what needs to change to turn > it into OAuth 2.0? > > Eran had a good answer here. > > > 4. If we start from draft-hardt-oauth, what needs to change to turn > it into OAuth 2.0? > > Eran had a good answer here. > > > 5. Do you think the approach of working first on 'how to use a > token' and then on 'how to get a token' is right? > > I think it's hard to compare text from this split approach to the > WRAP draft spec. > > > 6. Should we go back to working on a single specification? > > Yes. We can split it apart later, but should optimize for a single > easy to understand document. > > > 7. Do you think the protocol should include a signature-based > authentication scheme? > > Yes. See http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html > . > > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2-525171259 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body bgcolor=3D"#FFFFFF"><div>+1 to what Dave = said. </div><div><br></div><div>I almost wrote the same thing = (though admittedly with less technical = insight).</div><div><br></div><div>To me, the needs = are:</div><div><br></div><div>1. Consolidate the needs for OAuth = 2.0</div><div>2. Merge the documents as necessary; rinse, wash, repeat = until we have a satisfactorially readable and comprehensible document = (2.0 should be one of Eran's "editor's drafts").</div><div>3. We need = more flow diagrams methinks (I'll volunteer to prettify any ASCII = drawings).</div><div>4. This document needs to tell the marketplace that = OAuth is: evolving, stable, secure, and getting easier to implement in = more diverse (and realistic) environments. And that 2.0 isn't abandoning = 1.0a, but improving on that foundation to solve the problems that have = become clearer to us in the past several years since 1.0 was = released. </div><div>5. I would volunteer to write a = context-setting document to help people who aren't active in these lists = understand the goals, context, and purpose behind revving = OAuth. </div><div><br></div><div>Managing the transition and = outreach for the next rev of OAuth will be nearly as important as = getting to a final document in my = mind. </div><div><br></div><div>Chris</div><div><br>Sent from my = iPhone 2G</div><div><br>On Feb 18, 2010, at 10:24 PM, David Recordon = <<a href=3D"mailto:recordond@gmail.com">recordond@gmail.com</a>> = wrote:<br><br></div><div></div><blockquote type=3D"cite"><div>Glad to = see this thread. :)<br><br><div class=3D"gmail_quote">On Thu, Feb 18, = 2010 at 9:14 AM, Eran Hammer-Lahav <span dir=3D"ltr"><<a = href=3D"mailto:eran@hueniverse.com"><a = href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com</a></a>></span>= wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex;"> A few questions we should answer before moving forward. Considering = *your* use cases and reasons for being here:<br> <br> 1. Why are you here? What are you trying to solve that is not already = addressed by existing specifications (OAuth 1.0a, WRAP, = etc)?<br></blockquote><div><br></div><div>OAuth has been insanely = successful the past few years in terms of almost eliminating new = password-based APIs.  That said, developers both large and small = have found it to be complex and not as simple to implement as possible. =  We now have the opportunity to develop OAuth 2.0 based = on what we've learned and new methodologies in APIs that weren't = prevalent two years ago.  Overall, I want to modernize OAuth = so that it's not just "FooCo supports OAuth" but rather "FooCo has a = million developers using OAuth".</div> <div><br></div><div> </div><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex;">2. Should the WG start by taking WRAP or OAuth = 1.0a as its starting point? Something else?<br> </blockquote><div><br></div><div>I think that WRAP has a lot of the = right ideas (multiple ways to get tokens and relies on SSL), but = ultimately wasn't created in an open process and was shaped by small = number of implementors.  I also think that there are lessons to be = learned from OAuth 1.0 which haven't made their way into the current = WRAP draft.</div> <div><br></div><div>If I were to write a draft, I'd start with an empty = document and merge in appropriate sections from = draft-hammer-oauth, <span class=3D"Apple-style-span" = style=3D"font-family: arial, sans-serif; font-size: 13px; = border-collapse: collapse; ">draft-hammer-http-token-auth, and WRAP. =  I'd then probably rewrite half of the text as it gets = merged together.</span></div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex;">3. If we start from draft-hammer-oauth, what = needs to change to turn it into OAuth 2.0?<br> </blockquote><div><br></div><div>Eran had a good answer = here.</div><div> </div><div><br></div><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex;">4. If we start from draft-hardt-oauth, what = needs to change to turn it into OAuth 2.0?<br> </blockquote><div><br></div><div><div>Eran had a good answer = here.</div><div><br></div></div><div> </div><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex;"> 5. Do you think the approach of working first on 'how to use a token' = and then on 'how to get a token' is = right?<br></blockquote><div><br></div><div>I think it's hard to compare = text from this split approach to the WRAP draft spec.</div> <div><br></div><div> </div><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex;"> 6. Should we go back to working on a single = specification?<br></blockquote><div><br></div><div>Yes.  We can = split it apart later, but should optimize for a single easy to = understand document.</div><div> </div><div><br></div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex;">7. Do you think the = protocol should include a signature-based authentication = scheme?<br></blockquote><div><br></div><div> Yes.  See <a = href=3D"http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html">= <a = href=3D"http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html">= http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html</a></a>.<= /div><div><br></div><div> </div><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex;"> <font color=3D"#888888">EHL<br> </font><div><div></div><div = class=3D"h5">_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org"><a = href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a></a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" = target=3D"_blank"><a = href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/= mailman/listinfo/oauth</a></a><br> </div></div></blockquote></div><br> </div></blockquote><blockquote = type=3D"cite"><div><span>_______________________________________________</= span><br><span>OAuth mailing list</span><br><span><a = href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a></span><br><span><a = href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/= mailman/listinfo/oauth</a></span><br></div></blockquote></body></html>= --Apple-Mail-2-525171259-- From jpanzer@google.com Fri Feb 19 10:04:21 2010 Return-Path: <jpanzer@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6433828C215 for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 10:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.816 X-Spam-Level: X-Spam-Status: No, score=-104.816 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x7=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ8XPxl-cpJk for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 10:04:19 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id A60EC3A7F78 for <oauth@ietf.org>; Fri, 19 Feb 2010 10:04:18 -0800 (PST) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o1JI63Th012465 for <oauth@ietf.org>; Fri, 19 Feb 2010 18:06:04 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1266602764; bh=IrsOLpTxolkwd1JZMzGAAUmVwQY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=LzeLUO4XlVlqrlr9dkRT6pbw/F2lSIXDrtfmr7HzNIPx4q2OCNGgkInI0JPK8c0lR YaIdkE64KUmih5pSK/SiQ== 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=u57VG3QA8YYowWI2EeGlQ/jNMGdO27s/g6MEF/Fhf7AofC616rweg5A2tTzJWSP40 YSka+3tdh+YxWM96xVZhg== Received: from pxi14 (pxi14.prod.google.com [10.243.27.14]) by kpbe12.cbf.corp.google.com with ESMTP id o1JI54Ui005978 for <oauth@ietf.org>; Fri, 19 Feb 2010 10:06:02 -0800 Received: by pxi14 with SMTP id 14so183394pxi.15 for <oauth@ietf.org>; Fri, 19 Feb 2010 10:06:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.58.9 with SMTP id g9mr123576rva.87.1266602762191; Fri, 19 Feb 2010 10:06:02 -0800 (PST) In-Reply-To: <C786ED62.1C7AF%lshepard@facebook.com> References: <C786ED62.1C7AF%lshepard@facebook.com> From: John Panzer <jpanzer@google.com> Date: Fri, 19 Feb 2010 10:05:42 -0800 Message-ID: <cb5f7a381002191005q79bb3d3ag371a9b907192df23@mail.gmail.com> To: Luke Shepard <lshepard@facebook.com> Content-Type: multipart/alternative; boundary=001636b2ad25b64471047ff7efca X-System-Of-Record: true Cc: "oauth@ietf.org" <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 <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 18:04:21 -0000 --001636b2ad25b64471047ff7efca Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Luke, Thanks again for writing all of this up in such a cogent way. Some comment= s inline: On Thu, Jan 28, 2010 at 7:29 AM, Luke Shepard <lshepard@facebook.com> wrote= : > In the discussions around the OAuth WRAP spec, one of the questions ofte= n > asked is, =93why use SSL exclusively?=94 Several of us have done a lot of > thinking on it and I wanted to articulate my understanding of the pros an= d > cons of the approach for discussion. The use case I primarily have in min= d > 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, mobile). > > Overall, I think that the simplicity of using SSL outweighs all the > associated 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=92s overwhelmingly simpler for developers. > I=92ve implemented OpenID and OAuth, and I=92ve 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=92s not that SSL is a simpler encryption protocol than OAuth (it=92s n= ot) > but rather that commonly available tools almost universally support it = =96 > every major web browser, as well as most libraries for making HTTP reques= ts > (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 a= nd > verifying signatures. For example, the OpenID PHP library imports several > BigMath modules and encryption schemes. Even the relatively simpler Faceb= ook > client library requires several functions to sign requests. This makes th= e > client libraries a black box and impedes understanding. > > Wouldn=92t it be great if we could write a protocol that doesn=92t even r= equire > a client library to implement? If I could just make an authenticated API > request in my browser, as easily as with Basic Auth? > To these, I'd also add the obvious: SSL data is protected from reading in transit, while (only) OAuth signed data is not. This is important for many kinds of data passed in API calls. > > =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 argumen= ts > wrong or using the wrong algorithm, with SSL you worry about reading the > request over the wire. You can=92t sniff a request, and to intercept it, = you > need an HTTP proxy that understands SSL, and you need to worry about inva= lid > 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 =96 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=92ve talked to are > comfortable trading these higher costs for increased adoption due to the > simplicity. > Note that GMail recently turned on SSL for all user requests (for other reasons), constituting a natural experiment in what happens to a large service without and with SSL. I don't know if there are data we can share about performance impact, but I can investigate. > > -- Fixed costs for smaller providers > > There is a fixed cost to obtaining and signing an SSL certificates, > although that has dropped in recent years such that an operator can have = a > cert signed for a single domain for pretty cheap. > Apparently StartSSL will sign a certificate for free. I have not tried it out. > > -- 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 hig= her > latency in each request. Smaller, mobile devices may be disproportionatel= y > affected by this, but as they grow more powerful it=92s less of a concern= . > Already today newer phones can handle SSL just fine. > Shouldn't we be assuming HTTP keep-alive connections for APIs where latency and performance is a concern (and where there is sufficient traffic to make keep-alives a good tradeoff)? So the cold-start time may be higher, but th= e amortized cost may approach negligible. It's the initial SSL handshake tha= t costs, and you can re-use the same SSL connection across multiple calls to any path on a given host. Switching between hosts of course requires another connection, and this would drive API design. But it should drive API design anyway if latency is a concern, as the initial TCP connection ain't cheap either. > > -- 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=92s browser, then that information cannot be verified without an API > call, unless a signature is provided. Similar to stateful vs. stateless m= ode > in the OpenID 2.0 spec, the signature can serve as a performance enhancem= ent > to avoid an API call. > This is true but does the structure need to be standardized? (Assuming it'= s the SP that would verify the information it originated of course.) > > =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 becau= se > we want to help our long tail developers use our platform more easily. Fo= r > 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 a= n > 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=92s pretty important that OAuth= 2.0 > support a method other than SSL as an option for advanced developers. But= it > should be just that =96 an option, and only for advanced developers, so t= hat > beginning programmers and folks learning an API don=92t need to worry abo= ut > signatures when they just want to play around. > I agree with the long tail argument, and if there is a requirement for servers to support SSL as an option then client implementors could make thi= s choice. If it's left up to servers to decide though, then client implementors generally have to deal with the full complexity of both options, unless they write to exactly one provider of choice. Since we're hoping/planning that common libraries will be the main way client developer= s interact with all this though, that means that the complexity is pushed to the library developers -- forcing libraries to make a choice between complexity and full compatibility is not good for the ecosystem. I would love to see some public data on the performance trade-offs of SSL for API use cases, because I suspect that it is much lower than some people think for a properly designed API with keep-alive connections. (The security issues already discussed are another point, I'm just talking about server cost and latency hit here.) > Please let me know if I=92m 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 > > --001636b2ad25b64471047ff7efca Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Luke,<div><br></div><div>Thanks again for writing all of this up in such a = cogent way. =A0Some=A0comments inline:<br><br><div class=3D"gmail_quote">On= Thu, Jan 28, 2010 at 7:29 AM, Luke Shepard <span dir=3D"ltr"><<a href= =3D"mailto:lshepard@facebook.com">lshepard@facebook.com</a>></span> wrot= e:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"> <div> <font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:= 11pt">In the discussions around the OAuth WRAP spec, one of the questions o= ften asked is, =93why use SSL exclusively?=94 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 m= ind is that of a web service, like Facebook, Twitter, or Google services. O= ur service is primarily authenticated via the Web, but we have a use for al= l of the WRAP profiles (web app, client app, desktop, mobile).<br> =A0<br> 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.<br> <br> =3D=3D Advantages of using SSL for API calls<br> <br> -- It=92s overwhelmingly simpler for developers.<br> I=92ve implemented OpenID and OAuth, and I=92ve worked for years with devel= opers trying to handle signatures on the Facebook Platform. In my experienc= e, calculating signatures is one of the most complex and difficult parts of= an authentication protocol, and developers often get it wrong. By moving t= hat piece down the stack we can get it out of their way and let developers = focus on building their apps.<br> <br> -- Existing tools ecosystem<br> It=92s not that SSL is a simpler encryption protocol than OAuth (it=92s not= ) but rather that commonly available tools almost universally support it = =96 every major web browser, as well as most libraries for making HTTP requ= ests (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.<br> <br> -- Smaller client libraries<br> 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. <br> <br> Wouldn=92t it be great if we could write a protocol that doesn=92t even req= uire a client library to implement? If I could just make an authenticated A= PI request in my browser, as easily as with Basic Auth?<br></span></font></= div> </blockquote><div><br></div><div>To these, I'd also add the obvious: = =A0SSL data is protected from reading in transit, while (only) OAuth signed= data is not. =A0This is important for many kinds of data passed in API cal= ls.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"><div><font face=3D"Calibri, V= erdana, Helvetica, Arial"><span style=3D"font-size:11pt"> <br> =3D=3D Disadvantages of using SSL for API calls<br> <br> -- Difficulties of debugging<br> <br> 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=92t sniff a request, and to intercept it, yo= u need an HTTP proxy that understands SSL, and you need to worry about inva= lid 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 environm= ent to prevent damage from tokens exposed in plaintext.</span></font></div> </blockquote><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><font face= =3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:11pt"> <br> -- Variable costs for providers<br> <br> Server CPU costs will increase when handling SSL requests =96 especially on= every API call instead of just at the auth stage. At scale, this can becom= e expensive, although it can be offset by using specialized hardware to ter= minate the SSL connection. All the big companies I=92ve talked to are comfo= rtable trading these higher costs for increased adoption due to the simplic= ity.<br> </span></font></div></blockquote><div><br></div><div>Note that GMail recent= ly turned on SSL for all user requests (for other reasons), constituting a = natural experiment in what happens to a large service without and with SSL.= =A0I don't know if there are data we can share about performance impac= t, but I can investigate. =A0</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"><div><font face=3D"Calibri, V= erdana, Helvetica, Arial"><span style=3D"font-size:11pt"> <br> -- Fixed costs for smaller providers<br> <br> 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.<br></span></font></div></blockqu= ote> <div><br></div><div>Apparently StartSSL will sign a certificate for free. = =A0I have not tried it out.</div><div>=A0</div><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x;"> <div> <font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:= 11pt"> <br> -- Latency<br> <br> 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=92s less of a concern= . Already today newer phones can handle SSL just fine.<br> </span></font></div></blockquote><div><br></div><div>Shouldn't we be as= suming HTTP keep-alive connections for APIs where latency and performance i= s a concern (and where there is sufficient traffic to make keep-alives a go= od tradeoff)? =A0So the cold-start time may be higher, but the amortized co= st may approach negligible. =A0It's the initial SSL handshake that cost= s, and you can re-use the same SSL connection across multiple calls to any = path on a given host. =A0Switching between hosts of course requires another= connection, and this would drive API design. =A0But it should drive API de= sign anyway if latency is a concern, as the initial TCP connection ain'= t cheap either.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"><div><font face=3D"Calibri, V= erdana, Helvetica, Arial"><span style=3D"font-size:11pt"> <br> -- Browser limitations for cross domain communication<br> <br> 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.<br> <br> -- Verifying information on the relying party<br> <br> If information is passed from a Service Provider to a Consumer through the = user=92s 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 enhanceme= nt to avoid an API call.<br> </span></font></div></blockquote><div><br></div><div>This is true but does = the structure need to be standardized? =A0(Assuming it's the SP that wo= uld verify the information it originated of course.)</div><div>=A0</div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex;"> <div><font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-= size:11pt"> <br> =3D=3D Providing a non-SSL option for the short head<br> <br> 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.<br> <br> 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.<br> <br> 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=92s pretty important that OAuth 2.0 su= pport a method other than SSL as an option for advanced developers. But it = should be just that =96 an option, and only for advanced developers, so tha= t beginning programmers and folks learning an API don=92t need to worry abo= ut signatures when they just want to play around.<br> </span></font></div></blockquote><div><br></div><div>I agree with the long = tail argument, and if there is a requirement for servers to support SSL as = an option then client implementors could make this choice. =A0If it's l= eft up to servers to decide though, then client implementors generally have= to deal with the full complexity of both options, unless they write to exa= ctly one provider of choice. =A0Since we're hoping/planning that common= libraries will be the main way client developers interact with all this th= ough, that means that the complexity is pushed to the library developers --= forcing libraries to make a choice between complexity and full compatibili= ty is not good for the ecosystem.</div> <div>=A0</div><div>I would love to see some public data on the performance = trade-offs of SSL for API use cases, because I suspect that it is much lowe= r than some people think for a properly designed API with keep-alive connec= tions. =A0(The security issues already discussed are another point, I'm= just talking about server cost and latency hit here.)</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex;"><div><font face=3D"Calibri, = Verdana, Helvetica, Arial"><span style=3D"font-size:11pt"> <br> Please let me know if I=92m missing something or if my assumptions sound in= correct.</span></font></div></blockquote><div>=A0</div><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex;"> <div><font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-= size:11pt"> <br> -Luke Shepard<br> Software Engineer, Facebook Platform<br> </span></font> </div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> --001636b2ad25b64471047ff7efca-- From igor.faynberg@alcatel-lucent.com Fri Feb 19 10:14:16 2010 Return-Path: <igor.faynberg@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B1628C103 for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 10:14:16 -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 MbBrse8OVZb6 for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 10:14:15 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id E866128C11D for <oauth@ietf.org>; Fri, 19 Feb 2010 10:14:14 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o1JIFujV022911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Feb 2010 12:15:56 -0600 (CST) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o1JIFtge001289; Fri, 19 Feb 2010 12:15:55 -0600 (CST) Message-ID: <4B7ED55B.3080808@alcatel-lucent.com> Date: Fri, 19 Feb 2010 13:15:55 -0500 From: Igor Faynberg <igor.faynberg@alcatel-lucent.com> Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Torsten Lodderstedt <torsten@lodderstedt.net> References: <daf5b9571002181235u73fd3b0ar3a8ded512167907a@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BC9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9571002182151n773234aaj3137ef23f970c854@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BDC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9571002182209v42a9942fyd3caed7da20a9d37@mail.gmail.com> <4B7E4779.7030804@lodderstedt.net> <4B7E97D8.6050107@alcatel-lucent.com> <4B7EA1AD.9020003@lodderstedt.net> In-Reply-To: <4B7EA1AD.9020003@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] operational security X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 18:14:16 -0000 I have no doubt that the description makes sense, but I have not quite grasped it. I think that what you mean is the case when I want to get to a web site (relying party) with an OpenID. Here I should get from the identity provider (after it authenticates me) not only an assertion to pass back to the relying party but also a token. But what I don't understand is what access rights will this token give me. Is that that my identity provider is expected to know what access rights I have on different sites? This is the part that I am lost in. Maybe it would be easy to explain this idea by applying it to the classical OAuth use case (i.e., getting a printing service to print my photos on a photo album site)? If there is something written on this case, maybe you could share it? I am actually very interested in this subject and glad that you brought it up. Igor Torsten Lodderstedt wrote: > Suppose a webite wants to (1) login users interactively and (2) access > web services on behalf of those users which are secured by tokens. > From my point of view, one could integrate token issuance into the > login process. So the application might perform login via Openid and > request access tokens as additional results of the login process from > the identity provider. Does this make sense? > > regards, > Torsten. > From lshepard@facebook.com Fri Feb 19 11:36:11 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533AB3A7C9E for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 11:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.269 X-Spam-Level: X-Spam-Status: No, score=-5.269 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SARE_LWHUGE=1.54] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjjwb7i4SoOx for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 11:36:09 -0800 (PST) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id C43C13A7228 for <oauth@ietf.org>; Fri, 19 Feb 2010 11:36:09 -0800 (PST) Received: from mail.thefacebook.com ([192.168.18.83]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o1JJbQoh024730 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Feb 2010 11:37:26 -0800 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Fri, 19 Feb 2010 11:37:54 -0800 From: Luke Shepard <lshepard@facebook.com> To: Chris Messina <chris.messina@gmail.com> Date: Fri, 19 Feb 2010 11:37:32 -0800 Thread-Topic: [OAUTH-WG] WG Survey Thread-Index: AcqxmwdV55JTT1yhSoeRXSqz+5bIVw== Message-ID: <F484D88F-D7D5-4F8E-8B95-0C78E5C433C1@facebook.com> References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <fd6741651002182224g39f6c453u6dfc27396e856bd8@mail.gmail.com> <45E4EADB-D1C9-40C7-AA24-F1E0A1212F2C@gmail.com> In-Reply-To: <45E4EADB-D1C9-40C7-AA24-F1E0A1212F2C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F484D88FD7D54F8E8B950C78E5C433C1facebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-02-19_13:2010-02-06, 2010-02-19, 2010-02-19 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 19:36:11 -0000 --_000_F484D88FD7D54F8E8B950C78E5C433C1facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. Why are you here? What are you trying to solve that is not already addre= ssed by existing specifications (OAuth 1.0a, WRAP, etc) I'm here because we have a huge opportunity, right now, to move authenticat= ion down the "stack" a level. Just as developers don't have to worry about = HTTP anymore - it just sorta happens effortlessly - likewise, I want to bui= ld a spec that has enough widespread adoption so that the entire tools ecos= ystem supports it. If we are successful, then developers won't have to thin= k about auth - they can worry about building their applications. One thing that I haven't seen mentioned much is the relationship between Op= enID and OAuth. A primary goal of mine in OAuth 2.0 is to see a path to smo= oth interop with OpenID. The current OpenID/OAuth Hybrid protocol is awkwar= d and overly complex; it would be nice if the two protocols stacked on top = of each other really nicely. For a service like Facebook to truly adopt OAuth as our one standard way of= logging in, it must be able to support identity as well as authorization. = To me, this is one of the elephants in the room that we need to address. 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? = Something else? Dave summed this up nicely - I'd like to see what he comes up with. Persona= lly, I have a preference towards starting with WRAP, because it better refl= ects the Facebook Connect use cases than does OAuth 1.0a. On Feb 19, 2010, at 10:59 AM, Chris Messina wrote: +1 to what Dave said. I almost wrote the same thing (though admittedly with less technical insigh= t). To me, the needs are: 1. Consolidate the needs for OAuth 2.0 2. Merge the documents as necessary; rinse, wash, repeat until we have a sa= tisfactorially readable and comprehensible document (2.0 should be one of E= ran's "editor's drafts"). 3. We need more flow diagrams methinks (I'll volunteer to prettify any ASCI= I drawings). 4. This document needs to tell the marketplace that OAuth is: evolving, sta= ble, secure, and getting easier to implement in more diverse (and realistic= ) environments. And that 2.0 isn't abandoning 1.0a, but improving on that f= oundation to solve the problems that have become clearer to us in the past = several years since 1.0 was released. 5. I would volunteer to write a context-setting document to help people who= aren't active in these lists understand the goals, context, and purpose be= hind revving OAuth. Managing the transition and outreach for the next rev of OAuth will be near= ly as important as getting to a final document in my mind. Chris Sent from my iPhone 2G On Feb 18, 2010, at 10:24 PM, David Recordon <recordond@gmail.com<mailto:re= cordond@gmail.com>> wrote: Glad to see this thread. :) On Thu, Feb 18, 2010 at 9:14 AM, Eran Hammer-Lahav <<mailto:eran@hueniverse= .com>eran@hueniverse.com<mailto:eran@hueniverse.com>> wrote: A few questions we should answer before moving forward. Considering *your* = use cases and reasons for being here: 1. Why are you here? What are you trying to solve that is not already addre= ssed by existing specifications (OAuth 1.0a, WRAP, etc)? OAuth has been insanely successful the past few years in terms of almost el= iminating new password-based APIs. That said, developers both large and sm= all have found it to be complex and not as simple to implement as possible.= We now have the opportunity to develop OAuth 2.0 based on what we've lear= ned and new methodologies in APIs that weren't prevalent two years ago. Ov= erall, I want to modernize OAuth so that it's not just "FooCo supports OAut= h" but rather "FooCo has a million developers using OAuth". 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? = Something else? I think that WRAP has a lot of the right ideas (multiple ways to get tokens= and relies on SSL), but ultimately wasn't created in an open process and w= as shaped by small number of implementors. I also think that there are les= sons to be learned from OAuth 1.0 which haven't made their way into the cur= rent WRAP draft. If I were to write a draft, I'd start with an empty document and merge in a= ppropriate sections from draft-hammer-oauth, draft-hammer-http-token-auth, = and WRAP. I'd then probably rewrite half of the text as it gets merged tog= ether. 3. If we start from draft-hammer-oauth, what needs to change to turn it int= o OAuth 2.0? Eran had a good answer here. 4. If we start from draft-hardt-oauth, what needs to change to turn it into= OAuth 2.0? Eran had a good answer here. 5. Do you think the approach of working first on 'how to use a token' and t= hen on 'how to get a token' is right? I think it's hard to compare text from this split approach to the WRAP draf= t spec. 6. Should we go back to working on a single specification? Yes. We can split it apart later, but should optimize for a single easy to= understand document. 7. Do you think the protocol should include a signature-based authenticatio= n scheme? Yes. See <http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html= > http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html. EHL _______________________________________________ OAuth mailing list <mailto:OAuth@ietf.org>OAuth@ietf.org<mailto:OAuth@ietf.org> <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/l= istinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <ATT00001..txt> --_000_F484D88FD7D54F8E8B950C78E5C433C1facebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:= space; -webkit-line-break: after-white-space; "> <blockquote type=3D"= cite"><div bgcolor=3D"#FFFFFF"><blockquote type=3D"cite"><div><div class=3D= "gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; m= argin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width= : 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; pad= ding-left: 1ex; position: static; z-index: auto; ">1. Why are you here? Wha= t are you trying to solve that is not already addressed by existing specifi= cations (OAuth 1.0a, WRAP, etc)<br></blockquote></div></div></blockquote></= div></blockquote><div><br></div><div>I'm here because we have a huge opport= unity, right now, to move authentication down the "stack" a level. Just as = developers don't have to worry about HTTP anymore - it just sorta happens e= ffortlessly - likewise, I want to build a spec that has enough widespread a= doption so that the entire tools ecosystem supports it. If we are successfu= l, then developers won't have to think about auth - they can worry about bu= ilding their applications.</div><div><br></div><div>One thing that I haven'= t seen mentioned much is the relationship between OpenID and OAuth. A prima= ry goal of mine in OAuth 2.0 is to see a path to smooth interop with OpenID= . The current OpenID/OAuth Hybrid protocol is awkward and overly complex; i= t would be nice if the two protocols stacked on top of each other really ni= cely.</div><div><br></div><div>For a service like Facebook to truly adopt O= Auth as our one standard way of logging in, it must be able to support iden= tity as well as authorization. To me, this is one of the elephants in the r= oom that we need to address.</div><div><br></div><div><br></div><div><block= quote type=3D"cite"><div bgcolor=3D"#FFFFFF"><blockquote type=3D"cite"><div= ><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg= in-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; bor= der-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-sty= le: solid; padding-left: 1ex; ">2. Should the WG start by taking WRAP or OA= uth 1.0a as its starting point? Something else?<br></blockquote></div></div= ></blockquote></div></blockquote><div><br></div><div>Dave summed this up ni= cely - I'd like to see what he comes up with. Personally, I have a preferen= ce towards starting with WRAP, because it better reflects the Facebook Conn= ect use cases than does OAuth 1.0a.</div></div><div><br></div><div><div>On = Feb 19, 2010, at 10:59 AM, Chris Messina wrote:</div><br class=3D"Apple-int= erchange-newline"><blockquote type=3D"cite"><div bgcolor=3D"#FFFFFF"><div>+= 1 to what Dave said. </div><div><br></div><div>I almost wrote the same= thing (though admittedly with less technical insight).</div><div><br></div= ><div>To me, the needs are:</div><div><br></div><div>1. Consolidate the nee= ds for OAuth 2.0</div><div>2. Merge the documents as necessary; rinse, wash= , repeat until we have a satisfactorially readable and comprehensible docum= ent (2.0 should be one of Eran's "editor's drafts").</div><div>3. We need m= ore flow diagrams methinks (I'll volunteer to prettify any ASCII drawings).= </div><div>4. This document needs to tell the marketplace that OAuth is: ev= olving, stable, secure, and getting easier to implement in more diverse (an= d realistic) environments. And that 2.0 isn't abandoning 1.0a, but improvin= g on that foundation to solve the problems that have become clearer to us i= n the past several years since 1.0 was released. </div><div>5. I would= volunteer to write a context-setting document to help people who aren't ac= tive in these lists understand the goals, context, and purpose behind revvi= ng OAuth. </div><div><br></div><div>Managing the transition and outrea= ch for the next rev of OAuth will be nearly as important as getting to a fi= nal document in my mind. </div><div><br></div><div>Chris</div><div><br= >Sent from my iPhone 2G</div><div><br>On Feb 18, 2010, at 10:24 PM, David R= ecordon <<a href=3D"mailto:recordond@gmail.com">recordond@gmail.com</a>&= gt; wrote:<br><br></div><div></div><blockquote type=3D"cite"><div>Glad to s= ee this thread. :)<br><br><div class=3D"gmail_quote">On Thu, Feb 18, 2010 a= t 9:14 AM, Eran Hammer-Lahav <span dir=3D"ltr"><<a href=3D"mailto:eran@h= ueniverse.com"></a><a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.c= om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; bor= der-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-sty= le: solid; padding-left: 1ex; position: static; z-index: auto; "> A few questions we should answer before moving forward. Considering *your* = use cases and reasons for being here:<br> <br> 1. Why are you here? What are you trying to solve that is not already addre= ssed by existing specifications (OAuth 1.0a, WRAP, etc)?<br></blockquote><d= iv><br></div><div>OAuth has been insanely successful the past few years in = terms of almost eliminating new password-based APIs.  That said, devel= opers both large and small have found it to be complex and not as simple to= implement as possible.  We now have the opportunity to deve= lop OAuth 2.0 based on what we've learned and new methodologies in APIs tha= t weren't prevalent two years ago.  Overall, I want to modernize = OAuth so that it's not just "FooCo supports OAuth" but rather "FooCo has a = million developers using OAuth".</div> <div><br></div><div> </div><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2. Should t= he WG start by taking WRAP or OAuth 1.0a as its starting point? Something e= lse?<br> </blockquote><div><br></div><div>I think that WRAP has a lot of the right i= deas (multiple ways to get tokens and relies on SSL), but ultimately wasn't= created in an open process and was shaped by small number of implementors.=  I also think that there are lessons to be learned from OAuth 1.0 whi= ch haven't made their way into the current WRAP draft.</div> <div><br></div><div>If I were to write a draft, I'd start with an empty doc= ument and merge in appropriate sections from draft-hammer-oauth, <span= class=3D"Apple-style-span" style=3D"font-family: arial, sans-serif; font-s= ize: 13px; border-collapse: collapse; ">draft-hammer-http-token-auth, and W= RAP.  I'd then probably rewrite half of the text as it gets = merged together.</span></div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">3. If we star= t from draft-hammer-oauth, what needs to change to turn it into OAuth 2.0?<= br> </blockquote><div><br></div><div>Eran had a good answer here.</div><div>&nb= sp;</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">4. If we start from= draft-hardt-oauth, what needs to change to turn it into OAuth 2.0?<br> </blockquote><div><br></div><div><div>Eran had a good answer here.</div><di= v><br></div></div><div> </div><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 5. Do you think the approach of working first on 'how to use a token' and t= hen on 'how to get a token' is right?<br></blockquote><div><br></div><div>I= think it's hard to compare text from this split approach to the WRAP draft= spec.</div> <div><br></div><div> </div><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 6. Should we go back to working on a single specification?<br></blockquote>= <div><br></div><div>Yes.  We can split it apart later, but should opti= mize for a single easy to understand document.</div><div> </div><div><= br></div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">7. Do you think the protocol should include= a signature-based authentication scheme?<br></blockquote><div><br></div><d= iv> Yes.  See <a href=3D"http://www.ietf.org/mail-archive/web/oauth/c= urrent/msg01049.html"></a><a href=3D"http://www.ietf.org/mail-archive/web/o= auth/current/msg01049.html">http://www.ietf.org/mail-archive/web/oauth/curr= ent/msg01049.html</a>.</div><div><br></div><div> </div><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex;"> <font color=3D"#888888">EHL<br> </font><div><div></div><div class=3D"h5">__________________________________= _____________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org"></a><a href=3D"mailto:OAuth@ietf.org">OAu= th@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank"><= /a><a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf= .org/mailman/listinfo/oauth</a><br> </div></div></blockquote></div><br> </div></blockquote><blockquote type=3D"cite"><div><span>___________________= ____________________________</span><br><span>OAuth mailing list</span><br><= span><a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a></span><br><span><= a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth</a></span><br></div></blockquote></div><span><AT= T00001..txt></span></blockquote></div><br></body></html>= --_000_F484D88FD7D54F8E8B950C78E5C433C1facebookcom_-- From stpeter@stpeter.im Fri Feb 19 13:22:05 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BF703A738A for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 13:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAN9P-sPSDvb for <oauth@core3.amsl.com>; Fri, 19 Feb 2010 13:22:04 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 652183A6A8A for <oauth@ietf.org>; Fri, 19 Feb 2010 13:22:04 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 781FB40337 for <oauth@ietf.org>; Fri, 19 Feb 2010 14:23:51 -0700 (MST) Message-ID: <4B7F0165.9010002@stpeter.im> Date: Fri, 19 Feb 2010 14:23:49 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: OAuth WG <oauth@ietf.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040301010009000104020805" Subject: [OAUTH-WG] provisional timeslot in Anaheim X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 19 Feb 2010 21:22:05 -0000 This is a cryptographically signed message in MIME format. --------------ms040301010009000104020805 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The OAuth WG is provisionally scheduled to meet at IETF 77 on Monday, March 22 at 13:00 local time. The other sessions scheduled at that time are as follows: oauth Open Authentication Protocol WG 6lowpan IPv6 over Low power WPAN WG lisp Locator/ID Separation Protocol WG bmwg Benchmarking Methodology WG martini Multiple AoR reachabiliTy InformatioN Indication WG ccamp Common Control and Measurement Plane WG nea Network Endpoint Assessment WG If you see any schedule conflicts in that list, please contact the chairs= =2E Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040301010009000104020805 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 hvcNAQkFMQ8XDTEwMDIxOTIxMjM0OVowIwYJKoZIhvcNAQkEMRYEFBTMK3rM8E52p1CISzB9 mYJbwCV+MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAC8XId83wQCQHcWPaFllzS04BtIYxzws9wK7iyN8J ldnorwZFoIxMmVWzd0raa2x90N77A28hHeqSZ+uVgu06bQ7fIIHdUF2AXIergk0fIcFjietX WL//GSCTz44BL9bC7tUicWKGijVtZB3thkJm4ODCFaGi9yxK/cl4EmwE6HB8PzU2brIiDFyA owY27MOdjt0LQYF3cYLs92a8T8DMGeIDgnd4++NiVPEYYZdY0E5etPExi2j7Pn4vDrNkM5lN cw+oLDfMtnDfWTpOW1P801wv3siXiNAz4OlapffelxgckdzyBapAE3MWv8lW/d58IGOuieAv u9MI9ZEcELoqfQAAAAAAAA== --------------ms040301010009000104020805-- From mark.mcgloin@ie.ibm.com Sun Feb 21 03:25:34 2010 Return-Path: <mark.mcgloin@ie.ibm.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A5D28C0E0 for <oauth@core3.amsl.com>; Sun, 21 Feb 2010 03:25:34 -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 99dQAoYYYxE4 for <oauth@core3.amsl.com>; Sun, 21 Feb 2010 03:25:34 -0800 (PST) Received: from mtagate5.uk.ibm.com (mtagate5.uk.ibm.com [194.196.100.165]) by core3.amsl.com (Postfix) with ESMTP id A4ED13A7BFC for <oauth@ietf.org>; Sun, 21 Feb 2010 03:25:32 -0800 (PST) Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate5.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o1LBRORU018998 for <oauth@ietf.org>; Sun, 21 Feb 2010 11:27:24 GMT Received: from d06av05.portsmouth.uk.ibm.com (d06av05.portsmouth.uk.ibm.com [9.149.37.229]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o1LBRG1H1786020 for <oauth@ietf.org>; Sun, 21 Feb 2010 11:27:24 GMT Received: from d06av05.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av05.portsmouth.uk.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o1LBRFg0002649 for <oauth@ietf.org>; Sun, 21 Feb 2010 04:27:16 -0700 Received: from d06ml901.portsmouth.uk.ibm.com (d06ml901.portsmouth.uk.ibm.com [9.149.39.138]) by d06av05.portsmouth.uk.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o1LBRFMe002646 for <oauth@ietf.org>; Sun, 21 Feb 2010 04:27:15 -0700 In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: oauth@ietf.org X-Mailer: Lotus Notes Release 7.0 HF400 February 20, 2008 Message-ID: <OFFA3C07FA.41100087-ON802576D1.003E47A3-802576D1.003EEA8A@ie.ibm.com> From: Mark Mcgloin <mark.mcgloin@ie.ibm.com> Date: Sun, 21 Feb 2010 11:27:10 +0000 X-MIMETrack: Serialize by Router on D06ML901/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 21/02/2010 11:27:15 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 21 Feb 2010 11:25:34 -0000 > 1. Why are you here? What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)? I want to see a single hardened protocol rather than fragmented proprietty solutions. My leaning is towards a secure solution suitable for enterprise customers more than an easy to use solution for long end developers. To that end, standardizing on something that can then be used to build better library support should satisfy all parties > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? Something else? Not sure. Wrap is better from architecture point of view but OAuth has put more thought into security > 3. If we start from draft-hammer-oauth, what needs to change to turn it into OAuth 2.0? Better separation of authorization (Get a token) from authentication (use a token) > 4. If we start from draft-hardt-oauth, what needs to change to turn it into OAuth 2.0? Fill out section on security considerations, e.g. Spell out assumptions on infrastructure like SSL that are required to ensure security or threat models for non-SSL > 6. Should we go back to working on a single specification? Yes > 7. Do you think the protocol should include a signature-based authentication scheme? Yes. I think there will be some use cases or worries from over-cautious CIOs that it will neccessitate it. Mark McGloin From torsten@lodderstedt.net Sun Feb 21 06:53:45 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E52F28C1D8 for <oauth@core3.amsl.com>; Sun, 21 Feb 2010 06:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n45zuWgvXWv4 for <oauth@core3.amsl.com>; Sun, 21 Feb 2010 06:53:44 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id 084843A7B18 for <oauth@ietf.org>; Sun, 21 Feb 2010 06:53:43 -0800 (PST) Received: from p4fff236d.dip.t-dialin.net ([79.255.35.109] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1NjDDZ-0001iB-1V; Sun, 21 Feb 2010 15:55:33 +0100 Message-ID: <4B81495B.30302@lodderstedt.net> Date: Sun, 21 Feb 2010 15:55:23 +0100 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <daf5b9571002181235u73fd3b0ar3a8ded512167907a@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BC9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9571002182151n773234aaj3137ef23f970c854@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343864B47BDC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9571002182209v42a9942fyd3caed7da20a9d37@mail.gmail.com> <4B7E4779.7030804@lodderstedt.net> <4B7E97D8.6050107@alcatel-lucent.com> <4B7EA1AD.9020003@lodderstedt.net> <4B7ED55B.3080808@alcatel-lucent.com> In-Reply-To: <4B7ED55B.3080808@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] operational security (OpenId and OAuth) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 21 Feb 2010 14:53:45 -0000 Hi Igor, > > I have no doubt that the description makes sense, but I have not quite > grasped it. I think that what you mean is the case when I want to get > to a web site (relying party) with an OpenID. Here I should get from > the identity provider (after it authenticates me) not only an > assertion to pass back to the relying party but also a token. > > But what I don't understand is what access rights will this token give > me. Is that that my identity provider is expected to know what access > rights I have on different sites? This is the part that I am lost in. > > Maybe it would be easy to explain this idea by applying it to the > classical OAuth use case (i.e., getting a printing service to print my > photos on a photo album site)? > > If there is something written on this case, maybe you could share it? > > I am actually very interested in this subject and glad that you > brought it up. I didn't have anything in my pocket when I asked Brian regarding convergence of OpenId and OAuth. It was just an idea coming into my mind, when he pointed out the security risk imposed by storing tokens in a Oauth client. OAuth is great in that it eliminates the need to handle user passwords on consumer sites, the same objective can be achieved when using OpenId for web site login. So combining OAuth with OpenId for this category of applications might be beneficialy. And you are right, the key is the relationship between OpenId OP and OAuth Autorization Server the target services trust in. Below I summarize two possible setups. Note it is more brainstorming then thought through in detail. (I intentionally left out some details about privacy and security). *strong coupling In the simplest case, the photo album site is offered by a large service provider, which offers many different sites (products) to users. In order to offer a seamless user experience and facilitate security for web applications, the service provider uses a central user/authorization data management and a SSO server based on OpenId. So in comparison to classical OpenId, the OpenId protocol is used under the hood but the only OP supported for web site login is the provider's OP. Web service access is secured using OAuth tokens. Tokens are issued by a single OAuth service for all sites, which also operate on the central user/authorization data management. The provider also offers a photo print service to its customers, which is bound to the providers photo album site. Login at the photo print service could be performed as follows: 1) Photo print service initiates authentication and passes an additional parameter, which identifies the required service (photo album) 2) OP authenticates the user 3) OP shows user consent page. In this case not only asking for the approval to send attributes but also permissions to the RP 4) OP has access to user data base and directly creates tokens (it could delegate this part to the OAuth service, too) 5) Tokens are sent back with the response to the photo print service Such a strong coupling can be found in the environment I currently work in. Benefits: the typical benefits expected by standards (maturity, know-how, libraries,...), it would especially simplify the the implementation of both web services and applications and decrease cost. *loose coupling Let's try now to generalize the idea a bit. Assumptions: - the photo album site uses OpenId and operates a OAuth service - the photo print service site uses OpenId as well - users can use any OpenId server they like for both services as long as the use the same OpenId for both services - OAuth user consent pages shall be delivered by the OAuth server because of user recognition 1) Photo print service initiate authentication, passes additional parameters, which identify the required realms and services 2) OP authenticates the user 3) OP shows usual user consent page (attributes). 4) OP looks up OAuth provider associated with target web services (e.g. using YADIS/XRDS) 5) OP sents request to oauth provider along with the authenticated openid Note: there has to be a trust relationship between OAuth server and OpenId OP. I see different options here: pre-shared secrets, something based on OpenId discovery, probably the registration free process based on public key as suggested by Eran (posting from 02/19/2010) 6) OAuth server looks up its database for a user associated with the given openid 7) If the user exists, the OAuth responds with a redirect URL for the tokens authorization process 8) OP redirects user browser to OAuth server 9) OAuth server requests users approval for photo print service + asks the user to allow the OpenID OP to automatically request tokens for the photo print service in future authentication transactions 10) OAuth server creates tokens and encrypts them using the photo service consumer_secret (prevents eavesdropping by OP and on transit) + OAuth server issues a token to the OpenId server to be used for further tokens acquisitions (based on the approval in step 9+) 11) OAuth redirects user browser back to OpenId OP along with the encrypted token(s) 12) OP redirects user browser back, the response contains the usual OpenId parameters + the OAuth tokens What do you think? regards, Torsten. > > Igor > > Torsten Lodderstedt wrote: >> Suppose a webite wants to (1) login users interactively and (2) >> access web services on behalf of those users which are secured by >> tokens. From my point of view, one could integrate token issuance >> into the login process. So the application might perform login via >> Openid and request access tokens as additional results of the login >> process from the identity provider. Does this make sense? >> >> regards, >> Torsten. >> From hannes.tschofenig@nsn.com Sun Feb 21 08:06:55 2010 Return-Path: <hannes.tschofenig@nsn.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5351828C135 for <oauth@core3.amsl.com>; Sun, 21 Feb 2010 08:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Ov1nnlIfmS4E for <oauth@core3.amsl.com>; Sun, 21 Feb 2010 08:06:54 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 1DC1928C131 for <oauth@ietf.org>; Sun, 21 Feb 2010 08:06:53 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1LG8f35009699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2010 17:08:42 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1LG8fl8028711; Sun, 21 Feb 2010 17:08:41 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Feb 2010 17:08:41 +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: Sun, 21 Feb 2010 18:12:59 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502389244@FIESEXC015.nsn-intra.net> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] WG Survey Thread-Index: AcqwvdIpwql/pJksQI6hDRprwnPDjACUjwpA References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> To: "ext Eran Hammer-Lahav" <eran@hueniverse.com>, <oauth@ietf.org> X-OriginalArrivalTime: 21 Feb 2010 16:08:41.0244 (UTC) FILETIME=[227545C0:01CAB310] Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 21 Feb 2010 16:06:55 -0000 Hi Eran,=20 There are a couple of problems with this survey. See below =20 >-----Original Message----- >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 >On Behalf Of ext Eran Hammer-Lahav >Sent: 18 February, 2010 19:14 >To: OAuth WG (oauth@ietf.org) >Subject: [OAUTH-WG] WG Survey > >A few questions we should answer before moving forward.=20 >Considering *your* use cases and reasons for being here: > >1. Why are you here? What are you trying to solve that is not=20 >already addressed by existing specifications (OAuth 1.0a, WRAP, etc)? During the conference call we figured out that there is no way one would easily agree to a single scenario or deployment variant.=20 This is where some the disagreements come from. Some folks have the super-secure governmental application in mind, others want to support the enterprise environment which are able to spend a lot of money on security, and then there are others that focus on the web developer that does not have even money for the certs.=20 How do you want to provide a solution that fits everyone? Not really possible IMHO (unless you introduce the notion of "profiles").=20 > >2. Should the WG start by taking WRAP or OAuth 1.0a as its=20 >starting point? Something else? Largely irrelevant as the content will change anyway=20 > >3. If we start from draft-hammer-oauth, what needs to change=20 >to turn it into OAuth 2.0? Depends on the scenarios you want to cover under item (1).=20 > >4. If we start from draft-hardt-oauth, what needs to change to=20 >turn it into OAuth 2.0? Depends on the scenarios you want to cover under item (1).=20 > >5. Do you think the approach of working first on 'how to use a=20 >token' and then on 'how to get a token' is right? Nope. First, you have to figure out what you want the specification to accomplish.=20 > >6. Should we go back to working on a single specification? Does not matter. This is purely a document management / authorship question that would come last.=20 > >7. Do you think the protocol should include a signature-based=20 >authentication scheme? That depends on the scenarios you want to cover.=20 Ciao Hannes > >EHL >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Sun Feb 21 09:40:35 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B36C3A7EBD for <oauth@core3.amsl.com>; Sun, 21 Feb 2010 09:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 n1AokDXEdSzd for <oauth@core3.amsl.com>; Sun, 21 Feb 2010 09:40:34 -0800 (PST) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id A87823A79A3 for <oauth@ietf.org>; Sun, 21 Feb 2010 09:40:34 -0800 (PST) Received: by iwn29 with SMTP id 29so665401iwn.31 for <oauth@ietf.org>; Sun, 21 Feb 2010 09:42: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; bh=Bkp59A1LP4eUHMYoSM+++vv6nmn3kHnIq1Zh0QDLUeo=; b=rO+7/KWgdD3NKiJfRx3PXxeAiG0Lgd95D9yS5sRrNb0ysxD6QTdl8wiFUlQ8lvzUXU vs+U5B26PsxlC40JzwrYSdgULMS2JYRA4fgEOICHhNcMB1fBnfTfZ7nR+RoVLO0Bm0/s FYi/xJKX5HpAK0O/0jHaDykB/Z4zIDIxp4MYc= 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=IfNPa0vI/w8JswaaU5Uzy3s+tQfiuvPrZfR3O0WvIILDPx1q+yN66Kjk51PNhLHCXm 6kSgSwAbgelZCRdKh5APl+iaK9Ldw4xSngv5nBcmKn2AbRCWaF5xYFUpLFoPNJqLCnWw ZYXtVpwsodPXaJO+sYwE35F4mQxBgmBhTERzQ= MIME-Version: 1.0 Received: by 10.231.146.66 with SMTP id g2mr2312045ibv.88.1266774147312; Sun, 21 Feb 2010 09:42:27 -0800 (PST) In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502389244@FIESEXC015.nsn-intra.net> References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4502389244@FIESEXC015.nsn-intra.net> Date: Sun, 21 Feb 2010 09:42:27 -0800 Message-ID: <fd6741651002210942y3c58d84bld644cd0ff6d4f25f@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 21 Feb 2010 17:40:35 -0000 Hey Hannes, Not to be taken the wrong way, but we've already had eight really informative responses to this survey. It would be useful to understand what you're interested in solving within this working group versus just hearing the belief that the survey is broken. :) Cheers, --David On Sun, Feb 21, 2010 at 8:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com> wrote: > Hi Eran, > > There are a couple of problems with this survey. See below > >>-----Original Message----- >>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >>On Behalf Of ext Eran Hammer-Lahav >>Sent: 18 February, 2010 19:14 >>To: OAuth WG (oauth@ietf.org) >>Subject: [OAUTH-WG] WG Survey >> >>A few questions we should answer before moving forward. >>Considering *your* use cases and reasons for being here: >> >>1. Why are you here? What are you trying to solve that is not >>already addressed by existing specifications (OAuth 1.0a, WRAP, etc)? > > During the conference call we figured out that there is no way one would > easily agree to a single scenario or deployment variant. > > This is where some the disagreements come from. Some folks have the > super-secure governmental application in mind, others want to support > the enterprise environment which are able to spend a lot of money on > security, and then there are others that focus on the web developer that > does not have even money for the certs. > > How do you want to provide a solution that fits everyone? Not really > possible IMHO (unless you introduce the notion of "profiles"). > >> >>2. Should the WG start by taking WRAP or OAuth 1.0a as its >>starting point? Something else? > > Largely irrelevant as the content will change anyway > >> >>3. If we start from draft-hammer-oauth, what needs to change >>to turn it into OAuth 2.0? > > Depends on the scenarios you want to cover under item (1). > >> >>4. If we start from draft-hardt-oauth, what needs to change to >>turn it into OAuth 2.0? > > > Depends on the scenarios you want to cover under item (1). > >> >>5. Do you think the approach of working first on 'how to use a >>token' and then on 'how to get a token' is right? > > Nope. First, you have to figure out what you want the specification to > accomplish. > > >> >>6. Should we go back to working on a single specification? > > Does not matter. This is purely a document management / authorship > question that would come last. > >> >>7. Do you think the protocol should include a signature-based >>authentication scheme? > > That depends on the scenarios you want to cover. > > Ciao > Hannes > >> >>EHL >>_______________________________________________ >>OAuth mailing list >>OAuth@ietf.org >>https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From hannes.tschofenig@nsn.com Sun Feb 21 10:16:04 2010 Return-Path: <hannes.tschofenig@nsn.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3858A3A7D4B for <oauth@core3.amsl.com>; Sun, 21 Feb 2010 10:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 ymLt848pb+69 for <oauth@core3.amsl.com>; Sun, 21 Feb 2010 10:16:03 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id B1D943A7D70 for <oauth@ietf.org>; Sun, 21 Feb 2010 10:16:02 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1LIHmtW006399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2010 19:17:48 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1LIHms5030217; Sun, 21 Feb 2010 19:17:48 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Feb 2010 19:17:48 +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: Sun, 21 Feb 2010 20:22:05 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502389262@FIESEXC015.nsn-intra.net> In-Reply-To: <fd6741651002210942y3c58d84bld644cd0ff6d4f25f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scenarios -- was RE: [OAUTH-WG] WG Survey Thread-Index: AcqzHT3h74sOM7bESmCu9iKQ+nG5ogAAT4og References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4502389244@FIESEXC015.nsn-intra.net> <fd6741651002210942y3c58d84bld644cd0ff6d4f25f@mail.gmail.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> To: "ext David Recordon" <recordond@gmail.com> X-OriginalArrivalTime: 21 Feb 2010 18:17:48.0051 (UTC) FILETIME=[2BEA3630:01CAB322] Cc: oauth@ietf.org Subject: [OAUTH-WG] Scenarios -- was RE: WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 21 Feb 2010 18:16:04 -0000 Hi David,=20 It is good that folks share their thoughts.=20 Sometimes it is, however, difficult to pinpoint the real challenge. To me it seems that the different deployment scenarios people have in mind cause most of the problems. Here is an example conversation from the recent virtual interim meeting chat:=20 * Blaine argues that some web developers cannot afford a certificate and hence, for him, OAuth with only TLS based authentication is not enough. This demands token and HTTP message content signing mechanisms. * Brian claims that TLS is sufficient to protect bearer tokens. =20 * Jeff and Eve argue that they have scenarios where you need to have TLS and signed tokens.=20 So, what are the options:=20 1) You support all three scenarios. The spec will be large and various people will claim it is complex and that there might be an interoperability problem*.=20 2) You pick only one of the three scenarios. Let's say you pick the scenario Brian has in mind. The specification is simpler than (1) but will obviously not cover the scenario the other folks had in mind. That may or may not matter. Maybe the developer group Blaine has in mind suddenly decides to buy certificates to be more security aware. Who knows. It is a bit hard to predict the future. In any case, Blaine, Jeff and Eve will be unhappy and will likely do what they want anyway, namely to extend OAuth in their favorite way (in the usual forum shopping mentality).=20 Does this make any sense to you?=20 Now, what would you do? Ciao Hannes PS: I am sure that Eran is concerned about the time it will take him to edit the documents back and forth. Regarding (*): There is an interoperability problem but there is already one anyway since many other parts in the specification are not described so that independent implementations will have a hard time to interwork automatically anyway. >-----Original Message----- >From: ext David Recordon [mailto:recordond@gmail.com]=20 >Sent: 21 February, 2010 19:42 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: Eran Hammer-Lahav; oauth@ietf.org >Subject: Re: [OAUTH-WG] WG Survey > >Hey Hannes, >Not to be taken the wrong way, but we've already had eight=20 >really informative responses to this survey. It would be=20 >useful to understand what you're interested in solving within=20 >this working group versus just hearing the belief that the=20 >survey is broken. :) > >Cheers, >--David > >On Sun, Feb 21, 2010 at 8:12 AM, Tschofenig, Hannes (NSN -=20 >FI/Espoo) <hannes.tschofenig@nsn.com> wrote: >> Hi Eran, >> >> There are a couple of problems with this survey. See below >> >>>-----Original Message----- >>>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 >On Behalf=20 >>>Of ext Eran Hammer-Lahav >>>Sent: 18 February, 2010 19:14 >>>To: OAuth WG (oauth@ietf.org) >>>Subject: [OAUTH-WG] WG Survey >>> >>>A few questions we should answer before moving forward. >>>Considering *your* use cases and reasons for being here: >>> >>>1. Why are you here? What are you trying to solve that is=20 >not already=20 >>>addressed by existing specifications (OAuth 1.0a, WRAP, etc)? >> >> During the conference call we figured out that there is no way one=20 >> would easily agree to a single scenario or deployment variant. >> >> This is where some the disagreements come from. Some folks have the=20 >> super-secure governmental application in mind, others want=20 >to support=20 >> the enterprise environment which are able to spend a lot of money on=20 >> security, and then there are others that focus on the web developer=20 >> that does not have even money for the certs. >> >> How do you want to provide a solution that fits everyone? Not really=20 >> possible IMHO (unless you introduce the notion of "profiles"). >> >>> >>>2. Should the WG start by taking WRAP or OAuth 1.0a as its starting=20 >>>point? Something else? >> >> Largely irrelevant as the content will change anyway >> >>> >>>3. If we start from draft-hammer-oauth, what needs to change to turn=20 >>>it into OAuth 2.0? >> >> Depends on the scenarios you want to cover under item (1). >> >>> >>>4. If we start from draft-hardt-oauth, what needs to change=20 >to turn it=20 >>>into OAuth 2.0? >> >> >> Depends on the scenarios you want to cover under item (1). >> >>> >>>5. Do you think the approach of working first on 'how to use=20 >a token'=20 >>>and then on 'how to get a token' is right? >> >> Nope. First, you have to figure out what you want the=20 >specification to=20 >> accomplish. >> >> >>> >>>6. Should we go back to working on a single specification? >> >> Does not matter. This is purely a document management / authorship=20 >> question that would come last. >> >>> >>>7. Do you think the protocol should include a signature-based=20 >>>authentication scheme? >> >> That depends on the scenarios you want to cover. >> >> Ciao >> Hannes >> >>> >>>EHL >>>_______________________________________________ >>>OAuth mailing list >>>OAuth@ietf.org >>>https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From Bart.bv.Vrancken@alcatel-lucent.com Mon Feb 22 00:50:53 2010 Return-Path: <Bart.bv.Vrancken@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B176928B797 for <oauth@core3.amsl.com>; Mon, 22 Feb 2010 00:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C10wnxd+MXj5 for <oauth@core3.amsl.com>; Mon, 22 Feb 2010 00:50:53 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id A4A013A70E2 for <oauth@ietf.org>; Mon, 22 Feb 2010 00:50:52 -0800 (PST) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1M8qlfr001715 for <oauth@ietf.org>; Mon, 22 Feb 2010 09:52:48 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 09:52:36 +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: Mon, 22 Feb 2010 09:52:35 +0100 Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E04A49D65@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] WG Survey Thread-Index: AcqwvdIpwql/pJksQI6hDRprwnPDjAC3DCgA References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "Vrancken Bart bv" <Bart.bv.Vrancken@alcatel-lucent.com> To: <oauth@ietf.org> X-OriginalArrivalTime: 22 Feb 2010 08:52:36.0549 (UTC) FILETIME=[617F6750:01CAB39C] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 08:50:53 -0000 Hello folks, >A few questions we should answer before moving forward. Considering *your* >use cases and reasons for being here: > >1. Why are you here? What are you trying to solve that is not already >addressed by existing specifications (OAuth 1.0a, WRAP, etc)? I am here because I support open standards and would like to see some improvements/additions to the protocol. Recursive delegation is the main pain point that I want to address (see the ID of redelegation)=20 This is important for Mesh-ups or for content managers that use different services to have good interoperability with the different providers. WRAP could help here for TLS-enabled environments, but there are use cases where you don't have such an environment.=20 >2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? >Something else? Or we start a new document, combining the different ID's or we should start from our previous "consensus" around OAuth 1.0a >3. If we start from draft-hammer-oauth, what needs to change to turn it >into OAuth 2.0? The idea of Resource Owner Authorization should be adapted to provide a clean way to do the recursive delegation flow. Replacing the "PLAINTEXT"-method with WRAP >4. If we start from draft-hardt-oauth, what needs to change to turn it into >OAuth 2.0? I see WRAP as a nice replacement for the "PLAINTEXT"-method, so the other cases should be added. >5. Do you think the approach of working first on 'how to use a token' and >then on 'how to get a token' is right? There should be a simple spec having the whole flow, instead that you should read different documents to get a feeling of what there is written. Maybe the split could be used, if there is a third document that glues them together with a clear vision/use case. >6. Should we go back to working on a single specification? See previous answer >7. Do you think the protocol should include a signature-based >authentication scheme? Yes. Best regards, Bart Vrancken From James.H.Manger@team.telstra.com Mon Feb 22 05:04:52 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E46028C2DA for <oauth@core3.amsl.com>; Mon, 22 Feb 2010 05:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiOu+VlKczPb for <oauth@core3.amsl.com>; Mon, 22 Feb 2010 05:04:51 -0800 (PST) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id 0A92728C189 for <oauth@ietf.org>; Mon, 22 Feb 2010 05:04:49 -0800 (PST) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbi.ntcif.telstra.com.au with ESMTP; 23 Feb 2010 00:06:46 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id B08FCFF81 for <oauth@ietf.org>; Tue, 23 Feb 2010 00:06:45 +1100 (EST) Received: from WSMSG3702.srv.dir.telstra.com (wsmsg3702.srv.dir.telstra.com [172.49.40.170]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 764F941E79 for <oauth@ietf.org>; Tue, 23 Feb 2010 00:06:14 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Tue, 23 Feb 2010 00:06:45 +1100 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Tue, 23 Feb 2010 00:06:41 +1100 Thread-Topic: WG Survey Thread-Index: AcqwvdIpwql/pJksQI6hDRprwnPDjAC+SRpQ Message-ID: <255B9BB34FB7D647A506DC292726F6E11250A290E4@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {44D73B2A-0A07-47DB-8FCB-3D3400B9694A} x-cr-hashedpuzzle: A76p BBsv D0OY EgK8 FakT F3g8 GVUl GuMi InMG I/os Jg+6 KHFM Ka2b LVhS Lc1J Lxyt; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {44D73B2A-0A07-47DB-8FCB-3D3400B9694A}; agBhAG0AZQBzAC4AaAAuAG0AYQBuAGcAZQByAEAAdABlAGEAbQAuAHQAZQBsAHMAdAByAGEALgBjAG8AbQA=; Mon, 22 Feb 2010 13:06:41 GMT;UgBFADoAIABXAEcAIABTAHUAcgB2AGUAeQA= acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 13:04:52 -0000 PiBBIGZldyBxdWVzdGlvbnMgd2Ugc2hvdWxkIGFuc3dlciBiZWZvcmUgbW92aW5nIGZvcndhcmQu IENvbnNpZGVyaW5nDQo+ICp5b3VyKiB1c2UgY2FzZXMgYW5kIHJlYXNvbnMgZm9yIGJlaW5nIGhl cmU6DQo+IA0KPiAxLiBXaHkgYXJlIHlvdSBoZXJlPyBXaGF0IGFyZSB5b3UgdHJ5aW5nIHRvIHNv bHZlIHRoYXQgaXMgbm90IGFscmVhZHkNCj4gYWRkcmVzc2VkIGJ5IGV4aXN0aW5nIHNwZWNpZmlj YXRpb25zIChPQXV0aCAxLjBhLCBXUkFQLCBldGMpPw0KDQpJIGFtIGhlcmUgYmVjYXVzZSBkZWxl Z2F0aW9uIGlzIHJlYWxseSBpbXBvcnRhbnQgZnVuY3Rpb25hbGl0eSBmb3IgdGhlIHdlYi4NCkkg d2FudCBkZWxlZ2F0aW9uIGZ1bmN0aW9uYWxpdHkgdGhhdCBjYW4gd29yayBldmVuIHdoZW4gYSBj bGllbnQgaGFzIG5vdCBiZWVuIHByZS1yZWdpc3RlcmVkIHdpdGggYSBzZXJ2aWNlLg0KSSB3YW50 IGRlbGVnYXRpb24gZnVuY3Rpb25hbGl0eSB0aGF0IGZpdHMgd2VsbCB3aXRoIHRoZSBzdHlsZSBv ZiB0aGUgd2ViIChwYXJ0aWN1bGFybHkgSFRUUCkuDQpJIHdhbnQgYSBsb2dpY2FsbHkgY2xlYW4g cHJvdG9jb2wgZm9yIHRoZSBiZXN0IGNoYW5jZSBvZiBiZWluZyBhcHBsaWNhYmxlIHRvIGEgdmFy aWV0eSBvZiBzY2VuYXJpb3MgKGVnIGRlY291cGxlIGF1dGh6IGFuZCBhdXRobiwgbWluaW1hbCBz cG90cyBmb3Igc2VydmljZS1zcGVjaWZpYyAiYWRkaXRpb25hbCBwYXJhbXMiKS4NCg0KDQo+IDIu IFNob3VsZCB0aGUgV0cgc3RhcnQgYnkgdGFraW5nIFdSQVAgb3IgT0F1dGggMS4wYSBhcyBpdHMg c3RhcnRpbmcNCj4gcG9pbnQ/IFNvbWV0aGluZyBlbHNlPw0KDQpXUkFQIGlzIHByb2JhYmx5IGEg YmV0dGVyIHN0YXJ0aW5nIHBvaW50Lg0KDQoNCj4gMy4gSWYgd2Ugc3RhcnQgZnJvbSBkcmFmdC1o YW1tZXItb2F1dGgsIHdoYXQgbmVlZHMgdG8gY2hhbmdlIHRvIHR1cm4gaXQNCj4gaW50byBPQXV0 aCAyLjA/DQoNClJlbW92ZSB0aGUgcmVxdWVzdCBzaWduaW5nIG1lY2hhbmlzbXMuDQoNCj4gNC4g SWYgd2Ugc3RhcnQgZnJvbSBkcmFmdC1oYXJkdC1vYXV0aCwgd2hhdCBuZWVkcyB0byBjaGFuZ2Ug dG8gdHVybiBpdA0KPiBpbnRvIE9BdXRoIDIuMD8NCg0KU2VwYXJhdGUgdXNlci9jbGllbnQvc2Vy dmVyIGRlbGVnYXRpb24gZnJvbSBjbGllbnQvc2VydmVyIGNyZWRlbnRpYWwgcmVmcmVzaCAtLSBJ IGFtIG5vdCBzdXJlIHRoZXkgYXJlIGFzIHJlbGF0ZWQgYXMgV1JBUCBtYWtlcyBvdXQuDQoNCkJl dHRlciA0MDEgVW5hdXRob3JpemVkIFdXVy1BdXRoZW50aWNhdGUgcmVzcG9uc2VzIChub3QganVz dCAiV1JBUCIgZm9yIGV2ZXJ5dGhpbmcpLg0KDQoiRGlzY292ZXJ5IiAod2l0aGluIGRpcmVjdCBI VFRQIHJlcXVlc3QvcmVzcG9uc2UgZmxvdyk6IG9mIHJlZGlyZWN0IFVSSXMsIG9mIGF1dGhlbnRp Y2F0aW9uIG1lY2hhbmlzbXMsIG9mIHRoZSBkb21haW5zIHdoZXJlIGEgdG9rZW4gY2FuIGJlIHVz ZWQuLi4NCg0KDQo+IDUuIERvIHlvdSB0aGluayB0aGUgYXBwcm9hY2ggb2Ygd29ya2luZyBmaXJz dCBvbiAnaG93IHRvIHVzZSBhIHRva2VuJw0KPiBhbmQgdGhlbiBvbiAnaG93IHRvIGdldCBhIHRv a2VuJyBpcyByaWdodD8NCg0KTm8uDQpBcyBsb25nIGFzICJob3cgdG8gZ2V0IGEgdG9rZW4iIGNh biByZXN1bHQgaW4gYW4gYXV0aHogdG9rZW4gKCYgc29tZSBtZXRhZGF0YSkgb3IgYW4gaWQgcGx1 cyBzZWNyZXQga2V5ICgmIHNvbWUgbWV0YWRhdGEpIHRoZW4gYW55IG51bWJlciBvZiBkaWZmZXJl bnQgYXBwcm9hY2hlcyBjYW4gYmUgYWRvcHRlZCBmb3IgImhvdyB0byB1c2UgYSB0b2tlbiIgLS0g YW5kIHRoZXkgY2FuIGJlIGNob3NlbiBhdCBhbnkgdGltZSwgYnkgYW55b25lLg0KDQpJdCB3b3Vs ZCBiZSBuaWNlIHRvIGhhdmUgb25lIHNpbXBsZSAiaG93IHRvIHVzZSBhIHRva2VuIiBvcHRpb24g c3BlY2lmaWVkIHVwIGZyb250IC0tIGllIGEgYmVhcmVyIHRva2VuIHNjaGVtZSAtLSBzbyB5b3Ug Y2FuIHZpc3VhbGlzZSBhIGNvbXBsZXRlIGRlbGVnYXRpb24gZmxvdy4NCg0KIA0KPiA2LiBTaG91 bGQgd2UgZ28gYmFjayB0byB3b3JraW5nIG9uIGEgc2luZ2xlIHNwZWNpZmljYXRpb24/DQoNCk5v Lg0KQSBzZXBhcmF0ZSBzcGVjIGp1c3QgZm9yIHRyYW5zbWl0dGluZyBhIGJlYXJlciB0b2tlbiB3 b3VsZCBiZSB1c2VmdWwgKGFuZCBzaG9ydCkuDQoNCj4gNy4gRG8geW91IHRoaW5rIHRoZSBwcm90 b2NvbCBzaG91bGQgaW5jbHVkZSBhIHNpZ25hdHVyZS1iYXNlZA0KPiBhdXRoZW50aWNhdGlvbiBz Y2hlbWU/DQoNCk5vLg0KVGhlIGRlbGVnYXRpb24gcHJvdG9jb2wgc2hvdWxkIGJlIGNhcGFibGUg b2Ygd29ya2luZyB3aXRoIHNpZ25hdHVyZS1iYXNlZCBhdXRoIHNjaGVtZXMuDQpBbnkgbnVtYmVy IG9mIHNpZ25hdHVyZSBzY2hlbWVzIGNhbiBiZSBkZWZpbmVkIHNlcGFyYXRlbHkgaWYgdGhlcmUg aXMgYWdyZWVtZW50IG9uIHdoYXQgdG8gc2lnbiAoVVJJLCBob3N0LCBoZWFkZXJzLCBib2R5Li4u KSwgd2hhdCB0byBzaWduIHdpdGggKHBhc3N3b3JkLCBzaGFyZWQgc2VjcmV0LCBwdWJsaWMga2V5 IGNyeXB0by4uLiksIHdoYXQgc2VjdXJpdHkgdG8gb2ZmZXIgKHVzZXIgYXV0aCwgZGF0YSBvcmln aW4gYXV0aCwgY29uZmlkZW50aWFsaXR5LCByZXBsYXkgcHJvdGVjdGlvbiwgd2l0aCBvciB3aXRo b3V0IGNsb2NrcywgemVyby1rbm93bGVkZ2UgcHJvb2YuLi4pLCB3aGF0IHBlcmZvcm1hbmNlIGlz IGltcG9ydGFudCAobGF0ZW5jeSwgcm91bmQgdHJpcHMsIDEtcGFzcy4uLiksIGFuZCB3aGF0IG9w ZXJhdGlvbmFsIHNlY3VyaXR5IGlzIHBvc3NpYmxlIChub25jZXMsIGNsZWFydGV4dCBrZXlzLCBz aG9ydC10ZXJtIGtleXMuLi4pDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From tonynad@microsoft.com Mon Feb 22 07:45:06 2010 Return-Path: <tonynad@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C87628C1D5 for <oauth@core3.amsl.com>; Mon, 22 Feb 2010 07:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.465 X-Spam-Level: X-Spam-Status: No, score=-10.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUMvjVYYHgHH for <oauth@core3.amsl.com>; Mon, 22 Feb 2010 07:45:05 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 62D5B28C1C6 for <oauth@ietf.org>; Mon, 22 Feb 2010 07:45:05 -0800 (PST) Received: from TK5EX14CASC129.redmond.corp.microsoft.com (157.54.52.7) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 22 Feb 2010 07:46:55 -0800 Received: from TK5EX14MBXC103.redmond.corp.microsoft.com ([169.254.3.187]) by TK5EX14CASC129.redmond.corp.microsoft.com ([157.54.52.7]) with mapi; Mon, 22 Feb 2010 07:46:39 -0800 From: Anthony Nadalin <tonynad@microsoft.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Thread-Topic: WG Survey Thread-Index: AcqwvdIpwql/pJksQI6hDRprwnPDjAA3jrWg Date: Mon, 22 Feb 2010 15:46:38 +0000 Message-ID: <A08279DC79B11C48AD587060CD9397711AFCD9E5@TK5EX14MBXC103.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 15:45:06 -0000 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, February 18, 2010 9:14 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] WG Survey A few questions we should answer before moving forward. Considering *your* = use cases and reasons for being here: >1. Why are you here? What are you trying to solve that is not already addr= essed by existing specifications (OAuth 1.0a, WRAP, etc)? To further a specification to cover use cases that have emerged. WRAP curre= ntly covers those use cases and OAuth 1.0a does not. >2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point?= Something else? WRAP=20 >3. If we start from draft-hammer-oauth, what needs to change to turn it in= to OAuth 2.0? Remove the request signing mechanisms >4. If we start from draft-hardt-oauth, what needs to change to turn it int= o OAuth 2.0? >5. Do you think the approach of working first on 'how to use a token' and = then on 'how to get a token' is right? How to use a token may not be the right thing to concentrate on as I can se= e different tokens for different uses, so would support an emphasis on 'how= to get a token' >6. Should we go back to working on a single specification? If we can get agreement on the use cases and agree on the function/features= , makes sense >7. Do you think the protocol should include a signature-based authenticati= on scheme? Not a required item From esjewett@gmail.com Mon Feb 22 09:08:27 2010 Return-Path: <esjewett@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BAA228C32F for <oauth@core3.amsl.com>; Mon, 22 Feb 2010 09:08:27 -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 wm6QkO4BpYwH for <oauth@core3.amsl.com>; Mon, 22 Feb 2010 09:08:26 -0800 (PST) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by core3.amsl.com (Postfix) with ESMTP id AC41628C32E for <oauth@ietf.org>; Mon, 22 Feb 2010 09:08:26 -0800 (PST) Received: by pzk33 with SMTP id 33so120821pzk.5 for <oauth@ietf.org>; Mon, 22 Feb 2010 09:10:23 -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=1XCEGuBhkU3C4D3ZMt/eOS1tbhmomFOC9UGWX9/8f2g=; b=neJ0dao0FXsh0lTC55sOCR0PXXnbegTIaO44YHgoq/jNIGjgkl7QycAjFFLC536VI7 7nlY9AHhwKGKxoUTzMREuv07evg2xEJxM7UsMWszYVOqcbPKpb2boewWtIXpL3rSx62a SZxTnyg2DOJv1o7nPVVO4k2iGbBT3mJb49mNU= 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=lB9dOrvoeRIDD9hSP67hvrNz/edyUlH10WkCXJ0pNP49VPkrBYJTUKcOzR+qf+eadS UrMIFJf4dqnt+c+emNT+QlhHY9ahnsaJ6oZyQF+hqqGlXNpHZ4Kesc40mIcG8a4Vue6y JLVnjkBjkcz/SjFKEA6D0KyLgwOK4wb9g7qOw= MIME-Version: 1.0 Received: by 10.141.187.13 with SMTP id o13mr9138150rvp.28.1266858622749; Mon, 22 Feb 2010 09:10:22 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AcqwvdIpwql/pJksQI6hDRprwnPDjA==> <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 22 Feb 2010 11:10:22 -0600 Message-ID: <68f4a0e81002220910q3886533fy5e4ff21857c5aef9@mail.gmail.com> From: Ethan Jewett <esjewett@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 17:08:27 -0000 On Thu, Feb 18, 2010 at 11:14 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > A few questions we should answer before moving forward. Considering *your* use cases and reasons for being here: > > 1. Why are you here? What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)? OAuth 1.0a already meets most of my needs, but I think that there is room for improvement, clarification, and simplification, especially around key/token/secret acquisition and management and around the PLAINTEXT method. > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? Something else? On the resource access side, OAuth 1.0a. WRAP does not address the signature methods at all, so I do not think it is a good starting point. On the access token acquisition side, the WRAP profile approach makes a lot of sense in that it acknowledges and takes on the complexity of acquiring a token in different scenarios. However, I think we would still need to define something which the different profiles are ... profiling ... so we probably need to start from OAuth 1.0a and add on the profiles. Perhaps it makes sense to publish the profiles as separate documents instead of as part of the main document, but I'd think they need to be developed in parallel. > 3. If we start from draft-hammer-oauth, what needs to change to turn it into OAuth 2.0? I haven't gotten to thoroughly review the current draft, but from my point of view it looks pretty good from the resource access perspective. If replacing the entire PLAINTEXT flow with WRAP would make people happy, then I would be for that, but I don't see much difference between them. I think it really depends on what current implementations use WRAP (not sure about the number) vs. OAuth 1.0a PLAINTEXT (not many to my knowledge). > 4. If we start from draft-hardt-oauth, what needs to change to turn it into OAuth 2.0? I haven't been able to review this draft in detail. I like the profiling approach to a certain extent, but the fact that it completely ignores the signature scenario (and thereby ignores the vast majority of OAuth deployments as far as I can tell) is extremely problematic when considering it as a starting point. > 5. Do you think the approach of working first on 'how to use a token' and then on 'how to get a token' is right? Yes. I think that as long as we are agreed that a single access token is being used and that token is opaque to the client, then this approach makes sense. > 6. Should we go back to working on a single specification? I'm in the "no" camp, but mostly for logistical reasons. I have a hard time reading through a new draft of a specification that includes both pieces. It is worth noting that there was (IIRC) some confusion in the OAuth community, especially around signature calculation, that seemed to be caused by having both parts of the OAuth model in one document. People had a hard time understanding that the token acquisition flow and the resource request were very different animals. > 7. Do you think the protocol should include a signature-based authentication scheme? Absolutely. It's worth noting that OAuth 1.0a had a PLAINTEXT method similar to WRAP. As far as I can tell, it would have been possible for WRAP to define its resource access method to be compatible with the OAuth 1.0a PLAINTEXT method. I only say this to point out that none of the main OAuth implementations support the PLAINTEXT method to my knowledge, even though they could have done so. I think there are a lot of reasons one would want to use a signature method over the PLAINTEXT method or WRAP (and there are a lot of reasons in the other direction). But this is just a survey, so that answer is plenty long enough :-) Ethan From stpeter@stpeter.im Mon Feb 22 16:00:34 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA9628C462 for <oauth@core3.amsl.com>; Mon, 22 Feb 2010 16:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 ZcrYsPtK8JKM for <oauth@core3.amsl.com>; Mon, 22 Feb 2010 16:00:33 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5E1C928C454 for <oauth@ietf.org>; Mon, 22 Feb 2010 16:00:33 -0800 (PST) Received: from dhcp-64-101-72-201.cisco.com (dhcp-64-101-72-201.cisco.com [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2B6DB40126 for <oauth@ietf.org>; Mon, 22 Feb 2010 17:02:33 -0700 (MST) Message-ID: <4B831B18.3020101@stpeter.im> Date: Mon, 22 Feb 2010 17:02:32 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020307020908050507060605" Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 00:00:34 -0000 This is a cryptographically signed message in MIME format. --------------ms020307020908050507060605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/18/10 10:14 AM, Eran Hammer-Lahav wrote: > A few questions we should answer before moving forward. Eran, I think those were good questions. I've summarized the list feedback so far below. I'm out of time for the moment, but will reply with some of my own thoughts soon... > Considering *your* use cases and reasons for being here: >=20 > 1. Why are you here? Reasons include: - need to build applications on top of OAuth - interested in token-based infrastructures - interested in non-web applications - want to simplify the architecture - concerned about security issues - want an extension for passing around signed identity claims - want to build Internet-scale applications - seeking greater simplicity - see a need for a widespread authn/authz technology - concerned about fragmentation / care about open standards > What are you trying to solve that is not already addressed by=20 > existing specifications (OAuth 1.0a, WRAP, etc)? Problems include: - 1.0a doesn't easily support distributed policy enforcement - there is a lot of potential beyond the use cases covered in 1.0a - need improved support for central authorization services - protected resource needs to know consumer key and secret (security issu= e) - should be an option to pass a bearer token over an encrypted channel - in some environments it is difficult to revoke access tokens - need support for asymmetric secrets to avoid client registration - OAuth 1.0a flow is too complex - too many round trips - doesn't support non-web use cases very well - need more pictures / flow diagrams to make it more readable - integrate better with OpenID - the problems depend on the use cases (define those first) - recursive delegation is undefined - optimize for the web - support more use cases than defined in 1.0a - clarify what we have in 1.0a > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting=20 > point? Something else? Both: 5 (take the best parts from each document) WRAP: 4 Either: 2 (just start with use cases!) OAuth 1.0a: 2 > 3. If we start from draft-hammer-oauth, what needs to change to turn > it into OAuth 2.0? - separation of token issuance (delegation) and request authentication - abstract token format w. concrete minimum supportable set - token usage profiles (e.g. bearer vs. symmetric key vs. asymmetric) - add the flows from WRAP - add a new message format for signing - don't require client credentials to access protected resources - replace PLAINTEXT with a simpler bearer token format or WRAP/TLS - better separation of authorization (get a token) from authentication (use a token) - remove signing requests - keep signing requests but simplify > 4. If we start from draft-hardt-oauth, what needs to change to turn=20 > it into OAuth 2.0? - to support message signing, authorization servers should optionally issue token secrets - more clearly explain the architecture, especially how the token issuer can be separate from the resource server - improve security considerations - add non-PLAINTEXT use cases - separate user/client/server delegation from client/server credential refresh - better 401 Unauthorized WWW-Authenticate responses - discovery of redirect URIs, of authentication mechanisms, of the domains where a token can be used - need support for signed requests (majority of deployments) > 5. Do you think the approach of working first on 'how to use a token' > and then on 'how to get a token' is right? No: 7 Yes: 3 Abstain / Unsure: 3 considerations: - these steps are interdependent - more productive to start from either WRAP or OAuth 1.0a and iterate - hard to compare this approach to a more integrated approach - it all depends on the goals and use cases - OK to have many ways to use a token - need simple bearer token to define the entire flow > 6. Should we go back to working on a single specification? Yes: 8 No: 2 Doesn't matter: 2 Abstain / Unsure: 1 > 7. Do you think the protocol should include a signature-based=20 > authentication scheme? Yes: 10 No / make it optional: 2 Depends on use cases: 1 /psa --------------ms020307020908050507060605 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 hvcNAQkFMQ8XDTEwMDIyMzAwMDIzMlowIwYJKoZIhvcNAQkEMRYEFOI25gRS1HrPm+gZB7WR V/sASTNZMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAafQUP6t6BXP1ndgwo21JiS0HbiRuGkekznRpZke/ NDyjfitk8kQWFiYaTDPNlhLq1jUM84tpywnvztKi2pxHMgKjfPB8J8+uJ8BZY/R8Jjl/UL54 ZCrdIb4CNnbPDviMjPsgigZInibsZz9L5bNU4ARdskMpBOp1N+AYWxxZgO1neEq9BzZ+yTJ7 HV5MqE+UhLwUL2LHlnfNSfKLSvRjGwZ6FwfnGmEX5Fayc+WscBYx6QUL+2X1TV6cpTpuUbzo yU3BdKd+NpJ1h7vjOllZRO1Fc9/eRAfan2j2AorRAWA8HTnTmRehE8J+ghcKJbVKIKkuA8QO 01GUszsG8faQ0gAAAAAAAA== --------------ms020307020908050507060605-- From igor.faynberg@alcatel-lucent.com Tue Feb 23 12:38:08 2010 Return-Path: <igor.faynberg@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1693A8225 for <oauth@core3.amsl.com>; Tue, 23 Feb 2010 12:38:08 -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 CphR1q7IAiwR for <oauth@core3.amsl.com>; Tue, 23 Feb 2010 12:38:08 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 0D9A03A7C42 for <oauth@ietf.org>; Tue, 23 Feb 2010 12:38:07 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o1NKe83i011825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 14:40:08 -0600 (CST) Received: from [135.244.4.209] (faynberg.lra.lucent.com [135.244.4.209]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o1NKe7r1006289; Tue, 23 Feb 2010 14:40:08 -0600 (CST) Message-ID: <4B843D27.4040005@alcatel-lucent.com> Date: Tue, 23 Feb 2010 15:40:07 -0500 From: Igor Faynberg <igor.faynberg@alcatel-lucent.com> Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ext Eran Hammer-Lahav <eran@hueniverse.com>, oauth@ietf.org References: <90C41DD21FB7C64BB94121FBBC2E72343864B479DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4502389244@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502389244@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [OAUTH-WG] WG Survey X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 20:38:09 -0000 >> >> 1. Why are you here? What are you trying to solve that is not >> already addressed by existing specifications (OAuth 1.0a, WRAP, etc)? >> I am working on the security aspects of identity management, and I find that OAuth is trying to solve an essential piece of the puzzle there as far as delegation is concerned. I also observe that telecom providers--my customers--are interested in OAuth (and may be seeing there what I don't yet see). This is another motivation for me--I am very interested in integrating telecom and Web 2.0. (In fact, I started in the IETF 14 years ago by bringing that proposal...) > > > >> 2. Should the WG start by taking WRAP or OAuth 1.0a as its >> starting point? Something else? >> > > Something else: Use cases and the requirements. The WG must produce the requirements based on agreed use cases. Now, it is absolutely clear that both the WRAP and 1.0 people will ensure that their interests and agendas are reflected in the requirements, and this is fine, this is how we will ensure that OAuth WG synthesize both. Personally, I think that WRAP is much cleaner than OAuth 1.0, and I like clean things. But I also see some cases where WRAP would not be applicable. To this end, use cases is the best mechanism to express the vision of the WG. I would start with them first (in the informational RFC), meaning that the can be developed in parallel with the requirements. I don't think Hannes said that in exactly same words, but I suspect that he and I have the same idea here. >> 3. If we start from draft-hammer-oauth, what needs to change >> to turn it into OAuth 2.0? >> >> 4. If we start from draft-hardt-oauth, what needs to change to >> turn it into OAuth 2.0? >> (Since I chose the "something else" option in item 2, questions 3 and 4 are not applicable.) > > > >> 5. Do you think the approach of working first on 'how to use a >> token' and then on 'how to get a token' is right? >> > > Maybe. But even then, once it is clear' how to use a token', when working on 'how to get a token' this clarity will be less apparent, so this subject would need to be revisited.. When you do things like that, there is always a recursion (and it is not bad). To make things more effective, I strongly agree with Hannes that the objectives (in terms of use cases and requirements) must come first. > >> 6. Should we go back to working on a single specification? >> > > I am not sure that this should be an objective. Of course, if everything is simple, and there is a consensus, this is the best way. But it does not appear to me that there is a consensus, and if this is the case, it will be impossible to force one specification. In fact, there has been a precedent in the IETF where more than one solution was developed and it was left to the market to choose one. >> 7. Do you think the protocol should include a signature-based >> authentication scheme? >> ABSOLUTELY. I thought there has been a good discussion on that, and all the arguments are on the table. Respectfully submitted by Igor Faynberg From email@pbryan.net Wed Feb 24 09:28:13 2010 Return-Path: <email@pbryan.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A1728C1E1 for <oauth@core3.amsl.com>; Wed, 24 Feb 2010 09:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSNfo4wjGY19 for <oauth@core3.amsl.com>; Wed, 24 Feb 2010 09:28:12 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 6037F28C14B for <oauth@ietf.org>; Wed, 24 Feb 2010 09:28:12 -0800 (PST) Received: from [192.168.0.7] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id EA4A1EA021 for <oauth@ietf.org>; Wed, 24 Feb 2010 17:30:18 +0000 (UTC) From: "Paul C. Bryan" <email@pbryan.net> To: oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Wed, 24 Feb 2010 09:30:17 -0800 Message-ID: <1267032617.14335.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] OAuth XRD? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 24 Feb 2010 17:28:13 -0000 This is a message directed mostly at Eran: Is the OAuth 2.0 discovery mechanism still expected to be via a "provider" attribute in the WWW-Authenticate header, or is host-meta expected to take over? Paul From eran@hueniverse.com Wed Feb 24 18:38:23 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C83D28C2B5 for <oauth@core3.amsl.com>; Wed, 24 Feb 2010 18:38:23 -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 KB0P+8x2dquN for <oauth@core3.amsl.com>; Wed, 24 Feb 2010 18:38:22 -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 96EF028C2B3 for <oauth@ietf.org>; Wed, 24 Feb 2010 18:38:22 -0800 (PST) Received: (qmail 19317 invoked from network); 25 Feb 2010 02:40:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Feb 2010 02:40:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 24 Feb 2010 19:40:31 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "Paul C. Bryan" <email@pbryan.net>, "oauth@ietf.org" <oauth@ietf.org> Date: Wed, 24 Feb 2010 19:40:23 -0700 Thread-Topic: [OAUTH-WG] OAuth XRD? Thread-Index: Acq1dyNJWwEBfKycRjqNSCg9q6BBfwATHKqQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438D923AAF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1267032617.14335.11.camel@localhost> In-Reply-To: <1267032617.14335.11.camel@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth XRD? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 02:38:23 -0000 No idea. I am not sure yet what the discovery requirements are. For example= , are clients expected to be familiar with each of the token-obtaining prof= iles and just need a single URI for each supported mechanism? XRD is useful= for describing a bunch of links for such endpoints, but it might just be t= hat the discovery information can be provided directly in the header. Until we know what OAuth 2.0 looks like, we can't really discuss discovery = much. Is there a reason why you are asking now? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Paul C. Bryan > Sent: Wednesday, February 24, 2010 9:30 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] OAuth XRD? >=20 > This is a message directed mostly at Eran: >=20 > Is the OAuth 2.0 discovery mechanism still expected to be via a "provider= " > attribute in the WWW-Authenticate header, or is host-meta expected to > take over? >=20 > Paul >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From email@pbryan.net Wed Feb 24 18:56:03 2010 Return-Path: <email@pbryan.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BCE28C199 for <oauth@core3.amsl.com>; Wed, 24 Feb 2010 18:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 guIE9xyrCDJi for <oauth@core3.amsl.com>; Wed, 24 Feb 2010 18:56:00 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 1319928C251 for <oauth@ietf.org>; Wed, 24 Feb 2010 18:55:59 -0800 (PST) Received: from [192.168.0.5] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 2C1CBEA021 for <oauth@ietf.org>; Thu, 25 Feb 2010 02:58:08 +0000 (UTC) From: "Paul C. Bryan" <email@pbryan.net> To: "oauth@ietf.org" <oauth@ietf.org> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723438D923AAF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1267032617.14335.11.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723438D923AAF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Wed, 24 Feb 2010 18:58:06 -0800 Message-ID: <1267066686.9139.9.camel@Dodger> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] OAuth XRD? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 02:56:03 -0000 I've been mostly following the pattern in your XRD-Based OAuth Discovery Sneak Peek, where a client can discover how to interact with an OAuth token service in reaction to the OAuth challenge. What got me second-guessing this was a passing reference to OAuth in the example in XRD version 1.0. I'm asking now because in the process of simplifying the UMA spec, I need to decide on some of the OAuth discovery mechanisms it will use. Paul On Wed, 2010-02-24 at 19:40 -0700, Eran Hammer-Lahav wrote: > No idea. I am not sure yet what the discovery requirements are. For > example, are clients expected to be familiar with each of the > token-obtaining profiles and just need a single URI for each supported > mechanism? XRD is useful for describing a bunch of links for such > endpoints, but it might just be that the discovery information can be > provided directly in the header. > > Until we know what OAuth 2.0 looks like, we can't really discuss > discovery much. > > Is there a reason why you are asking now? > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > > Of Paul C. Bryan > > Sent: Wednesday, February 24, 2010 9:30 AM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] OAuth XRD? > > > > This is a message directed mostly at Eran: > > > > Is the OAuth 2.0 discovery mechanism still expected to be via a > "provider" > > attribute in the WWW-Authenticate header, or is host-meta expected > to > > take over? > > > > Paul > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Wed Feb 24 21:36:45 2010 Return-Path: <jpanzer@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A2C28C0ED for <oauth@core3.amsl.com>; Wed, 24 Feb 2010 21:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.21 X-Spam-Level: X-Spam-Status: No, score=-105.21 tagged_above=-999 required=5 tests=[AWL=0.767, 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 cFuA5Hil3gCi for <oauth@core3.amsl.com>; Wed, 24 Feb 2010 21:36:44 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 1669E3A8626 for <oauth@ietf.org>; Wed, 24 Feb 2010 21:36:43 -0800 (PST) Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id o1P5cpBq029519 for <oauth@ietf.org>; Thu, 25 Feb 2010 05:38:51 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1267076332; bh=DtpESEVUyalXrg4iB1Bx7VJv13Y=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=L471RvUde8ph/8Dh0lh/qeGZvSxkWddGjRKpyPPJqBDjNwWUmaghe9nRRsFe8ltMs 7KTEvzT4y8S58NY+kWvZQ== 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=IpOu9YjAPQnWJjsRs5n2Rgsb/wFm3FrpfZQEZ8o6SeTzt+H3t5+RwT408g9ozSEa6 /AfP5V5Y5i01oKzFkAkXw== Received: from pzk4 (pzk4.prod.google.com [10.243.19.132]) by spaceape7.eur.corp.google.com with ESMTP id o1P5cmvi022019 for <oauth@ietf.org>; Wed, 24 Feb 2010 21:38:50 -0800 Received: by pzk4 with SMTP id 4so279137pzk.21 for <oauth@ietf.org>; Wed, 24 Feb 2010 21:38:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.214.39 with SMTP id r39mr340463rvq.278.1267076328531; Wed, 24 Feb 2010 21:38:48 -0800 (PST) In-Reply-To: <1267066686.9139.9.camel@Dodger> References: <1267032617.14335.11.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723438D923AAF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1267066686.9139.9.camel@Dodger> Date: Wed, 24 Feb 2010 21:38:48 -0800 Message-ID: <cb5f7a381002242138w714a0b23y96070a3cb8cdfabe@mail.gmail.com> From: John Panzer <jpanzer@google.com> To: "Paul C. Bryan" <email@pbryan.net> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth XRD? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 05:36:45 -0000 Www-Authenticate plus Link headers seem like they would involve minimal wheel re-invention. On Wednesday, February 24, 2010, Paul C. Bryan <email@pbryan.net> wrote: > I've been mostly following the pattern in your XRD-Based OAuth Discovery > Sneak Peek, where a client can discover how to interact with an OAuth > token service in reaction to the OAuth challenge. What got me > second-guessing this was a passing reference to OAuth in the example in > XRD version 1.0. > > I'm asking now because in the process of simplifying the UMA spec, I > need to decide on some of the OAuth discovery mechanisms it will use. > > Paul > > On Wed, 2010-02-24 at 19:40 -0700, Eran Hammer-Lahav wrote: >> No idea. I am not sure yet what the discovery requirements are. For >> example, are clients expected to be familiar with each of the >> token-obtaining profiles and just need a single URI for each supported >> mechanism? XRD is useful for describing a bunch of links for such >> endpoints, but it might just be that the discovery information can be >> provided directly in the header. >> >> Until we know what OAuth 2.0 looks like, we can't really discuss >> discovery much. >> >> Is there a reason why you are asking now? >> >> EHL >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> Behalf >> > Of Paul C. Bryan >> > Sent: Wednesday, February 24, 2010 9:30 AM >> > To: oauth@ietf.org >> > Subject: [OAUTH-WG] OAuth XRD? >> > >> > This is a message directed mostly at Eran: >> > >> > Is the OAuth 2.0 discovery mechanism still expected to be via a >> "provider" >> > attribute in the WWW-Authenticate header, or is host-meta expected >> to >> > take over? >> > >> > Paul >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From eran@hueniverse.com Wed Feb 24 23:24:50 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05A2B28C155 for <oauth@core3.amsl.com>; Wed, 24 Feb 2010 23:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmG7C9gTL8qa for <oauth@core3.amsl.com>; Wed, 24 Feb 2010 23:24:48 -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 C55E628C142 for <oauth@ietf.org>; Wed, 24 Feb 2010 23:24:48 -0800 (PST) Received: (qmail 19460 invoked from network); 25 Feb 2010 07:26:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Feb 2010 07:26:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 25 Feb 2010 00:26:57 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: John Panzer <jpanzer@google.com>, "Paul C. Bryan" <email@pbryan.net> Date: Thu, 25 Feb 2010 00:26:48 -0700 Thread-Topic: [OAUTH-WG] OAuth XRD? Thread-Index: Acq13NQ46HJQEYdLT/OP4vJJ6A96KgADvCWg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438D923AB2B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1267032617.14335.11.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723438D923AAF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1267066686.9139.9.camel@Dodger> <cb5f7a381002242138w714a0b23y96070a3cb8cdfabe@mail.gmail.com> In-Reply-To: <cb5f7a381002242138w714a0b23y96070a3cb8cdfabe@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth XRD? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 07:24:50 -0000 That's how I feel. In other words, we need to make the protocol configurati= on simple enough that this is all discovery needs. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of John Panzer > Sent: Wednesday, February 24, 2010 9:39 PM > To: Paul C. Bryan > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth XRD? >=20 > Www-Authenticate plus Link headers seem like they would involve minimal > wheel re-invention. >=20 > On Wednesday, February 24, 2010, Paul C. Bryan <email@pbryan.net> > wrote: > > I've been mostly following the pattern in your XRD-Based OAuth > > Discovery Sneak Peek, where a client can discover how to interact with > > an OAuth token service in reaction to the OAuth challenge. What got me > > second-guessing this was a passing reference to OAuth in the example > > in XRD version 1.0. > > > > I'm asking now because in the process of simplifying the UMA spec, I > > need to decide on some of the OAuth discovery mechanisms it will use. > > > > Paul > > > > On Wed, 2010-02-24 at 19:40 -0700, Eran Hammer-Lahav wrote: > >> No idea. I am not sure yet what the discovery requirements are. For > >> example, are clients expected to be familiar with each of the > >> token-obtaining profiles and just need a single URI for each > >> supported mechanism? XRD is useful for describing a bunch of links > >> for such endpoints, but it might just be that the discovery > >> information can be provided directly in the header. > >> > >> Until we know what OAuth 2.0 looks like, we can't really discuss > >> discovery much. > >> > >> Is there a reason why you are asking now? > >> > >> EHL > >> > >> > -----Original Message----- > >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf > >> > Of Paul C. Bryan > >> > Sent: Wednesday, February 24, 2010 9:30 AM > >> > To: oauth@ietf.org > >> > Subject: [OAUTH-WG] OAuth XRD? > >> > > >> > This is a message directed mostly at Eran: > >> > > >> > Is the OAuth 2.0 discovery mechanism still expected to be via a > >> "provider" > >> > attribute in the WWW-Authenticate header, or is host-meta expected > >> to > >> > take over? > >> > > >> > Paul > >> > > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > >=20 > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Thu Feb 25 13:06:36 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B2A28C3DA for <oauth@core3.amsl.com>; Thu, 25 Feb 2010 13:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 V-K8qEB6DhQB for <oauth@core3.amsl.com>; Thu, 25 Feb 2010 13:06:35 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 72E4E28C150 for <oauth@ietf.org>; Thu, 25 Feb 2010 13:06:32 -0800 (PST) Received: from dhcp-64-101-72-201.cisco.com (dhcp-64-101-72-201.cisco.com [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E08D440126 for <oauth@ietf.org>; Thu, 25 Feb 2010 14:08:43 -0700 (MST) Message-ID: <4B86E6DA.6020003@stpeter.im> Date: Thu, 25 Feb 2010 14:08:42 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: OAuth WG <oauth@ietf.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060905000300080602090604" Subject: [OAUTH-WG] proposed agenda for 4th interim meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 21:06:36 -0000 This is a cryptographically signed message in MIME format. --------------ms060905000300080602090604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is a proposed agenda for the 4th interim meeting, to be held next Thursday at 19:00 UTC. ### * Intro * NOTE WELL * Collective note-taking via EtherPad * Agenda bashing * Chair announcement * Impending Area Director change, therefore need for a new co-chair * Discussion of the "WG Survey" thread and results * Discussion of possible goals for Anaheim meeting and possible agenda it= ems * Other business? ### Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060905000300080602090604 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 hvcNAQkFMQ8XDTEwMDIyNTIxMDg0MlowIwYJKoZIhvcNAQkEMRYEFPwudH20u5PaCpAIwoZl qXQkDeq3MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAQnJjp3HiHhUKJNqUUOg5Mu0NatzUrBbP1KibjiQd JexJCOHM4oUwdUwNK6YgahCQcEy3cCWoMkEOOWbnA0v/v/RHljkFcM0eSxH3WyyPhqSYnMpA PITOKguF9zEfKXYSFPWWMlhOy9cV0sRf4UdKAC9HfiVSjqnCIlh8aOnsMrxnKsx3swY9U2CT ymNnjx4gSWmbFNF/icuAJO6ZMr2PrCtKcQMCxOC76w/ksDRNq03LA8cVDVtLZeoTCPv1kehN fbTGW7IkQuUM1xYmy2uQI4+Nxmh33xQYAyMtkHf3JZs7VViXEGmHbe2VtZ5b74z/DgK7yyS3 PllFRLT358Pr9QAAAAAAAA== --------------ms060905000300080602090604-- From stpeter@stpeter.im Thu Feb 25 16:32:16 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626AD28C298 for <oauth@core3.amsl.com>; Thu, 25 Feb 2010 16:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doq8eUMpWNWV for <oauth@core3.amsl.com>; Thu, 25 Feb 2010 16:32:15 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 24F3828C4A1 for <oauth@ietf.org>; Thu, 25 Feb 2010 16:32:15 -0800 (PST) Received: from squire.local (dsl-140-211.dynamic-dsl.frii.net [216.17.140.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CC05D40126 for <oauth@ietf.org>; Thu, 25 Feb 2010 17:34:26 -0700 (MST) Message-ID: <4B871711.80008@stpeter.im> Date: Thu, 25 Feb 2010 17:34:25 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: OAuth WG <oauth@ietf.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060909060907020509030803" Subject: [OAUTH-WG] Fwd: Meeting invitation: OAUTH WG Virtual Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 00:32:16 -0000 This is a cryptographically signed message in MIME format. --------------ms060909060907020509030803 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here are meeting logistics for our virtual interim meeting next Thursday (March 4). /psa -------- Original Message -------- Subject: Meeting invitation: OAUTH WG Virtual Meeting Date: Fri, 19 Feb 2010 06:29:02 GMT From: IETF Secretariat <messenger@webex.com> Reply-To: amorris@amsl.com To: stpeter@stpeter.im Hello , IETF Secretariat invites you to attend this online meeting. Topic: OAUTH WG Virtual Meeting Date: Thursday, March 4, 2010 Time: 7:00 pm, GMT Time (London, GMT) Meeting Number: 961 854 854 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D132105992&UID=3D11162446= 87&RT=3DMiMyMQ%3D%3D <https://workgreen.webex.com/workgreen/j.php?ED=3D132105992&UID=3D1116244= 687&RT=3DMiMyMQ%3D%3D> 2. Enter your name and email address. 3. Enter the meeting password: (This meeting does not require a password.= ) 4. Click "Join Now". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=3D132105992&UID=3D11162446= 87&ORT=3DMiMyMQ%3D%3D <https://workgreen.webex.com/workgreen/j.php?ED=3D132105992&UID=3D1116244= 687&ORT=3DMiMyMQ%3D%3D> ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&E= D=3D132105992&tollFree=3D0 <https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&= ED=3D132105992&tollFree=3D0> Access code:961 854 854 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com <mailto:amorris@amsl.com> 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=3D132105992&UID=3D11162446= 87&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DTrJMhgkOafB81EITQ8lUfMV3Se7J7/HH0= TncQAX1sEk=3D&RT=3DMiMyMQ%3D%3D <https://workgreen.webex.com/workgreen/j.php?ED=3D132105992&UID=3D1116244= 687&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DTrJMhgkOafB81EITQ8lUfMV3Se7J7/HH= 0TncQAX1sEk=3D&RT=3DMiMyMQ%3D%3D> The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. --------------ms060909060907020509030803 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 hvcNAQkFMQ8XDTEwMDIyNjAwMzQyNVowIwYJKoZIhvcNAQkEMRYEFJlPEP4PX8ZVlDAKckhr cMMJ7SO0MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAVVWdlnrQTMNLp6jqy/piBXIQDdx/CVgoiPX1sc2S uM+ghFOElXjDqzm+OpcJScNHQvl4LRbdz19G+M28yoYxL6+Tl0m5Tytn0F6m2ql8wDV/Lqt6 opSQ+EqIdE4bs46pV2T2hbXj6sC91tPq5mMj9Ent9Athnwj1fdBSO8nMKK5opd3TK53rCLaV kyWnWTCgcMB/CuvVk8Vz+gJPtsi9xgAnrFDiNg/XpcLNF7vQV/28Zu5UE90o3ddA8t9w6Ksk dXjBpQGzFkXEA/ic1MLvekJudamtJKC/rHxFx9jBmPAHQ4uAR5JkoMFm9khqKV4m3nWq9gG3 s5TuqReRHNz6lgAAAAAAAA== --------------ms060909060907020509030803-- From y.oiwa@aist.go.jp Fri Feb 26 10:04:22 2010 Return-Path: <y.oiwa@aist.go.jp> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238B728C212 for <oauth@core3.amsl.com>; Fri, 26 Feb 2010 10:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.339 X-Spam-Level: X-Spam-Status: No, score=-4.339 tagged_above=-999 required=5 tests=[AWL=-6.261, BAYES_00=-2.599, FAKE_REPLY_C=2.012, 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 Q7DF1rmPxacs for <oauth@core3.amsl.com>; Fri, 26 Feb 2010 10:04:20 -0800 (PST) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id A9E143A72CD for <oauth@ietf.org>; Fri, 26 Feb 2010 10:04:20 -0800 (PST) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id o1QI6YU1020482 for <oauth@ietf.org>; Sat, 27 Feb 2010 03:06:34 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1267207595; bh=CfIbhUeUe0c8s33fGV/bnxlFz3AGGpTJ2twwKMgJamg=; h=From:Date:Message-ID; b=qEarqvL1T93CvKctPsLvVd8LjSDMPeUKh3krAJgSTebMdCayf4G5v0/OjUB2UkpaU 8wgI7M9Z4LtRF2BTTl+983BCmjZ6qATdEnUTpEB0MbJ6WoHAAlzAcThuWGdnS0pqXB mGXObzJwB4i10Uwqqlxji/leOzUPTmaioA8fiRWc= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id o1QI6YtA006579 for <oauth@ietf.org>; Sat, 27 Feb 2010 03:06:34 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id o1QI6XC6021654 for <oauth@ietf.org>; Sat, 27 Feb 2010 03:06:33 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: OAuth WG <oauth@ietf.org> From: Yutaka OIWA <y.oiwa@aist.go.jp> Date: Sat, 27 Feb 2010 03:06:33 +0900 Message-ID: <87635jan2u.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [OAUTH-WG] draft-oiwa-http-mutualauth-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 18:04:22 -0000 Dear people in OAuth WG mailing list, I recently updated the draft for HTTP Mutual Access Authorization Protocol. The draft is available from IETF website at <http://tools.ietf.org/html/draft-oiwa-http-mutualauth-06>. This protocol was first proposed to the httpbis WG, and as suggested there previously (in IETF 74), I send this to OAuth WG at this time. Although the protocol itself is designed separately from the OAuth protocol, I believe that this protocol is beneficial for many OAuth users. Please take a look on it, and comments are always welcome. This -06 revision is a minor update: I have integrated several useful comments received from many people. I'm very grateful for those comments. I'm going to attend both the OAuth WG and the Httpbis WG at Anaheim, So I'm looking forward to seeing you there. If you're interested, please search for us in Anaheim, and I can make a demonstration there. # The demonstration is also available on our website # <https://www.rcis.aist.go.jp/special/MutualAuth/>, but you will # need to install a browser with the protocol support there. A very short introduction: This protocol provides true mutual authentication between HTTP clients and servers using simple password-based authentication in a very secure way. This protocol enables clients to check whether the SERVER knows the user's entity (encrypted password), and also ensure that the client password itself will not be exposed to a peer server. By using this protocol we can protect the client's passwords from forged (phishing) servers. Furthermore, the mutual authentication provided by this protocol will also protect other important information from phishing attacks. More details are available on the draft and a preprint available from our website <https://www.rcis.aist.go.jp/special/MutualAuth/>. Some issues currently pending: o Format of the "Authentication-Control" header and other header fields extending the general HTTP authentication scheme, and harmonization of those with other draft proposals such as <http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0086.html> and Thomas' 308 status code proposal <http://lists.w3.org/Archives/Public/public-web-security/2010Jan/0001.html>. o Restructuring of the draft, possibly separating it to several parts, e.g. introduction, general HTTP extensions and Mutual authentication. I am currently planning to do it after the harmonization above. -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5]