From nobody Sun Feb 1 16:07:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8891A07BE for ; Sun, 1 Feb 2015 16:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6y8FYqrtdN7 for ; Sun, 1 Feb 2015 16:07:09 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E301A033B for ; Sun, 1 Feb 2015 16:07:09 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id j7so27130701qaq.5 for ; Sun, 01 Feb 2015 16:07:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:cc:to :mime-version; bh=AUc/bESw49K5yrurOc5idBL7MjAvK36M6l9UxBHD9lo=; b=CjTLaLyDq9xrsAp1W9L/QsA+wbW4T7r35K5N7IF6Sz8Br51hE20F/6BH1oZFYt11jm YXbnT7YVzU1BIgCEhZoaos7pr5XVi+hCwt6gdiU92LXIx+QStbEt5O0hescEBnOiZ5u2 KZk5iUf9tJajKcSXGR5suUwPMiWJ9aRNqKmhK1KlBENBVFd1ZETXnCE8mNG9ldG8HGmq nldGx5g1OFvJmmCZjPbVPvaByl7l8CgBq3CHCdSwlhEWvZuIV5s3Mg8eJl8ViWZstFvX 4HqVL3X5nIrJ2RwvmYN6UQ3j6j3bfI0UrSVfnyhcEtvNI2tBoh4G78wG7Qit8o7w6Ip8 KJjA== X-Gm-Message-State: ALoCoQml9/bd75nlCMVLr9wDjolXY9DInqrIYrzgn2SzItuPNVQvNr1W6RdIxlzzolR5Jh/PdHlK X-Received: by 10.140.16.163 with SMTP id 32mr32407731qgb.22.1422835628346; Sun, 01 Feb 2015 16:07:08 -0800 (PST) Received: from [192.168.8.100] ([181.202.128.231]) by mx.google.com with ESMTPSA id w107sm10103946qge.5.2015.02.01.16.07.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Feb 2015 16:07:05 -0800 (PST) From: John Bradley Content-Type: multipart/signed; boundary="Apple-Mail=_FB596A5C-7BBA-49AC-AEB4-32BED7A00D96"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sun, 1 Feb 2015 21:07:01 -0300 Message-Id: <5CB2DAD4-1C61-4910-A866-4C18F4A9A3FE@ve7jtb.com> To: Nat Sakimura Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: oauth Subject: [OAUTH-WG] PKCE/SPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 00:07:12 -0000 --Apple-Mail=_FB596A5C-7BBA-49AC-AEB4-32BED7A00D96 Content-Type: multipart/alternative; boundary="Apple-Mail=_FB022D81-0B69-4B91-A97D-9C92FA9F2537" --Apple-Mail=_FB022D81-0B69-4B91-A97D-9C92FA9F2537 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 h= ttps://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da06e= 99c225/draft-ietf-oauth-spop-00.txt = I made some edits to the copy in bitbucket. I changed the reference for unreserved URI characters to RFC3986. The = Base64 spec we were pointing to is slightly different. The change allows someone in the future to define a new = code_challenge_method that would allow a JWT to be valid. We unintentionally precluded the use of the =E2=80=9C.=E2=80=9D in = code_challenge and code_verifier.=20 I also added an appendix B to show the steps of S256 in a way someone = could use as a test vector. Appendix B is a first cut at it so give me feedback, and I can push it = to the document tracker later in the week. John B. --Apple-Mail=_FB022D81-0B69-4B91-A97D-9C92FA9F2537 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143= c246658da06e99c225/draft-ietf-oauth-spop-00.txt

I made some edits to the copy in = bitbucket.

I = changed the reference for unreserved URI characters to RFC3986. The Base64 spec we = were pointing to is slightly different.
The change allows someone in = the future to define a new code_challenge_method that would allow a JWT = to be valid.
We unintentionally precluded the use of the = =E2=80=9C.=E2=80=9D in code_challenge and code_verifier. =

I also added an appendix B = to show the steps of S256 in a way someone could use as a test = vector.

Appendix B is a first cut at = it so give me feedback, and I can push it to the document tracker later = in the week.


John B.

= --Apple-Mail=_FB022D81-0B69-4B91-A97D-9C92FA9F2537-- --Apple-Mail=_FB596A5C-7BBA-49AC-AEB4-32BED7A00D96 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAyMDIwMDA3MDFaMCMGCSqGSIb3DQEJBDEWBBS8rGB3LgJbt9uZ47ygDvjH q2/L5zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBIKORI2jIEXQ4QPACpW6G7jP8mFp0V6kcd5D0huqIGGhH80U2dH3LX GPrA2zMtAOblnpx67FlI6pcUDQShokvoarcaNd8koIG/c9+L+RikqVUTOwh94TyxkC1xsihiSwiN hQMrHFZpjXG038OLCLo1kjbWEK3e3fxm3+gPHuOYuxz528GuvqCjbKE6bT7Sb5Y9eU7bRa36r3Hq UU4af3j1k4/D9rawMH9q4/AJTzZ57vSyNTkLH3FVPmo+y1xCv9ZfX3HqLONN9cPOQUjdMXwA2K5t 78bQCrnUFFBJDeje4Dtzn+x+p1pZmM+nFyXrvJxTMDWuHfp8iILsqWcl692rAAAAAAAA --Apple-Mail=_FB596A5C-7BBA-49AC-AEB4-32BED7A00D96-- From nobody Tue Feb 3 05:41:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8838F1A006B for ; Tue, 3 Feb 2015 05:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_FlYw6zYJMU for ; Tue, 3 Feb 2015 05:41:48 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94691A005F for ; Tue, 3 Feb 2015 05:41:47 -0800 (PST) Received: from mail-ie0-f170.google.com ([209.85.223.170]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKVNDP9jkY88YBw+5vQVmhSz3XU1z10V6q@postini.com; Tue, 03 Feb 2015 05:41:47 PST Received: by mail-ie0-f170.google.com with SMTP id y20so25208549ier.1 for ; Tue, 03 Feb 2015 05:40:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wJ6F7jkFF6hSXqYhYuj4qZ4CkbjyDMvch0gdIBop5fA=; b=K3WPvcbdXyNNlQ9UbFFb3sDV6KsJJa1UAyspptKQScIM/6w0Xzuv8wuQDS3+Z3wzl+ Ac2TIMJ5Zzc/cAJk3mm3btcljWOG/+663/0OYurSDVQ5oFWgRlf0hSl2YtIMJEi/z5Nk PJSrLsThpuonVvpmixtaC1C9H1oIiPYB3Z3f3IjhNx8WrQS9w81yUHB7C8uufCnd3pzA glSdJwoYknM7SbtNP4J+vHt8hdphhcQW5PgdC3XHD5Jc1nkJEgldTbR+InJg5MeQVd/k H9PpiMlge35jSl1MxAOtlKvBDKp1RcVc0wmvWs36dsYRmqqJQmrC6mIOwNt8EtHCEQW7 FxQg== X-Gm-Message-State: ALoCoQmReLoHsgJ6T9SP2THvpdBTvWXNBvWx2A1RF0UrAYaDMarOgffIjaW4j9A9r6fboImKY3jDzf5GViQa9uWguQH+MVdMO7er9wZqwPKaTFj4wtul8wqgDe//8F4vID5rhFPRIFWo X-Received: by 10.51.16.1 with SMTP id fs1mr17645813igd.8.1422970856553; Tue, 03 Feb 2015 05:40:56 -0800 (PST) X-Received: by 10.51.16.1 with SMTP id fs1mr17645672igd.8.1422970854985; Tue, 03 Feb 2015 05:40:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Tue, 3 Feb 2015 05:40:24 -0800 (PST) In-Reply-To: <5CB2DAD4-1C61-4910-A866-4C18F4A9A3FE@ve7jtb.com> References: <5CB2DAD4-1C61-4910-A866-4C18F4A9A3FE@ve7jtb.com> From: Brian Campbell Date: Tue, 3 Feb 2015 06:40:24 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a1135e68c568bf8050e2f389e Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] PKCE/SPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 13:41:49 -0000 --001a1135e68c568bf8050e2f389e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I went thought appendix B and reproduced the same calculations. Which is nice. One little nit - to be consitent with the notation defined in =C2=A72, the = appendix B should have BASE64URL(SHA256(ASCII("code_verifier"))) =3D=3D code_challenge rather than Base64url(SHA256(ASCII("code_verifier" ))) =3D=3D code_challenge On Sun, Feb 1, 2015 at 5:07 PM, John Bradley wrote: > > https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da0= 6e99c225/draft-ietf-oauth-spop-00.txt > > I made some edits to the copy in bitbucket. > > I changed the reference for unreserved URI characters to RFC3986. The > Base64 spec we were pointing to is slightly different. > The change allows someone in the future to define a new > code_challenge_method that would allow a JWT to be valid. > We unintentionally precluded the use of the =E2=80=9C.=E2=80=9D in code_c= hallenge and > code_verifier. > > I also added an appendix B to show the steps of S256 in a way someone > could use as a test vector. > > Appendix B is a first cut at it so give me feedback, and I can push it to > the document tracker later in the week. > > > John B. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1135e68c568bf8050e2f389e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I went thought append= ix B and reproduced the same calculations. Which is nice.

One little= nit - to be consitent with the notation defined in =C2=A72, the appendix B should have

BASE64URL(SHA256(ASCII("code_verifier"))) =3D=3D code_challen= gerather than
   Base64url(SHA256(ASCII("code_verif=
ier" ))) =3D=3D code_challenge



On Sun, Feb 1, 2015 = at 5:07 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
https://bitbucket.org/= Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da06e99c225/draft-ietf-oaut= h-spop-00.txt

I made some edits to the copy in bitbu= cket.

I changed the reference for unreserved URI c= haracters to=C2=A0RFC3986. The Base64= spec we were pointing to is slightly different.
The change allows someone in the future to defi= ne a new code_challenge_method that would allow a JWT to be valid.
We unintentionally precluded = the use of the =E2=80=9C.=E2=80=9D in code_challenge and code_verifier.

<= span style=3D"white-space:pre-wrap">I also added an appendix B to show the = steps of S256 in a way someone could use as a test vector.

Appendix B is a first cut at it so give me feedback, = and I can push it to the document tracker later in the week.


John B.


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


--001a1135e68c568bf8050e2f389e-- From nobody Tue Feb 3 06:51:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F9A1A0451 for ; Tue, 3 Feb 2015 06:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8vLpN4j4d5i for ; Tue, 3 Feb 2015 06:51:36 -0800 (PST) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73DD1A0404 for ; Tue, 3 Feb 2015 06:51:36 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id a108so929251qge.7 for ; Tue, 03 Feb 2015 06:51:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=oKWvl/72OweqmfjHHZ5L47LIJdA8JQ2kJ3a1jPwLxe8=; b=kmJGTCd9bRB+15W+7fzRAHKlPtZnzMPrTUWSDJb8bDXi4Lwu8pzHFJ4ydsjERPEIas bKVYeOvZSMeg7cam9dvbq1VpRzkn8AKPGCc6/E6n8pP79Uj5cqS2lODtRMIFFbYm1hwl OyidbeMoCXt2N9qb8002UpeQFktralmC15zJbkezMwREkgVH+VEPk+uDsEfgTFGmHRRU 7k5Nm5QjMmmlD/smJWn8TMjmo9EAyFh3waIe2cHJ89uBByvG0hadwSZLbyERIz9hxlMk 4WTRv54HzX8vW6eIee58kx14sL6g1rLa/iySJyHQjGvvXOZ0T78xft2NcGG3qhoAzd6i WrmA== X-Gm-Message-State: ALoCoQn2M5ZzzQIJLY+dtlW6LUdrmf52gKE/E2IlTTIDir0DcEijIFuYqkbw5jJQnVysHzQ1f3Iq X-Received: by 10.140.23.199 with SMTP id 65mr50548904qgp.84.1422975095760; Tue, 03 Feb 2015 06:51:35 -0800 (PST) Received: from [192.168.1.41] (186-106-130-17.baf.movistar.cl. [186.106.130.17]) by mx.google.com with ESMTPSA id k64sm15754859qge.37.2015.02.03.06.51.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Feb 2015 06:51:35 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_5880C38C-DE57-410E-B308-A3CF619D3DB2"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Tue, 3 Feb 2015 11:51:26 -0300 Message-Id: References: <5CB2DAD4-1C61-4910-A866-4C18F4A9A3FE@ve7jtb.com> To: Brian Campbell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] PKCE/SPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 14:51:39 -0000 --Apple-Mail=_5880C38C-DE57-410E-B308-A3CF619D3DB2 Content-Type: multipart/alternative; boundary="Apple-Mail=_78E98D89-E281-4134-B504-9D6B504F8E8D" --Apple-Mail=_78E98D89-E281-4134-B504-9D6B504F8E8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK I fixed that in bitbucket. If I don=E2=80=99t hear back from anyone else I will push that version = to the doc tracker this afternoon. John B. > On Feb 3, 2015, at 10:40 AM, Brian Campbell = wrote: >=20 > I went thought appendix B and reproduced the same calculations. Which = is nice. >=20 > One little nit - to be consitent with the notation defined in =C2=A72, = the appendix B should have >=20 > BASE64URL(SHA256(ASCII("code_verifier"))) =3D=3D code_challenge > rather than > Base64url(SHA256(ASCII("code_verifier" ))) =3D=3D code_challenge >=20 >=20 >=20 > On Sun, Feb 1, 2015 at 5:07 PM, John Bradley > wrote: > = https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da06= e99c225/draft-ietf-oauth-spop-00.txt = >=20 > I made some edits to the copy in bitbucket. >=20 > I changed the reference for unreserved URI characters to RFC3986. The = Base64 spec we were pointing to is slightly different. > The change allows someone in the future to define a new = code_challenge_method that would allow a JWT to be valid. > We unintentionally precluded the use of the =E2=80=9C.=E2=80=9D in = code_challenge and code_verifier.=20 >=20 > I also added an appendix B to show the steps of S256 in a way someone = could use as a test vector. >=20 > Appendix B is a first cut at it so give me feedback, and I can push it = to the document tracker later in the week. >=20 >=20 > John B. >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_78E98D89-E281-4134-B504-9D6B504F8E8D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK I fixed that in bitbucket.

If I don=E2=80=99t hear back from = anyone else I will push that version to the doc tracker this = afternoon.

John = B.


On = Feb 3, 2015, at 10:40 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I went thought appendix B and reproduced the same calculations. Which is = nice.

One little nit - to be = consitent with the notation defined in =C2=A72, the appendix B should = have

   =
BASE64URL(SHA256(ASCII("code_verifier"))) =3D=3D =
code_challenge
rather than
   Base64url(SHA256(ASCII("code_verifier" ))) =3D=3D =
code_challenge



On Sun, Feb 1, 2015 at 5:07 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143= c246658da06e99c225/draft-ietf-oauth-spop-00.txt

I made some edits to the copy in = bitbucket.

I = changed the reference for unreserved URI characters to RFC3986. The Base64 spec we = were pointing to is slightly different.
The change allows someone in = the future to define a new code_challenge_method that would allow a JWT = to be valid.
We unintentionally precluded = the use of the =E2=80=9C.=E2=80=9D in code_challenge and code_verifier. =

I also added an appendix B to = show the steps of S256 in a way someone could use as a test = vector.

Appendix B is a first cut at = it so give me feedback, and I can push it to the document tracker later = in the week.


John B.


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



= --Apple-Mail=_78E98D89-E281-4134-B504-9D6B504F8E8D-- --Apple-Mail=_5880C38C-DE57-410E-B308-A3CF619D3DB2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAyMDMxNDUxMjZaMCMGCSqGSIb3DQEJBDEWBBRa//UyT75MdiwcB7w8TWdX tUvNcjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAOyY8RYpN8HZYtHXGLCnHNq+rjJ39gBPli1EMAc2jfZO4XUxwSuP+Y cy9SUnA2VAJtCh1pBGvF55oIKtUkmrpqVVZZY8JzT8BnYM4ImmQRE6MvvCsqMhWrW1K15E0H+1GB 3r0rZaLqESwJ0114jt/4f8vJihp9Jh+zN3n2W5n66wNG07SXsIGka94WYljSG0hll6gj0lb0b8XL Bx6P1ZYZdjDLqCCc1hNR/wv3cWH5bU1YRXyOLwWg8ncpJX+kvlOA4amjPkYhYrO7TRfs+2ELSHTw 4gkwOIkFHPS1MTSyP8GGG0fnqsyqAAyeLz/j652r9bqqkUEVIEyz9r3wRgAVAAAAAAAA --Apple-Mail=_5880C38C-DE57-410E-B308-A3CF619D3DB2-- From nobody Tue Feb 3 10:52:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF821A8824; Tue, 3 Feb 2015 10:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woM9tLlhGFw7; Tue, 3 Feb 2015 10:51:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA921A8A41; Tue, 3 Feb 2015 10:51:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150203185155.18330.96160.idtracker@ietfa.amsl.com> Date: Tue, 03 Feb 2015 10:51:55 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 18:51:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Authors : Nat Sakimura John Bradley Naveen Agarwal Filename : draft-ietf-oauth-spop-08.txt Pages : 18 Date : 2015-02-03 Abstract: OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-spop-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 3 17:50:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2831F1A1B9C for ; Tue, 3 Feb 2015 17:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 884DxKuzclfS for ; Tue, 3 Feb 2015 17:50:26 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FF11A1B8E for ; Tue, 3 Feb 2015 17:50:26 -0800 (PST) Received: by mail-oi0-f43.google.com with SMTP id z81so52198415oif.2 for ; Tue, 03 Feb 2015 17:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=075kAO84C7oPKwW5uX+7Mc+gNagtE5H6nyuFxJLClzk=; b=ZeNEZERWXZkq2iSjI4VFofIBijmusnpJ6wK0mO4PDBeB0P9n9Y6milGuAPjhe6Rlku gwK8JNbrP7BBDctnntQjO14wbVNqLv87PFIiZUCWNLf0W/BQZ+zlmZE3Xj5sEat+BNGM i3bHPXYtp3tJz++cHEuB8d1HVPJhYXpDsKLCYdgM/DWjYye9hdeN08jSVuSKkAdh2Hbi /FkrfuwDjZF7Rz1NWQbERFzINwGNW4xcBVbLFdg4MHFg0/+VXxL1yhjpzxyzc4W/G4f1 tWnE3GGTkODBM/3qAkJylzgxqdEzFkyH16VJEncDx9dVueSps+BmAVnxMqYY+WxD7XKH nAOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=075kAO84C7oPKwW5uX+7Mc+gNagtE5H6nyuFxJLClzk=; b=eFK1wii36LghH4b8LFkotPgV/BOq/aBr+v88bwaGEbhy+nxV4EPMav+Jbbh8EisVfg ym0ikESVJdzTNFoSJZlW+cpQXipDHk42/U/f848RFyYhJPJA3Uunu2G24wK0jmoPEVB3 NloWirppXn2CaVaX//M3FnqxeE3v5Q5QgfeyMctWkT7O865pYarc8H+DLqb6XDrpYTFc xIC75j6yUhgVw0szeqg183y3LH5H+0msY/c1RyN8rN3TmHnslWuXt906kx/Y3OxnHApw 3giVRSBPNYsR3fJbedBQtLJssBwtd5wN84PEQDgkz2irUN876O8ZiMUqNukuyZUtR+9c tEew== X-Gm-Message-State: ALoCoQkST2OvF7SawAcHz4dnuIuqQP5Nsr2cZy8jyB2pIhFwlEka4lfzvxDSkfTvGvlsR4QHAVrJ X-Received: by 10.202.80.199 with SMTP id e190mr16577431oib.75.1423014625360; Tue, 03 Feb 2015 17:50:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.80.206 with HTTP; Tue, 3 Feb 2015 17:50:04 -0800 (PST) In-Reply-To: References: <5CB2DAD4-1C61-4910-A866-4C18F4A9A3FE@ve7jtb.com> From: William Denniss Date: Tue, 3 Feb 2015 17:50:04 -0800 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a113b1c00416881050e3969cd Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] PKCE/SPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 01:50:28 -0000 --001a113b1c00416881050e3969cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Speaking of Base64url, where it's defined in "Notational Conventions", is there a way to prevent the HTML markup automatically linkifying "Section 3.2" ? It's not marked up in the XML, but in the HTML output it is =E2=80= =93 and the auto-generated link is incorrect, as it points to Section 3.2 in SPOP, rather than 3.2 in RFC4648. This may seem trivial, but the fact that we're using a less common variant of Base64url makes me want to provide as much accurate context as possible to help implementers. This is how it renders today (note the Section 3.2 link) Base64url Encoding Base64 encoding using the URL- and filename-safe character set defined in Section 5 of RFC 4648 [RFC4648 ], with all trailing '=3D' characters omitted (as permitted by Section 3.2 ) and without the inclusion of any line breaks, whitespace, or other additional characters. (See Appendix A for notes on implementing base64url encoding without padding.) On Tue, Feb 3, 2015 at 6:51 AM, John Bradley wrote: > OK I fixed that in bitbucket. > > If I don=E2=80=99t hear back from anyone else I will push that version to= the doc > tracker this afternoon. > > John B. > > > On Feb 3, 2015, at 10:40 AM, Brian Campbell > wrote: > > I went thought appendix B and reproduced the same calculations. Which is > nice. > > One little nit - to be consitent with the notation defined in =C2=A72, th= e appendix > B should have > > BASE64URL(SHA256(ASCII("code_verifier"))) =3D=3D code_challenge > > rather than > > Base64url(SHA256(ASCII("code_verifier" ))) =3D=3D code_challenge > > > > > On Sun, Feb 1, 2015 at 5:07 PM, John Bradley wrote: > >> >> https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da= 06e99c225/draft-ietf-oauth-spop-00.txt >> >> I made some edits to the copy in bitbucket. >> >> I changed the reference for unreserved URI characters to RFC3986. The >> Base64 spec we were pointing to is slightly different. >> The change allows someone in the future to define a new >> code_challenge_method that would allow a JWT to be valid. >> We unintentionally precluded the use of the =E2=80=9C.=E2=80=9D in code_= challenge and >> code_verifier. >> >> I also added an appendix B to show the steps of S256 in a way someone >> could use as a test vector. >> >> Appendix B is a first cut at it so give me feedback, and I can push it t= o >> the document tracker later in the week. >> >> >> John B. >> >> >> _______________________________________________ >> 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 > > --001a113b1c00416881050e3969cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking of Base64url, where it's defined in "Not= ational Conventions", is there a way to prevent the HTML markup automa= tically linkifying "Section 3.2" ?=C2=A0 It's not marked up i= n the XML, but in the HTML output it is =E2=80=93 and the auto-generated li= nk is incorrect, as it points to Section 3.2 in SPOP, rather than 3.2 in=C2= =A0RFC4648.

This may seem trivial, but the fact tha= t we're using a less common variant of Base64url makes me want to provi= de as much accurate context as possible to help implementers.

This is how it renders today (note the Section 3.2 link)<= /div>

   Base64url Enco=
ding  Base64 encoding using the URL- and filename-safe
      character set defined in Section=C2=A05 of RFC 4648 [RFC4648], with all
      trailing '=3D' characters omitted (as permitted by Section 3=
.2) and
      without the inclusion of any line breaks, whitespace, or other
      additional characters.  (See Appendix A for notes on implementing
      base64url encoding without padding.)


On Tue, Feb 3, 2015 at 6:51= AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
OK I fixed that in b= itbucket.

If I don=E2=80=99t hear back from anyone else = I will push that version to the doc tracker this afternoon.

<= /div>
John B.


=
On Feb 3, 2015, at 10:40 AM, Brian Campbell = <bcampbe= ll@pingidentity.com> wrote:

I went th= ought appendix B and reproduced the sa= me calculations. Which is nice.

One little nit - to be consit= ent with the notation defined in =C2=A72, the appendix B should have

   BASE64URL(SHA256(ASCII=
("code_verifier"))) =3D=3D code_challenge
rather than
   Base64url(SHA256(ASCII("code_verifier" ))) =3D=3D code_=
challenge


On Sun, Feb 1, 2015 at 5:07 PM, John Bradley <= span dir=3D"ltr"><ve7jtb@ve7jtb.com> wrote:
=
https://bitbucket.org/Nat/oauth-spop/raw/cd8b864= 96fb59261103143c246658da06e99c225/draft-ietf-oauth-spop-00.txt

=
I made some edits to the copy in bitbucket.

=
I changed the reference for unreserved URI characters to=C2=A0RFC3986. The Base64 spec we were pointing to = is slightly different.
The change allows someone in the future to define a new code_challenge_me= thod that would allow a JWT to be valid.
We unintentionally precluded the use of the =E2=80=9C.= =E2=80=9D in code_challenge and code_verifier.

I also added an appendix B to show the steps of S256 in a way so= meone could use as a test vector.

App= endix B is a first cut at it so give me feedback, and I can push it to the = document tracker later in the week.

<= br>
John B.


_______________________________________________=
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


--001a113b1c00416881050e3969cd-- From nobody Tue Feb 3 18:38:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD6D1A1A39 for ; Tue, 3 Feb 2015 18:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_tk1-5B-_oL for ; Tue, 3 Feb 2015 18:38:24 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637641A1A8B for ; Tue, 3 Feb 2015 18:38:21 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so25618729obc.9 for ; Tue, 03 Feb 2015 18:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HKkOuZu++ETHN/+nlqgsKRgqnZTGJsGYgtnMytcCFP8=; b=RC6cBugVgr55YU/5tIMkkvkywRaqaX2d1roaV3Ru3TYnhrTSGKMHqQ7w/s8fCPcJsz RuWmdNQTW4mP0SObmsFxZwqvr6Oij5rNotkPWJVatrBWUZgi/Ng0AD+fv3QD+DBT5VYk bgowBK0bwNRWMr8IiaeXF3NQTbTwaHwW9YbodUd6xHd74bwGguVsR/ItkP7AOwITvfar EvFmlY+2Ce/qOnCwv4Vic6IQU0p0+re+rLSdAV2ftngUoM+Q+W3M/1AXoUle+US9EWtX Sc+R0Eps93AXS8WFEgrnopevQ7aLC6buk0QNmSle4mQwe27zo4CqR9K1j365YIMde2ue DREg== MIME-Version: 1.0 X-Received: by 10.182.81.98 with SMTP id z2mr17732953obx.35.1423017500644; Tue, 03 Feb 2015 18:38:20 -0800 (PST) Received: by 10.60.171.196 with HTTP; Tue, 3 Feb 2015 18:38:20 -0800 (PST) In-Reply-To: References: <5CB2DAD4-1C61-4910-A866-4C18F4A9A3FE@ve7jtb.com> Date: Wed, 4 Feb 2015 11:38:20 +0900 Message-ID: From: Nat Sakimura To: William Denniss Content-Type: multipart/alternative; boundary=047d7b2e4858a29cee050e3a14b5 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] PKCE/SPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 02:38:27 -0000 --047d7b2e4858a29cee050e3a14b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hmmm. A bug at ietf.org rendering engine? Perhaps we may repeat of RFC4648 again there to avoid this behaviour. 2015-02-04 10:50 GMT+09:00 William Denniss : > Speaking of Base64url, where it's defined in "Notational Conventions", is > there a way to prevent the HTML markup automatically linkifying "Section > 3.2" ? It's not marked up in the XML, but in the HTML output it is =E2= =80=93 and > the auto-generated link is incorrect, as it points to Section 3.2 in SPOP= , > rather than 3.2 in RFC4648. > > This may seem trivial, but the fact that we're using a less common varian= t > of Base64url makes me want to provide as much accurate context as possibl= e > to help implementers. > > This is how it renders today (note the Section 3.2 link) > > Base64url Encoding Base64 encoding using the URL- and filename-safe > character set defined in Section 5 of RFC 4648 [RFC4648 ], = with all > trailing '=3D' characters omitted (as permitted by Section 3.2 ) and > without the inclusion of any line breaks, whitespace, or other > additional characters. (See Appendix A for notes on implementing > base64url encoding without padding.) > > > > On Tue, Feb 3, 2015 at 6:51 AM, John Bradley wrote: > >> OK I fixed that in bitbucket. >> >> If I don=E2=80=99t hear back from anyone else I will push that version t= o the doc >> tracker this afternoon. >> >> John B. >> >> >> On Feb 3, 2015, at 10:40 AM, Brian Campbell >> wrote: >> >> I went thought appendix B and reproduced the same calculations. Which is >> nice. >> >> One little nit - to be consitent with the notation defined in =C2=A72, t= he appendix >> B should have >> >> BASE64URL(SHA256(ASCII("code_verifier"))) =3D=3D code_challenge >> >> rather than >> >> Base64url(SHA256(ASCII("code_verifier" ))) =3D=3D code_challenge >> >> >> >> >> On Sun, Feb 1, 2015 at 5:07 PM, John Bradley wrote: >> >>> >>> https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658d= a06e99c225/draft-ietf-oauth-spop-00.txt >>> >>> I made some edits to the copy in bitbucket. >>> >>> I changed the reference for unreserved URI characters to RFC3986. The >>> Base64 spec we were pointing to is slightly different. >>> The change allows someone in the future to define a new >>> code_challenge_method that would allow a JWT to be valid. >>> We unintentionally precluded the use of the =E2=80=9C.=E2=80=9D in code= _challenge and >>> code_verifier. >>> >>> I also added an appendix B to show the steps of S256 in a way someone >>> could use as a test vector. >>> >>> Appendix B is a first cut at it so give me feedback, and I can push it >>> to the document tracker later in the week. >>> >>> >>> John B. >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --047d7b2e4858a29cee050e3a14b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hmmm. A bug at ietf.org re= ndering engine?=C2=A0
Perhaps we may repeat of RFC4648 again there to a= void this behaviour.=C2=A0

2015-02-04 10:50 GMT+09:00 William Denniss <wdenn= iss@google.com>:
Speaking of Base64url, where it's defined in "Notational = Conventions", is there a way to prevent the HTML markup automatically = linkifying "Section 3.2" ?=C2=A0 It's not marked up in the XM= L, but in the HTML output it is =E2=80=93 and the auto-generated link is in= correct, as it points to Section 3.2 in SPOP, rather than 3.2 in=C2=A0RFC46= 48.

This may seem trivial, but the fact that we'= ;re using a less common variant of Base64url makes me want to provide as mu= ch accurate context as possible to help implementers.

<= /div>
This is how it renders today (note the Section 3.2 link)

   Base64url Encoding  Base64 encodi=
ng using the URL- and filename-safe
      character set defined in Section=C2=A05 of RFC 4648 [RFC4648], with all
      trailing '=3D' characters omitted (as permitted by Section 3.2) and
      without the inclusion of any line breaks, whitespace, or other
      additional characters.  (See Appendix A for not=
es on implementing
      base64url encoding without padding.)


On Tue, Feb 3, 2015 at 6:51 AM, John Bradley <ve7jtb@ve7jtb.c= om> wrote:
OK I fixed that in bitbucket.

If I d= on=E2=80=99t hear back from anyone else I will push that version to the doc= tracker this afternoon.

John B.


On Feb 3, 2015, a= t 10:40 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I went thought appen= dix B and reproduced the same calculations. Which is nice.

One littl= e nit - to be consitent with the notation defined in =C2=A72, the appendix B should have

BASE64URL(SHA256(ASCII("code_verifier"))) =3D=3D code_challe= ngerather than
   Base64url(SHA256(ASCII("code_veri=
fier" ))) =3D=3D code_challenge



On Sun, Feb 1, 2015= at 5:07 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
https://bitbucket.org= /Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da06e99c225/draft-ietf-oau= th-spop-00.txt

I made some edits to the copy in bitb= ucket.

I changed the reference for unreserved URI = characters to=C2=A0RFC3986. The Base6= 4 spec we were pointing to is slightly different.
The change allows someone in the future to def= ine a new code_challenge_method that would allow a JWT to be valid.<= /div>
We unintentionally precluded= the use of the =E2=80=9C.=E2=80=9D in code_challenge and code_verifier.

= I also added an appendix B to show the= steps of S256 in a way someone could use as a test vector.

Appendix B is a first cut at it so give me feedback,= and I can push it to the document tracker later in the week.
<= div>

John B.


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




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



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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--047d7b2e4858a29cee050e3a14b5-- From nobody Wed Feb 4 04:26:54 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0071A87C7 for ; Wed, 4 Feb 2015 04:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ixii-rSH4nib for ; Wed, 4 Feb 2015 04:26:47 -0800 (PST) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9465C1A87A0 for ; Wed, 4 Feb 2015 04:26:47 -0800 (PST) Received: by mail-qg0-f52.google.com with SMTP id z107so827872qgd.11 for ; Wed, 04 Feb 2015 04:26:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ksnFBLbJ/kx3rGSXACpfK4aaRK9Ja1NckLPdjentJw0=; b=Kgy0VSgzDXCfLztuqwMQ2M4DajDR2Quf8XLeE3FBfDceL2thotUYNrFGYIwAtUP2EN Agyn5myF+3zDLz/R2NypWzsceMqCqVsIIa0S8aTPcYWso7WRPxlHd2i9d84rQfFD7AFB PfzDStktc/oHKs75MvhTd945nndG4dXRi2zGuSLbJdIyi1l5i6Jz1Hd54eLD2QyGnsGe J5hOg5wcDnGjZNoY6DQt2QZoij3n+hYCGs+JEwA0mVBpDRs2OEjg8r2HdxML7MNrrtUH 5AOwxAyU0iNncgUpzpvHIMxr4myx6vkRu82fUIaIxBJ/CevuhVH1T4tF0sboMq9z/MyE WBTg== X-Gm-Message-State: ALoCoQn/T2E9T8FCgFlRFMOj/EebXtUnD8Z2tRrFTrMoYTRul/wnHT55gLSYpu56ks8tH37GIWnP X-Received: by 10.224.19.193 with SMTP id c1mr61485859qab.73.1423052806500; Wed, 04 Feb 2015 04:26:46 -0800 (PST) Received: from [192.168.1.43] (186-106-130-17.baf.movistar.cl. [186.106.130.17]) by mx.google.com with ESMTPSA id 11sm1532153qgt.41.2015.02.04.04.26.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Feb 2015 04:26:45 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_3813A7F5-7C20-4888-9169-A6D5844C0A73"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: Date: Wed, 4 Feb 2015 09:26:24 -0300 Message-Id: References: <5CB2DAD4-1C61-4910-A866-4C18F4A9A3FE@ve7jtb.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1993) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] PKCE/SPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 12:26:53 -0000 --Apple-Mail=_3813A7F5-7C20-4888-9169-A6D5844C0A73 Content-Type: multipart/alternative; boundary="Apple-Mail=_A3D921CC-DA9C-45F8-867C-F4B2A0D1E409" --Apple-Mail=_A3D921CC-DA9C-45F8-867C-F4B2A0D1E409 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I will take a look at it today. I was using the local python version = I think. John B. > On Feb 3, 2015, at 11:38 PM, Nat Sakimura wrote: >=20 > Hmmm. A bug at ietf.org rendering engine?=20 > Perhaps we may repeat of RFC4648 again there to avoid this behaviour.=20= >=20 > 2015-02-04 10:50 GMT+09:00 William Denniss >: > Speaking of Base64url, where it's defined in "Notational Conventions", = is there a way to prevent the HTML markup automatically linkifying = "Section 3.2" ? It's not marked up in the XML, but in the HTML output = it is =E2=80=93 and the auto-generated link is incorrect, as it points = to Section 3.2 in SPOP, rather than 3.2 in RFC4648. >=20 > This may seem trivial, but the fact that we're using a less common = variant of Base64url makes me want to provide as much accurate context = as possible to help implementers. >=20 > This is how it renders today (note the Section 3.2 link) >=20 > Base64url Encoding Base64 encoding using the URL- and = filename-safe > character set defined in Section=C2=A05 of RFC 4648 = [RFC4648 = ], with all > trailing '=3D' characters omitted (as permitted by Section 3.2 = ) and > without the inclusion of any line breaks, whitespace, or other > additional characters. (See Appendix A = for = notes on implementing > base64url encoding without padding.) >=20 >=20 > On Tue, Feb 3, 2015 at 6:51 AM, John Bradley > wrote: > OK I fixed that in bitbucket. >=20 > If I don=E2=80=99t hear back from anyone else I will push that version = to the doc tracker this afternoon. >=20 > John B. >=20 >=20 >> On Feb 3, 2015, at 10:40 AM, Brian Campbell = > wrote: >>=20 >> I went thought appendix B and reproduced the same calculations. Which = is nice. >>=20 >> One little nit - to be consitent with the notation defined in =C2=A72, = the appendix B should have >>=20 >> BASE64URL(SHA256(ASCII("code_verifier"))) =3D=3D code_challenge >> rather than >> Base64url(SHA256(ASCII("code_verifier" ))) =3D=3D code_challenge >>=20 >>=20 >>=20 >> On Sun, Feb 1, 2015 at 5:07 PM, John Bradley > wrote: >> = https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da06= e99c225/draft-ietf-oauth-spop-00.txt = >>=20 >> I made some edits to the copy in bitbucket. >>=20 >> I changed the reference for unreserved URI characters to RFC3986. = The Base64 spec we were pointing to is slightly different. >> The change allows someone in the future to define a new = code_challenge_method that would allow a JWT to be valid. >> We unintentionally precluded the use of the =E2=80=9C.=E2=80=9D in = code_challenge and code_verifier.=20 >>=20 >> I also added an appendix B to show the steps of S256 in a way someone = could use as a test vector. >>=20 >> Appendix B is a first cut at it so give me feedback, and I can push = it to the document tracker later in the week. >>=20 >>=20 >> John B. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail=_A3D921CC-DA9C-45F8-867C-F4B2A0D1E409 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8  I will take a look at it today.   I was using the = local python version I think.

John B.
On Feb 3, 2015, at 11:38 PM, Nat Sakimura = <sakimura@gmail.com> wrote:

Hmmm. A bug at ietf.org rendering engine? 
Perhaps = we may repeat of RFC4648 again there to avoid this = behaviour. 

2015-02-04 10:50 GMT+09:00 William Denniss <wdenniss@google.com>:
Speaking of Base64url, where it's defined in "Notational = Conventions", is there a way to prevent the HTML markup automatically = linkifying "Section 3.2" ?  It's not marked up in the XML, but in = the HTML output it is =E2=80=93 and the auto-generated link is = incorrect, as it points to Section 3.2 in SPOP, rather than 3.2 = in RFC4648.

This may seem trivial, but the fact that we're using a less = common variant of Base64url makes me want to provide as much accurate = context as possible to help implementers.

This is how it renders today (note the = Section 3.2 link)

  =
 Base64url Encoding  Base64 encoding using the URL- and filename-safe
      character set defined in Section 5 of RFC 4648 [RFC4648], with all
      trailing '=3D' characters omitted (as permitted by Section 3.2) and
      without the inclusion of any line breaks, whitespace, or other
      additional characters.  (See Appendix A for notes on implementing
      base64url encoding without padding.)


On Tue, = Feb 3, 2015 at 6:51 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
OK I fixed that in = bitbucket.

If I = don=E2=80=99t hear back from anyone else I will push that version to the = doc tracker this afternoon.

John B.


On Feb = 3, 2015, at 10:40 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I went thought = appendix B and = reproduced the same calculations. Which is nice.

One little nit - to be consitent with the notation = defined in =C2=A72, the appendix B should have

BASE64URL(SHA256(ASCII("code_verifier"))) =3D=3D = code_challengerather than
   Base64url(SHA256(ASCII("code_verifier" ))) =3D=3D =
code_challenge



On Sun, Feb 1, 2015 at 5:07 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143= c246658da06e99c225/draft-ietf-oauth-spop-00.txt

I made some edits to the copy in = bitbucket.

I = changed the reference for unreserved URI characters to RFC3986. The Base64 spec we = were pointing to is slightly different.
The change allows someone in = the future to define a new code_challenge_method that would allow a JWT = to be valid.
We unintentionally precluded = the use of the =E2=80=9C.=E2=80=9D in code_challenge and code_verifier. =

I also added an appendix B to = show the steps of S256 in a way someone could use as a test = vector.

Appendix B is a first cut at = it so give me feedback, and I can push it to the document tracker later = in the week.


John B.


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




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



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




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

= --Apple-Mail=_A3D921CC-DA9C-45F8-867C-F4B2A0D1E409-- --Apple-Mail=_3813A7F5-7C20-4888-9169-A6D5844C0A73 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAyMDQxMjI2MjVaMCMGCSqGSIb3DQEJBDEWBBQegt3kLp5LTLFUa+4EdIxN eZmE1DCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAdiWovVzX0pKVSCEcautuYr1wKo+5tCOcdS/HkqLeoOW2eSJDzUVZI VAP4xYoljartkuWOdjfbJb1SsBH4pAc0W2XXkAa4wAHQE6YDQ7Fgaxh35bWd211UA4rL3SxTL9Gy O4cGkWmAQ/guUJw7lJseqI2so/cS3klNBOLuIVxFEHxjVsaUZfm78RyUTz+fZ8RTNDHQh78ixtDq drBATFAVEk/IaSr+QneTRjM1OOLAUNQFV6l2NCIRaF3bfVo1Rb92taSDcVrYzZkkQ6qciemYlbTd 5U2uHYgq0hdV9ZwqiHfT574mCk00FwBc1yq58m3AFcKdQB11X85cl0yYVOJJAAAAAAAA --Apple-Mail=_3813A7F5-7C20-4888-9169-A6D5844C0A73-- From nobody Wed Feb 4 05:40:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3091A00E4 for ; Wed, 4 Feb 2015 05:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnYWR4OIF4gE for ; Wed, 4 Feb 2015 05:40:46 -0800 (PST) Received: from na3sys009aog134.obsmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DED91A0360 for ; Wed, 4 Feb 2015 05:40:44 -0800 (PST) Received: from mail-ie0-f174.google.com ([209.85.223.174]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKVNIhXBhS92cYv4nlpXfx3T8nqTmr5OTV@postini.com; Wed, 04 Feb 2015 05:40:45 PST Received: by mail-ie0-f174.google.com with SMTP id vy18so1966228iec.5 for ; Wed, 04 Feb 2015 05:40:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=M1mLOUPn3kKD3YW1qaXEov2tvy/a4LHlYiwlpTX6Uzg=; b=JLQbVssJYLsGFw9gyMg1zsFJG3RbXnIXcKsxxzrMDeH4HACeM7t1/1/YusRtaBZIv2 7TiRbAdPAgw7FWXNfgIjkQDPGe/Da0Q9TsYdpXLZS9aEf1qBLCOxKMaVNBelycMQb58h fvDMbTcIt1qG2RfZs9NKupO62asF1JdZIixGtOsH6av+f/m26MjO8MKx7u3Z6nNnQJqD ljfKZjFTSANeEiVCm6LkqG1wPBWfRDat7w4i9IGeG1y2BgT1aBt4+PFVcWIquW/DBGO1 T5zqARi3Xza0f3wE55I3SzloXqJfrITP/sv6ozEfBKIzoFv7kKnD6hKM4+KJdxeMfKSS qLVg== X-Gm-Message-State: ALoCoQlNw4ry9atr1gycp1nAXKmotVzwOiJO/sxZK1k9carE+pLsIVtYgHbjdNz8lZHP+d6ZY7c8wBhA1sg9KgA7xfme56MJ7CnOF/ToOjMZT95k24yG4rbBGBHjtvmc72oQPvMeI8XW X-Received: by 10.107.151.80 with SMTP id z77mr34793371iod.51.1423057244178; Wed, 04 Feb 2015 05:40:44 -0800 (PST) X-Received: by 10.107.151.80 with SMTP id z77mr34793356iod.51.1423057243971; Wed, 04 Feb 2015 05:40:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Wed, 4 Feb 2015 05:40:12 -0800 (PST) In-Reply-To: References: <5CB2DAD4-1C61-4910-A866-4C18F4A9A3FE@ve7jtb.com> From: Brian Campbell Date: Wed, 4 Feb 2015 06:40:12 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a1140f5ee85bae3050e4355e8 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] PKCE/SPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 13:40:49 -0000 --001a1140f5ee85bae3050e4355e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I *think* this is the same formatting issue that is discussed, with a way to work around it, at http://www.ietf.org/mail-archive/web/jose/current/msg04571.html On Wed, Feb 4, 2015 at 5:26 AM, John Bradley wrote: > I will take a look at it today. I was using the local python version I > think. > > John B. > > On Feb 3, 2015, at 11:38 PM, Nat Sakimura wrote: > > Hmmm. A bug at ietf.org rendering engine? > Perhaps we may repeat of RFC4648 again there to avoid this behaviour. > > 2015-02-04 10:50 GMT+09:00 William Denniss : > >> Speaking of Base64url, where it's defined in "Notational Conventions", i= s >> there a way to prevent the HTML markup automatically linkifying "Section >> 3.2" ? It's not marked up in the XML, but in the HTML output it is =E2= =80=93 and >> the auto-generated link is incorrect, as it points to Section 3.2 in SPO= P, >> rather than 3.2 in RFC4648. >> >> This may seem trivial, but the fact that we're using a less common >> variant of Base64url makes me want to provide as much accurate context a= s >> possible to help implementers. >> >> This is how it renders today (note the Section 3.2 link) >> >> Base64url Encoding Base64 encoding using the URL- and filename-safe >> character set defined in Section 5 of RFC 4648 [RFC4648 ],= with all >> trailing '=3D' characters omitted (as permitted by Section 3.2 ) and >> without the inclusion of any line breaks, whitespace, or other >> additional characters. (See Appendix A for notes on implementing >> base64url encoding without padding.) >> >> >> >> On Tue, Feb 3, 2015 at 6:51 AM, John Bradley wrote: >> >>> OK I fixed that in bitbucket. >>> >>> If I don=E2=80=99t hear back from anyone else I will push that version = to the >>> doc tracker this afternoon. >>> >>> John B. >>> >>> >>> On Feb 3, 2015, at 10:40 AM, Brian Campbell >>> wrote: >>> >>> I went thought appendix B and reproduced the same calculations. Which >>> is nice. >>> >>> One little nit - to be consitent with the notation defined in =C2=A72, = the appendix >>> B should have >>> >>> BASE64URL(SHA256(ASCII("code_verifier"))) =3D=3D code_challenge >>> >>> rather than >>> >>> Base64url(SHA256(ASCII("code_verifier" ))) =3D=3D code_challenge >>> >>> >>> >>> >>> On Sun, Feb 1, 2015 at 5:07 PM, John Bradley wrote: >>> >>>> >>>> https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658= da06e99c225/draft-ietf-oauth-spop-00.txt >>>> >>>> I made some edits to the copy in bitbucket. >>>> >>>> I changed the reference for unreserved URI characters to RFC3986. The >>>> Base64 spec we were pointing to is slightly different. >>>> The change allows someone in the future to define a new >>>> code_challenge_method that would allow a JWT to be valid. >>>> We unintentionally precluded the use of the =E2=80=9C.=E2=80=9D in cod= e_challenge and >>>> code_verifier. >>>> >>>> I also added an appendix B to show the steps of S256 in a way someone >>>> could use as a test vector. >>>> >>>> Appendix B is a first cut at it so give me feedback, and I can push it >>>> to the document tracker later in the week. >>>> >>>> >>>> John B. >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1140f5ee85bae3050e4355e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I *think* this is the same formatting issue that is discus= sed, with a way to work around it, at http://www.ietf.org/mail-archive/web= /jose/current/msg04571.html

On Wed, Feb 4, 2015 at 5:26 AM, John Bradley <ve7j= tb@ve7jtb.com> wrote:
=C2=A0I will take a look at it today. =C2=A0= I was using the local python version I think.

John B.

On Feb 3, 2015= , at 11:38 PM, Nat Sakimura <sakimura@gmail.com> wrote:


<= div class=3D"gmail_quote">2015-02-04 10:50 GMT+09:00 William Denniss <wd= enniss@google.com>:
Speaking of Base64url, where it's defined in "Notational= Conventions", is there a way to prevent the HTML markup automatically= linkifying "Section 3.2" ?=C2=A0 It's not marked up in the X= ML, but in the HTML output it is =E2=80=93 and the auto-generated link is i= ncorrect, as it points to Section 3.2 in SPOP, rather than 3.2 in=C2=A0RFC4= 648.

This may seem trivial, but the fact that we= 9;re using a less common variant of Base64url makes me want to provide as m= uch accurate context as possible to help implementers.

=
This is how it renders today (note the Section 3.2 link)

   Base64url Encoding  Base64 encoding using the URL=
- and filename-safe
      character set defined in Section=C2=A05 of RFC 4648 [RFC4648], with all
      trailing '=3D' characters omitted (as permitted by Section 3.2) and
      without the inclusion of any line breaks, whitespace, or other
      additional characters.  (See Appendix A for not=
es on implementing
      base64url encoding without padding.)

<= div class=3D"gmail_extra">
On Tue, Feb 3, 201= 5 at 6:51 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
OK I fixed = that in bitbucket.

If I don=E2=80=99t hear back from any= one else I will push that version to the doc tracker this afternoon.
<= div>
John B.


On Feb 3, 2015, at 10:40 AM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

I went though= t appendix B and reproduced the same c= alculations. Which is nice.

One little nit - to be consitent = with the notation defined in =C2=A72, the appendix B should have

   BASE64URL(SHA256(ASCII(&qu=
ot;code_verifier"))) =3D=3D code_challenge
rather than
Base64url(SHA256(ASCII("code_verifier" ))) =3D=3D code_chal= lenge


On Sun, Feb 1, 2015 at 5:07 PM, John Bradley <ve7= jtb@ve7jtb.com> wrote:
https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb= 59261103143c246658da06e99c225/draft-ietf-oauth-spop-00.txt

I made some edits to the copy in bitbucket.

I changed the reference for unreserved URI characters to=C2=A0RFC3986. The Base64 spec we were pointing to is = slightly different.
T= he change allows someone in the future to define a new code_challenge_metho= d that would allow a JWT to be valid.
We unintentionally precluded the use of the =E2=80=9C.=E2= =80=9D in code_challenge and code_verifier.

I also added an appendix B to show the steps of S256 in a way som= eone could use as a test vector.

Appe= ndix B is a first cut at it so give me feedback, and I can push it to the d= ocument tracker later in the week.

John B.


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




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



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




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


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


--001a1140f5ee85bae3050e4355e8-- From nobody Wed Feb 4 12:26:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DF81A1B6A for ; Wed, 4 Feb 2015 12:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7mWhsvndWs8 for ; Wed, 4 Feb 2015 12:26:00 -0800 (PST) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303581A1A8D for ; Wed, 4 Feb 2015 12:26:00 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id i50so2428235qgf.0 for ; Wed, 04 Feb 2015 12:25:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=G9ThryfkYcfPmuggyzYh1HlHXlD3zPNsZ0WJ9DS4pec=; b=VrM398VThsec0s0KUdbffOTOYi0enEMI5v4r6yCmikJvUfAq37+1QLxIBfN+2vuZ74 g1JyGgzuCMiFP/2Oj/MJcogob8oSS6zYijsuB2QXKsSXmXMKn1yhTh/SHnJ0YeoViZDq PaABY7I5NO+7QqjcteVvbifuIm+Cb0hiAJMXyd3jdDDRYxk7WaZ8ClVEIFIAys3Ky/hG NcBOM27Cwo8G9NdswmRvMw7xjsuT5xVF95GLe4EuNgmeRXD7NIUcxbAhTrfUc6wBx3s6 5drwo+V+mTlrz0Jjm+fP3mtclKfMFiNjLw9A7yet0GB4MOckMiXc1jOqPCdwViuDtRJv xlfA== X-Gm-Message-State: ALoCoQkKJ2rpcXksWhnsxMwCBTVhdcPlPJtRm8Yp5N5EeyClYNMlV0pINZ2lqLfX1FopuZbZUXTd X-Received: by 10.229.236.129 with SMTP id kk1mr418939qcb.20.1423081559303; Wed, 04 Feb 2015 12:25:59 -0800 (PST) Received: from [192.168.8.100] ([181.202.131.210]) by mx.google.com with ESMTPSA id e88sm2738247qgf.22.2015.02.04.12.25.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Feb 2015 12:25:58 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_4A69664B-77B6-4ECA-8AC0-3349BF532CD3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Wed, 4 Feb 2015 17:25:53 -0300 Message-Id: <43C18957-1E86-4C86-9D17-F98A91D870BC@ve7jtb.com> References: <5CB2DAD4-1C61-4910-A866-4C18F4A9A3FE@ve7jtb.com> To: Brian Campbell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] PKCE/SPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 20:26:03 -0000 --Apple-Mail=_4A69664B-77B6-4ECA-8AC0-3349BF532CD3 Content-Type: multipart/alternative; boundary="Apple-Mail=_40EC4FF3-8A64-4D32-B59C-4BA83F59AE0E" --Apple-Mail=_40EC4FF3-8A64-4D32-B59C-4BA83F59AE0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes that is what it is. I didn=E2=80=99t know that the HTML was = produced based on the TEXT doc rather than the XML. I have fixed that and a couple of others in the doc. I am trying to = find a way to test it with rfcmarkup before updating. John B. > On Feb 4, 2015, at 10:40 AM, Brian Campbell = wrote: >=20 > I *think* this is the same formatting issue that is discussed, with a = way to work around it, at = http://www.ietf.org/mail-archive/web/jose/current/msg04571.html = >=20 > On Wed, Feb 4, 2015 at 5:26 AM, John Bradley > wrote: > I will take a look at it today. I was using the local python = version I think. >=20 > John B. >=20 >> On Feb 3, 2015, at 11:38 PM, Nat Sakimura > wrote: >>=20 >> Hmmm. A bug at ietf.org rendering engine?=20 >> Perhaps we may repeat of RFC4648 again there to avoid this behaviour.=20= >>=20 >> 2015-02-04 10:50 GMT+09:00 William Denniss >: >> Speaking of Base64url, where it's defined in "Notational = Conventions", is there a way to prevent the HTML markup automatically = linkifying "Section 3.2" ? It's not marked up in the XML, but in the = HTML output it is =E2=80=93 and the auto-generated link is incorrect, as = it points to Section 3.2 in SPOP, rather than 3.2 in RFC4648. >>=20 >> This may seem trivial, but the fact that we're using a less common = variant of Base64url makes me want to provide as much accurate context = as possible to help implementers. >>=20 >> This is how it renders today (note the Section 3.2 link) >>=20 >> Base64url Encoding Base64 encoding using the URL- and = filename-safe >> character set defined in Section=C2=A05 of RFC 4648 = [RFC4648 = ], with all >> trailing '=3D' characters omitted (as permitted by Section 3.2 = ) and >> without the inclusion of any line breaks, whitespace, or other >> additional characters. (See Appendix A = for = notes on implementing >> base64url encoding without padding.) >>=20 >>=20 >> On Tue, Feb 3, 2015 at 6:51 AM, John Bradley > wrote: >> OK I fixed that in bitbucket. >>=20 >> If I don=E2=80=99t hear back from anyone else I will push that = version to the doc tracker this afternoon. >>=20 >> John B. >>=20 >>=20 >>> On Feb 3, 2015, at 10:40 AM, Brian Campbell = > wrote: >>>=20 >>> I went thought appendix B and reproduced the same calculations. = Which is nice. >>>=20 >>> One little nit - to be consitent with the notation defined in =C2=A72,= the appendix B should have >>>=20 >>> BASE64URL(SHA256(ASCII("code_verifier"))) =3D=3D code_challenge >>> rather than >>> Base64url(SHA256(ASCII("code_verifier" ))) =3D=3D code_challenge >>>=20 >>>=20 >>>=20 >>> On Sun, Feb 1, 2015 at 5:07 PM, John Bradley > wrote: >>> = https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da06= e99c225/draft-ietf-oauth-spop-00.txt = >>>=20 >>> I made some edits to the copy in bitbucket. >>>=20 >>> I changed the reference for unreserved URI characters to RFC3986. = The Base64 spec we were pointing to is slightly different. >>> The change allows someone in the future to define a new = code_challenge_method that would allow a JWT to be valid. >>> We unintentionally precluded the use of the =E2=80=9C.=E2=80=9D in = code_challenge and code_verifier.=20 >>>=20 >>> I also added an appendix B to show the steps of S256 in a way = someone could use as a test vector. >>>=20 >>> Appendix B is a first cut at it so give me feedback, and I can push = it to the document tracker later in the week. >>>=20 >>>=20 >>> John B. >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_40EC4FF3-8A64-4D32-B59C-4BA83F59AE0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes that is what it is.  I didn=E2=80=99t know that the = HTML was produced based on the TEXT doc rather than the XML.

I have fixed that and a = couple of others in the doc.   I am trying to find a way to test it = with rfcmarkup before updating.

John B.

On = Feb 4, 2015, at 10:40 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I *think* this is the same formatting issue that is = discussed, with a way to work around it, at http://www.ietf.org/mail-archive/web/jose/current/msg04571.html=

On Wed, Feb 4, 2015 at 5:26 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
 I will take a look at it = today.   I was using the local python version I think.

John B.

On Feb 3, 2015, at 11:38 PM, = Nat Sakimura <sakimura@gmail.com> wrote:

Hmmm. A bug at ietf.org = rendering engine? 
Perhaps we may repeat of RFC4648 = again there to avoid this behaviour. 

2015-02-04= 10:50 GMT+09:00 William Denniss <wdenniss@google.com>:
Speaking of = Base64url, where it's defined in "Notational Conventions", is there a = way to prevent the HTML markup automatically linkifying "Section 3.2" = ?  It's not marked up in the XML, but in the HTML output it is =E2=80= =93 and the auto-generated link is incorrect, as it points to Section = 3.2 in SPOP, rather than 3.2 in RFC4648.

This may seem trivial, = but the fact that we're using a less common variant of Base64url makes = me want to provide as much accurate context as possible to help = implementers.

This is how it renders today (note the Section 3.2 = link)

   Base64url Encoding  Base64 encoding using the URL- and =
filename-safe
      character set defined in Section 5 of RFC 4648 [RFC4648], with all
      trailing '=3D' characters omitted (as permitted by Section 3.2) and
      without the inclusion of any line breaks, whitespace, or other
      additional characters.  (See Appendix A for notes on implementing
      base64url encoding without padding.)


On Tue, = Feb 3, 2015 at 6:51 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
OK I fixed that in = bitbucket.

If I = don=E2=80=99t hear back from anyone else I will push that version to the = doc tracker this afternoon.

John B.


On Feb = 3, 2015, at 10:40 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I went thought = appendix B and = reproduced the same calculations. Which is nice.

One little nit - to be consitent with the notation = defined in =C2=A72, the appendix B should have

BASE64URL(SHA256(ASCII("code_verifier"))) =3D=3D = code_challengerather than
   Base64url(SHA256(ASCII("code_verifier" ))) =3D=3D =
code_challenge



On Sun, Feb 1, 2015 at 5:07 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143= c246658da06e99c225/draft-ietf-oauth-spop-00.txt

I made some edits to the copy in = bitbucket.

I = changed the reference for unreserved URI characters to RFC3986. The Base64 spec we = were pointing to is slightly different.
The change allows someone in = the future to define a new code_challenge_method that would allow a JWT = to be valid.
We unintentionally precluded = the use of the =E2=80=9C.=E2=80=9D in code_challenge and code_verifier. =

I also added an appendix B to = show the steps of S256 in a way someone could use as a test = vector.

Appendix B is a first cut at = it so give me feedback, and I can push it to the document tracker later = in the week.


John B.


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




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



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




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


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



= --Apple-Mail=_40EC4FF3-8A64-4D32-B59C-4BA83F59AE0E-- --Apple-Mail=_4A69664B-77B6-4ECA-8AC0-3349BF532CD3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAyMDQyMDI1NTRaMCMGCSqGSIb3DQEJBDEWBBS/pn99oSdBq7RrduYPwTSb 6vEjRjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBdbl8FU85cSFZf+0JotQzxmQqww2pbs+GVuEtnFyjGcRVqkdU+GGNA 7BKK8wjmcxFL6r1hBvozvvbGZZkcmOlLziTomTeXPqGTK/ZWK00dOJxBeMPw1ahhHIGJ2HOhiAx1 Ea6pMbGHatN/nanm73CImbf8gdiK0pY0bm5hrh6V/GkVvQ/MQaHJPnxek6yk0/cW56LAy0HDRW1Z W2p13ZBc1t00g7cRMbGrA1EcTgIrY0LkN1ns4ai3Q1/ALkNr8hgEmdCuGQ2kPZEjXTXQO0G+H883 BIytLARoBJboWObCHZClBaldJYL6K8aBcgxHWQwE6ggor4CyxfBfc3LuGngEAAAAAAAA --Apple-Mail=_4A69664B-77B6-4ECA-8AC0-3349BF532CD3-- From nobody Wed Feb 4 15:40:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF111A002F; Wed, 4 Feb 2015 15:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 715czBcZmdci; Wed, 4 Feb 2015 15:40:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8BC1A0040; Wed, 4 Feb 2015 15:40:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150204234040.19482.87437.idtracker@ietfa.amsl.com> Date: Wed, 04 Feb 2015 15:40:40 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 23:40:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Authors : Nat Sakimura John Bradley Naveen Agarwal Filename : draft-ietf-oauth-spop-09.txt Pages : 18 Date : 2015-02-04 Abstract: OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-spop-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 4 17:44:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47ED1A00BF for ; Wed, 4 Feb 2015 17:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZOh_jfMLOvF for ; Wed, 4 Feb 2015 17:44:08 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id E3AC21A000D for ; Wed, 4 Feb 2015 17:44:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,521,1418043600"; d="scan'208";a="68305842" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 05 Feb 2015 12:17:45 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7702"; a="331952063" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcavi.tcif.telstra.com.au with ESMTP; 05 Feb 2015 12:43:43 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Thu, 5 Feb 2015 12:43:42 +1100 From: "Manger, James" To: "oauth@ietf.org" Date: Thu, 5 Feb 2015 12:43:41 +1100 Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt Thread-Index: AdBA1AEYXq7rjRewS0OREYk72TcMvgAAIblA Message-ID: <255B9BB34FB7D647A506DC292726F6E12851EBA8C3@WSMSG3153V.srv.dir.telstra.com> References: <20150204234040.19482.87437.idtracker@ietfa.amsl.com> In-Reply-To: <20150204234040.19482.87437.idtracker@ietfa.amsl.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 01:44:10 -0000 > Title : Proof Key for Code Exchange by OAuth Public Clients > Filename : draft-ietf-oauth-spop-09.txt > https://tools.ietf.org/html/draft-ietf-oauth-spop-09 Some nits on this draft: 1. 42 chars. The lower limit of 42 chars for code_verifier: is not mentioned in prose (j= ust the upper limit); is too high (128-bits=3D22-chars is sufficient); and = doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 chars, = not 42). 2.=20 Quotes around "code_verifier" and "code_challenge" in prose are okay, thoug= h not really necessary as the underscore is enough to distinguish them as t= echnical labels. Quotes around these terms in formula is bad as it looks li= ke the formula applies to the 13 or 14 chars of the label. The quoting is a= lso used inconsistently. Suggestion: remove all quotes around "code_verifier" and "code_challenge" i= n prose and formula. For example, change ASCII("code_verifier") to ASCII(code_verifier). 3. Two ways to check code_verifier are given in appendix B, whereas only one o= f these is mentioned in section 4.6. SHA256(verifier) =3D=3D=3D B64-DECODE(challenge) B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop the = 1st from appendix B). It is simpler to mention only one. It also means base= 64url-decoding is never done, and doesn't need to be mentioned in the spec. 4. Expand "MTI" to "mandatory to implement". P.S. Suggesting code challenge method names not exceed 8 chars to be compac= t is a bit perverse given the field holding these values has the long name = "code_challenge_method" ;) -- James Manger From nobody Wed Feb 4 19:56:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44A51A032D for ; Wed, 4 Feb 2015 19:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okrwah2089t9 for ; Wed, 4 Feb 2015 19:56:11 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9B01A0235 for ; Wed, 4 Feb 2015 19:56:11 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id wp4so5084295obc.10 for ; Wed, 04 Feb 2015 19:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I7FEv2GcEa3CrkZBSI7q4iIVPksCpONIRSKQdjhm2A4=; b=cTpBSd4mj11jJbTs0qlDw9xF2nFEyBVAiXKHem9l6bFoivVkIQxmleMTOJ1BlquwUe wSBryQQV7nqUyCSVNOs2NifqZ3oib7JPoE2uFOUgQEzlmzT5iE4gzRAcFOOy+dSx6z6H iNIKYAHJvaoq2Rqvq12V2sF2upzhmcdnkRba2xVAkC/bUBtb2jeW5oMFdGz+4qyID6g8 pv3ClKejWqsWOePeh8MVcheJYZZGynQXBwUPogmLvRAnWTcKNfGF33o5NfmXgPEtJ9Ad uRtNjkBIlqnd+JXQfnXHxU42xsSb+CBo0VctUgU3DK/TA7VAqYdvckAF9d0Zgha9GZZb a/Gw== MIME-Version: 1.0 X-Received: by 10.182.210.197 with SMTP id mw5mr1086933obc.26.1423108558115; Wed, 04 Feb 2015 19:55:58 -0800 (PST) Received: by 10.60.171.196 with HTTP; Wed, 4 Feb 2015 19:55:58 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E12851EBA8C3@WSMSG3153V.srv.dir.telstra.com> References: <20150204234040.19482.87437.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E12851EBA8C3@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 5 Feb 2015 12:55:58 +0900 Message-ID: From: Nat Sakimura To: "Manger, James" Content-Type: multipart/alternative; boundary=001a11c29be8155a80050e4f486f Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 03:56:13 -0000 --001a11c29be8155a80050e4f486f Content-Type: text/plain; charset=UTF-8 2015-02-05 10:43 GMT+09:00 Manger, James : > > Title : Proof Key for Code Exchange by OAuth Public Clients > > Filename : draft-ietf-oauth-spop-09.txt > > https://tools.ietf.org/html/draft-ietf-oauth-spop-09 > > > Some nits on this draft: > > 1. 42 chars. > The lower limit of 42 chars for code_verifier: is not mentioned in prose > (just the upper limit); is too high (128-bits=22-chars is sufficient); and > doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 chars, > not 42). > Thanks for pointing out. > > 2. > Quotes around "code_verifier" and "code_challenge" in prose are okay, > though not really necessary as the underscore is enough to distinguish them > as technical labels. Quotes around these terms in formula is bad as it > looks like the formula applies to the 13 or 14 chars of the label. The > quoting is also used inconsistently. > Suggestion: remove all quotes around "code_verifier" and "code_challenge" > in prose and formula. > For example, change ASCII("code_verifier") to ASCII(code_verifier). > They are actually put in by the tools automagically. In XML, it is , and if HTML is compiled from it, it will appear in fixed width type. However, the xml2txt converter at the tools.ietf.org does convert them to quoted strings. We have also found other nits due to the tools and trying to figure out what to do. It may end up modifying the text to avoid those tools issues. > > > 3. > Two ways to check code_verifier are given in appendix B, whereas only one > of these is mentioned in section 4.6. > SHA256(verifier) === B64-DECODE(challenge) > B64-ENCODE(SHA256(verifier)) === challenge > > I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop the > 1st from appendix B). It is simpler to mention only one. It also means > base64url-decoding is never done, and doesn't need to be mentioned in the > spec. > Good point. > > > 4. > Expand "MTI" to "mandatory to implement". > Will do. > > P.S. Suggesting code challenge method names not exceed 8 chars to be > compact is a bit perverse given the field holding these values has the long > name "code_challenge_method" ;) > Yup. > > -- > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c29be8155a80050e4f486f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-02-05 10:43 GMT+09:00 Manger, James <James.H.Mange= r@team.telstra.com>:
>= ;=C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Proof = Key for Code Exchange by OAuth Public Clients
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-ietf-oauth-spop-09.txt
> https://tools.ietf.org/html/draft-ietf-oauth-spop-09


Some nits on this draft:

1. 42 chars.
The lower limit of 42 chars for code_verifier: is not mentioned in prose (j= ust the upper limit); is too high (128-bits=3D22-chars is sufficient); and = doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 cha= rs, not 42).

Thanks for pointing out.= =C2=A0
=C2=A0

2.
Quotes around "code_verifier" and "code_challenge" in p= rose are okay, though not really necessary as the underscore is enough to d= istinguish them as technical labels. Quotes around these terms in formula i= s bad as it looks like the formula applies to the 13 or 14 chars of the lab= el. The quoting is also used inconsistently.
Suggestion: remove all quotes around "code_verifier" and "co= de_challenge" in prose and formula.
For example, change ASCII("code_verifier") to ASCII(code_verifier= ).

They are actually put in by the tool= s automagically.=C2=A0
In XML, it is <spanx style=3D"verb"= ;> </spanx>, and if HTML is compiled from it, it will appear in fi= xed width type.
However, the xml2txt converter at the tools.ietf.org does convert them to quoted strings.=C2= =A0
We have also found other nits due to th= e tools and trying to figure out what to do.=C2=A0
It may end up modifying the text to avoid those tools issues.=C2=A0=
=C2=A0

3.
Two ways to check code_verifier are given in appendix B, whereas only one o= f these is mentioned in section 4.6.
=C2=A0 SHA256(verifier) =3D=3D=3D B64-DECODE(challenge)
=C2=A0 B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge

I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop the = 1st from appendix B). It is simpler to mention only one. It also means base= 64url-decoding is never done, and doesn't need to be mentioned in the s= pec.

Good point.=C2=A0
=C2=A0=


4.
Expand "MTI" to "mandatory to implement".

Will do.=C2=A0
=C2=A0

P.S. Suggesting code challenge method names not exceed 8 chars to be compac= t is a bit perverse given the field holding these values has the long name = "code_challenge_method" ;)

Yu= p.=C2=A0
=C2=A0

--
James Manger

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



--
=
Nat Sakimura (=3Dnat)
Chairman, OpenID F= oundation
http://= nat.sakimura.org/
@_nat_en
--001a11c29be8155a80050e4f486f-- From nobody Thu Feb 5 08:49:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD171A89FB for ; Thu, 5 Feb 2015 08:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_N1mBhI4a4k for ; Thu, 5 Feb 2015 08:49:35 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6945E1A07BD for ; Thu, 5 Feb 2015 08:49:35 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id l89so7000954qgf.6 for ; Thu, 05 Feb 2015 08:49:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=y6tTTIspmnpdSjzQKQM557XdQ1d+E3YwxH1WtGitoJQ=; b=RLSFOanRtIaWwFDdF5UZyxcQ0Z1LrNgW0HMZyN63LkyByxBTpjW2OO7EYMuIM07Rtn E6hSrqHTAkQuW7hs/9FBR+CrGeUm//TYr+R0hO/DHdthTDGsJ/tq2DdABDUeYFFlV8Qv 65YkkblUbg75lC54XhJ1iYDmtUP6fBWIhKFUw776rz2EOhQ1MOmCITNTi5tEAiD0QYsL 79fi2h+9KK4iki6Avtf1S/7R2S/A+AwTho6t7n+/3qib3Jx7bTwAGi0gBQDLf5EzSqut UQWOvDcM1x4N0Z8UxLm+M0+eZzCz4nkxcRARVJgGX//Gc01v8cv5Hu8rWTj6aXQQf0/5 miOQ== X-Gm-Message-State: ALoCoQlZON4FEtplGBlHlQYmbnm5Ye685GnrTjFNBAhwKuxflAf/5z7b0fFSxlcODaZ46E/DCOBQ X-Received: by 10.229.99.134 with SMTP id u6mr10261636qcn.10.1423154974549; Thu, 05 Feb 2015 08:49:34 -0800 (PST) Received: from [192.168.8.100] ([181.202.19.170]) by mx.google.com with ESMTPSA id o88sm985660qge.22.2015.02.05.08.49.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 08:49:33 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_A5BA1611-85EB-40CF-BA8F-3A1CE8CBC534"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <255B9BB34FB7D647A506DC292726F6E12851EBA8C3@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 5 Feb 2015 13:49:29 -0300 Message-Id: <97C03A16-4299-44A5-B121-58C6542DF6C1@ve7jtb.com> References: <20150204234040.19482.87437.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E12851EBA8C3@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 16:49:37 -0000 --Apple-Mail=_A5BA1611-85EB-40CF-BA8F-3A1CE8CBC534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Inline > On Feb 4, 2015, at 10:43 PM, Manger, James = wrote: >=20 >> Title : Proof Key for Code Exchange by OAuth Public = Clients >> Filename : draft-ietf-oauth-spop-09.txt >> https://tools.ietf.org/html/draft-ietf-oauth-spop-09 >=20 >=20 > Some nits on this draft: >=20 > 1. 42 chars. > The lower limit of 42 chars for code_verifier: is not mentioned in = prose (just the upper limit); is too high (128-bits=3D22-chars is = sufficient); and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 = bytes) gives 43 chars, not 42). In my editors draft I fixed the 43 octet base64url encoding of 32bytes. = I originally had 43 but it got changed at some point =20 Is there working group feedback on making the lower limit clear in the = prose and if so what should it be? 22-chars (128 bits) or 43 char (256 = bits)? >=20 > 2.=20 > Quotes around "code_verifier" and "code_challenge" in prose are okay, = though not really necessary as the underscore is enough to distinguish = them as technical labels. Quotes around these terms in formula is bad as = it looks like the formula applies to the 13 or 14 chars of the label. = The quoting is also used inconsistently. > Suggestion: remove all quotes around "code_verifier" and = "code_challenge" in prose and formula. > For example, change ASCII("code_verifier") to ASCII(code_verifier). >=20 I am going to leave this for a later formatting cleanup at the moment, I = need to find a good style compromise that works with rfcmarkup. > 3. > Two ways to check code_verifier are given in appendix B, whereas only = one of these is mentioned in section 4.6. > SHA256(verifier) =3D=3D=3D B64-DECODE(challenge) > B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge >=20 > I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop = the 1st from appendix B). It is simpler to mention only one. It also = means base64url-decoding is never done, and doesn't need to be mentioned = in the spec. >=20 Yes when I added the example I realized that the normative text was the = more complicated way to do the comparison. I will go back and refactor the main text to talk about the simpler = comparison and drop the base64url-decode references. >=20 > 4. > Expand "MTI" to "mandatory to implement". Done in editors draft. >=20 > P.S. Suggesting code challenge method names not exceed 8 chars to be = compact is a bit perverse given the field holding these values has the = long name "code_challenge_method" ;) On the topic of the parameter name "code_challange_method", James = has a point in that it is a bit long. We could shorten it to "ccm". If we want to change the name sooner is = better than later. =20 It is that balance between compactness and clear parameter names for = developers, that we keep running into. I don't know that encouraging longer parameter values is the best = direction. Feedback please John B. >=20 > -- > James Manger >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A5BA1611-85EB-40CF-BA8F-3A1CE8CBC534 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAyMDUxNjQ5MzBaMCMGCSqGSIb3DQEJBDEWBBTlWtkFqE6kv4DZmHf6QQEW cEG9kzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAHDs02KBs7P8AzjzKfx1lB14gvo6XH0xNeypZn6YebHPX6WLzTvdZM XyStuKlWYB2ZxdAuJiPtFbXQ/SjZ/Ic+I85pVlgGN2KWsiATzKmgMqMpBZzKl+eVktXDsjRpKVsw RE9kpw4asyw5pIOJ3L2+rRf9AsRQr6VSsunjQLuCTsZyYxz+UsROVfWARx+tWKj4cYzNoejqTKu2 Xc+PSGpsBRPfFyo3rlI+rf2+8k7dCCSZZ5P4bThCATGb1DpJ69aeXdHIaMTJ6YEoNZ0L9XUsQI6k 7C/GYkasycKRlek90ni6vw6Bx3iBojoXUu+atxpczQpjajHziE5FvCpO1MMsAAAAAAAA --Apple-Mail=_A5BA1611-85EB-40CF-BA8F-3A1CE8CBC534-- From nobody Thu Feb 5 10:09:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739691A0377 for ; Thu, 5 Feb 2015 10:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sTJ3pb37Xiz for ; Thu, 5 Feb 2015 10:09:42 -0800 (PST) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FBFD1A87DB for ; Thu, 5 Feb 2015 10:09:36 -0800 (PST) Received: from mail-ig0-f182.google.com ([209.85.213.182]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKVNOx39QhxbjGkmj3/5Ml4jS0sYca9Onn@postini.com; Thu, 05 Feb 2015 10:09:36 PST Received: by mail-ig0-f182.google.com with SMTP id h15so15646163igd.3 for ; Thu, 05 Feb 2015 10:09:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8Q8c4+uwmnAh01cTxaj7kPsY3OFdc/w3gF7CvW3eLIw=; b=JUdJJIoGErKlmDLwvSgp/3xkcdY6QpGzNO6BoHjFpgnnjdIms8i5XF3yfPLXnnyqjC Za9tg4QKweB/Kjhu7/ofnfmKjTkyud9dF900JMdtlEvaahZ2AqT5jm0xsQPaebmVH82V T6RZnjhAM25WaCuEVpH19HWkzmeuXY+AGLNqyG13x9VgFb8zvcMfk/y+F2FbXEz89AEd GCvFrU0/yWIEbnxbnG8H4xa0zUaZaF4Ffr2i1syHZij5euoVIT1STHO2hULbemD7GL4E flcDI6fGOgm5lc/xixWVToDDIyDQaH4QE/jA71OTxK80wPzmt1WbTXNsVEuaBkEbO0f2 NCiw== X-Gm-Message-State: ALoCoQk4Rqx8B3A6Z9I01zxZ4nPVPD52AJHHylVaoIk4BLu5HzGBz+Qnkv7oBmXcCdzmGQZsccwphVbwA1Q4Rfl/3oNs8fOdPPJIDN8ydkZQvy539ccaBeEYU75GL0NqIncE4JDlBH04 X-Received: by 10.42.113.2 with SMTP id a2mr5382138icq.30.1423159775292; Thu, 05 Feb 2015 10:09:35 -0800 (PST) X-Received: by 10.42.113.2 with SMTP id a2mr5382125icq.30.1423159775111; Thu, 05 Feb 2015 10:09:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Thu, 5 Feb 2015 10:09:04 -0800 (PST) In-Reply-To: <97C03A16-4299-44A5-B121-58C6542DF6C1@ve7jtb.com> References: <20150204234040.19482.87437.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E12851EBA8C3@WSMSG3153V.srv.dir.telstra.com> <97C03A16-4299-44A5-B121-58C6542DF6C1@ve7jtb.com> From: Brian Campbell Date: Thu, 5 Feb 2015 11:09:04 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a11c3e82adb0259050e5b348c Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 18:09:45 -0000 --001a11c3e82adb0259050e5b348c Content-Type: text/plain; charset=UTF-8 22-chars (128 bits) as a lower limit seems just fine for this case. "ccm" works for me but I don't feel strongly about it either way. On Thu, Feb 5, 2015 at 9:49 AM, John Bradley wrote: > Inline > > > > On Feb 4, 2015, at 10:43 PM, Manger, James < > James.H.Manger@team.telstra.com> wrote: > > > >> Title : Proof Key for Code Exchange by OAuth Public Clients > >> Filename : draft-ietf-oauth-spop-09.txt > >> https://tools.ietf.org/html/draft-ietf-oauth-spop-09 > > > > > > Some nits on this draft: > > > > 1. 42 chars. > > The lower limit of 42 chars for code_verifier: is not mentioned in prose > (just the upper limit); is too high (128-bits=22-chars is sufficient); and > doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 chars, > not 42). > > In my editors draft I fixed the 43 octet base64url encoding of 32bytes. I > originally had 43 but it got changed at some point > > Is there working group feedback on making the lower limit clear in the > prose and if so what should it be? 22-chars (128 bits) or 43 char (256 > bits)? > > > > > > 2. > > Quotes around "code_verifier" and "code_challenge" in prose are okay, > though not really necessary as the underscore is enough to distinguish them > as technical labels. Quotes around these terms in formula is bad as it > looks like the formula applies to the 13 or 14 chars of the label. The > quoting is also used inconsistently. > > Suggestion: remove all quotes around "code_verifier" and > "code_challenge" in prose and formula. > > For example, change ASCII("code_verifier") to ASCII(code_verifier). > > > > I am going to leave this for a later formatting cleanup at the moment, I > need to find a good style compromise that works with rfcmarkup. > > > 3. > > Two ways to check code_verifier are given in appendix B, whereas only > one of these is mentioned in section 4.6. > > SHA256(verifier) === B64-DECODE(challenge) > > B64-ENCODE(SHA256(verifier)) === challenge > > > > I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop > the 1st from appendix B). It is simpler to mention only one. It also means > base64url-decoding is never done, and doesn't need to be mentioned in the > spec. > > > Yes when I added the example I realized that the normative text was the > more complicated way to do the comparison. > > I will go back and refactor the main text to talk about the simpler > comparison and drop the base64url-decode references. > > > > 4. > > Expand "MTI" to "mandatory to implement". > > Done in editors draft. > > > > P.S. Suggesting code challenge method names not exceed 8 chars to be > compact is a bit perverse given the field holding these values has the long > name "code_challenge_method" ;) > > On the topic of the parameter name "code_challange_method", James has > a point in that it is a bit long. > > We could shorten it to "ccm". If we want to change the name sooner is > better than later. > > It is that balance between compactness and clear parameter names for > developers, that we keep running into. > > I don't know that encouraging longer parameter values is the best > direction. > > Feedback please > > John B. > > > > -- > > James Manger > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11c3e82adb0259050e5b348c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
22-chars (128 bits) as a lower limit seems just fine = for this case.

"ccm" works for me but I don't fe= el strongly about it either way.



On Thu, Feb 5, 2015 at 9:49 AM, John Bradl= ey <ve7jtb@ve7jtb.com> wrote:
Inline


> On Feb 4, 2015, at 10:43 PM, Manger, James <James.H.Manger@team.telstra.com> wrote:<= br> >
>>=C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Proof= Key for Code Exchange by OAuth Public Clients
>>=C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ie= tf-oauth-spop-09.txt
>> https://tools.ietf.org/html/draft-ietf-oauth-spop-09 >
>
> Some nits on this draft:
>
> 1. 42 chars.
> The lower limit of 42 chars for code_verifier: is not mentioned in pro= se (just the upper limit); is too high (128-bits=3D22-chars is sufficient);= and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 4= 3 chars, not 42).

In my editors draft I fixed the 43 octet base64url encoding of 32byt= es.=C2=A0 I originally had 43 but it got changed at some point

Is there working group feedback on making the lower limit clear in the pros= e and if so what should it be?=C2=A0 22-chars (128 bits) or 43 char (256 bi= ts)?


>
> 2.
> Quotes around "code_verifier" and "code_challenge"= in prose are okay, though not really necessary as the underscore is enough= to distinguish them as technical labels. Quotes around these terms in form= ula is bad as it looks like the formula applies to the 13 or 14 chars of th= e label. The quoting is also used inconsistently.
> Suggestion: remove all quotes around "code_verifier" and &qu= ot;code_challenge" in prose and formula.
> For example, change ASCII("code_verifier") to ASCII(code_ver= ifier).
>

I am going to leave this for a later formatting cleanup at the momen= t, I need to find a good style compromise that works with rfcmarkup.

> 3.
> Two ways to check code_verifier are given in appendix B, whereas only = one of these is mentioned in section 4.6.
>=C2=A0 SHA256(verifier) =3D=3D=3D B64-DECODE(challenge)
>=C2=A0 B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge
>
> I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop= the 1st from appendix B). It is simpler to mention only one. It also means= base64url-decoding is never done, and doesn't need to be mentioned in = the spec.
>
Yes when I added the example I realized that the normative text was = the more complicated way to do the comparison.

I will go back and refactor the main text to talk about the simpler compari= son and drop the base64url-decode references.
>
> 4.
> Expand "MTI" to "mandatory to implement".

Done in editors draft.
>
> P.S. Suggesting code challenge method names not exceed 8 chars to be c= ompact is a bit perverse given the field holding these values has the long = name "code_challenge_method" ;)

=C2=A0 On the topic of the parameter=C2=A0 name=C2=A0 "code_cha= llange_method",=C2=A0 James has a point in that it is a bit long.

We could shorten it to "ccm".=C2=A0 =C2=A0If we want to change th= e name sooner is better than later.

It is that balance between compactness and clear parameter names for develo= pers, that we keep running into.

I don't know that encouraging longer parameter values is the best direc= tion.

Feedback please

John B.
>
> --
> James Manger
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


--001a11c3e82adb0259050e5b348c-- From nobody Thu Feb 5 12:12:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035D51A6F3A for ; Thu, 5 Feb 2015 12:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLaHWNUyTS4T for ; Thu, 5 Feb 2015 12:12:11 -0800 (PST) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6431A8AB5 for ; Thu, 5 Feb 2015 12:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1423167097; bh=bGlQmVV7aFSiBWesoPsu9+nC8KFR6TySn+SfRiU+Ub0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=qf3lYQxvyktMkWeVecDSKK77/DxASZUEx8J2whdIYIKH6BQ7yq4pUdVkbYLVgh+lgKF+sDZWNhtKyn7Vr9mtYBE2O3Gb3TEmBCwE49qqSQ1rnzP4YGOTuCA4beultFikk3Tl8Qo9lWPjJ8Ks9hIKKtTrqBrvLiMjZKiFLIS3tskrP9C1ICjnaATJ4mQuTzZ0oF2QMKZzwqGFZhS1VIsl7hJK4hSm1A1CAJjU2n4nuVq/hNc/BUoEQS12cSqwMY1Cs6N4R4FZUoOxU3pE2YKwG+CjZLNeyyS/ckDSf+heT0fJH/oyB0av3ZoUACURxqcGEN1LtC8dyo1F9OeKIje6JQ== Received: from [98.139.212.151] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2015 20:11:37 -0000 Received: from [98.139.212.249] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2015 20:11:37 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 05 Feb 2015 20:11:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 55224.69364.bm@omp1058.mail.bf1.yahoo.com X-YMail-OSG: 0Xppt1YVM1lzYk470uTrMmcRTQ9t4wTXh2T4Z1YlG2Iam9KtlAfzMRnJwesyPI4 3687g8yJ9dAb2WEEgrqfPwBaM_oWfwpPiqedq5e_tSLg7GrHTOwFdI6kM26pPGo.7N1QS3PDIDBn KFElahNzItYTjSn6QCbk92QAicn5b9UBzq1dFPmJx.OTXYO5TmmNbUhCZMzK2pBtHVHnMwdzs4DZ fmfyyvvVrK19P2PtJXj.yaIUORc9yil2ib1RogxTvuCdWBf1YPUsbjSempGtyeIBS.V2t93yBx5V JeBiGMmCWbbPnFyPviC6Ym_OLUX7psM7O0x7dT4CmYMdNoHt26HhKlGfsRyFKymRmPBKbdQuiyoE RQMor6qQN8gYB8wwaOtBlyLlmsHRNcNB9BflebI2BsJohc.Cvdmhcp.76SlwvWBiXgF7sSLlYeZe PsXy8XthXrLI7rbNoGSzU6293V5Cy5MuZkwNSRk1cbCE3sxqYOnU7JDW5ZRgX0oeBPZeWWhhWkIF U1m37q5ZbqWL.7g-- Received: by 76.13.27.54; Thu, 05 Feb 2015 20:11:36 +0000 Date: Thu, 5 Feb 2015 20:11:36 +0000 (UTC) From: Bill Mills To: Brian Campbell , John Bradley Message-ID: <539792956.415454.1423167096100.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_415453_1585801587.1423167096094" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 20:12:13 -0000 ------=_Part_415453_1585801587.1423167096094 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is there a compelling reason to make that length fixed? =C2=A0 =20 On Thursday, February 5, 2015 10:10 AM, Brian Campbell wrote: =20 22-chars (128 bits) as a lower limit seems just fine for this case. "ccm" works for me but I don't feel strongly about it either way. On Thu, Feb 5, 2015 at 9:49 AM, John Bradley wrote: Inline > On Feb 4, 2015, at 10:43 PM, Manger, James wrote: > >>=C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Proof Key f= or Code Exchange by OAuth Public Clients >>=C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-oau= th-spop-09.txt >> https://tools.ietf.org/html/draft-ietf-oauth-spop-09 > > > Some nits on this draft: > > 1. 42 chars. > The lower limit of 42 chars for code_verifier: is not mentioned in prose = (just the upper limit); is too high (128-bits=3D22-chars is sufficient); an= d doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 chars= , not 42). In my editors draft I fixed the 43 octet base64url encoding of 32bytes.=C2= =A0 I originally had 43 but it got changed at some point Is there working group feedback on making the lower limit clear in the pros= e and if so what should it be?=C2=A0 22-chars (128 bits) or 43 char (256 bi= ts)? > > 2. > Quotes around "code_verifier" and "code_challenge" in prose are okay, tho= ugh not really necessary as the underscore is enough to distinguish them as= technical labels. Quotes around these terms in formula is bad as it looks = like the formula applies to the 13 or 14 chars of the label. The quoting is= also used inconsistently. > Suggestion: remove all quotes around "code_verifier" and "code_challenge"= in prose and formula. > For example, change ASCII("code_verifier") to ASCII(code_verifier). > I am going to leave this for a later formatting cleanup at the moment, I ne= ed to find a good style compromise that works with rfcmarkup. > 3. > Two ways to check code_verifier are given in appendix B, whereas only one= of these is mentioned in section 4.6. >=C2=A0 SHA256(verifier) =3D=3D=3D B64-DECODE(challenge) >=C2=A0 B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge > > I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop th= e 1st from appendix B). It is simpler to mention only one. It also means ba= se64url-decoding is never done, and doesn't need to be mentioned in the spe= c. > Yes when I added the example I realized that the normative text was the mor= e complicated way to do the comparison. I will go back and refactor the main text to talk about the simpler compari= son and drop the base64url-decode references. > > 4. > Expand "MTI" to "mandatory to implement". Done in editors draft. > > P.S. Suggesting code challenge method names not exceed 8 chars to be comp= act is a bit perverse given the field holding these values has the long nam= e "code_challenge_method" ;) =C2=A0 On the topic of the parameter=C2=A0 name=C2=A0 "code_challange_metho= d",=C2=A0 James has a point in that it is a bit long. We could shorten it to "ccm".=C2=A0 =C2=A0If we want to change the name soo= ner is better than later. It is that balance between compactness and clear parameter names for develo= pers, that we keep running into. I don't know that encouraging longer parameter values is the best direction= . Feedback please John B. > > -- > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_415453_1585801587.1423167096094 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there a compelling reason to make t= hat length fixed?  


=
On Thursday, Fe= bruary 5, 2015 10:10 AM, Brian Campbell <bcampbell@pingidentity.com> = wrote:


22-chars (128 bits) as a lowe= r limit seems just fine for this case.

"ccm" works for me but I don't feel strongly about it either way.


On Thu, Feb 5, 2015 at 9:49 AM, John Bradley <<= a rel=3D"nofollow" shape=3D"rect" ymailto=3D"mailto:ve7jtb@ve7jtb.com" targ= et=3D"_blank" href=3D"mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com> wrote:
Inline


> On Feb 4, 2015, at 10:43 PM, Manger, James <James.H.Manger@team.t= elstra.com> wrote:
>
>>    Title           : Proof= Key for Code Exchange by OAuth Public Clients
>>      Filename        : draft-ie= tf-oauth-spop-09.txt
>> https://tools.ietf.org/htm= l/draft-ietf-oauth-spop-09
>
>
> Some nits on this draft:
>
> 1. 42 chars.
> The lower limit of 42 chars for code_verifier: is not mentioned in pro= se (just the upper limit); is too high (128-bits=3D22-chars is sufficient);= and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 ch= ars, not 42).

In my editors draft I fixed the 43 octet base64url encoding of 32byt= es.  I originally had 43 but it got changed at some point

Is there working group feedback on making the lower limit clear in the pros= e and if so what should it be?  22-chars (128 bits) or 43 char (256 bi= ts)?


>
> 2.
> Quotes around "code_verifier" and "code_challenge" in prose are okay, = though not really necessary as the underscore is enough to distinguish them= as technical labels. Quotes around these terms in formula is bad as it loo= ks like the formula applies to the 13 or 14 chars of the label. The quoting= is also used inconsistently.
> Suggestion: remove all quotes around "code_verifier" and "code_challen= ge" in prose and formula.
> For example, change ASCII("code_verifier") to ASCII(code_verifier). >

I am going to leave this for a later formatting cleanup at the momen= t, I need to find a good style compromise that works with rfcmarkup.

> 3.
> Two ways to check code_verifier are given in appendix B, whereas only = one of these is mentioned in section 4.6.
>  SHA256(verifier) =3D=3D=3D B64-DECODE(challenge)
>  B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge
>
> I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop= the 1st from appendix B). It is simpler to mention only one. It also means= base64url-decoding is never done, and doesn't need to be mentioned in the = spec.
>
Yes when I added the example I realized that the normative text was = the more complicated way to do the comparison.

I will go back and refactor the main text to talk about the simpler compari= son and drop the base64url-decode references.
>
> 4.
> Expand "MTI" to "mandatory to implement".

Done in editors draft.
>
> P.S. Suggesting code challenge method names not exceed 8 chars to be c= ompact is a bit perverse given the field holding these values has the long = name "code_challenge_method" ;)

  On the topic of the parameter  name  "code_challang= e_method",  James has a point in that it is a bit long.

We could shorten it to "ccm".   If we want to change the name soo= ner is better than later.

It is that balance between compactness and clear parameter names for develo= pers, that we keep running into.

I don't know that encouraging longer parameter values is the best direction= .

Feedback please

John B.
>
> --
> James Manger
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/o= auth


____________________________________________= ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>


=



<= /div>
------=_Part_415453_1585801587.1423167096094-- From nobody Thu Feb 5 12:22:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580A81A8AAE for ; Thu, 5 Feb 2015 12:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWYrbwvrdiG2 for ; Thu, 5 Feb 2015 12:21:58 -0800 (PST) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457481A8AA8 for ; Thu, 5 Feb 2015 12:21:58 -0800 (PST) Received: by mail-qg0-f52.google.com with SMTP id h3so4023370qgf.11 for ; Thu, 05 Feb 2015 12:21:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=W4FGxIF4c7McvdXHupDnz7Sa/sohhqQlEGMDWhvCMV4=; b=CWXibGLuacGxWN67nLtfXDEU2coM77diUxs+Mn011v1H/YtuEQDNmO3kbcBohkl6Yg Tjl/NezdxKByRUPQ0IwwJqRkZ77l3ps0yUk+omuJGIF5QR8uAIUXfd2grYcKRUtbftl4 QCtiWe1C/C/JCKNla1+SK6XO5XCkPQnj0ImzNbwMcWhMLdn3vmz9p+ILIS+WZ71aFPiL rQhxkCUIjMuXbgZGOdDSPOLw92DDWC74og0va/E2EX9wPdtJkEYIwAN10poRTGhHu31R 5BKS7vmY0zD+Zv6b/dFp1T8vOZZKwSLCWerF/+z9XBgqsTzpJWMjdtGFtLbpLYccL8MF f5jw== X-Gm-Message-State: ALoCoQkTH+pxFaJnsY8vU6zd5pQu8k/nwaN+63cp5deSB+GiiM2vw7w4y2TKDe9RlPpVOlZngv/W X-Received: by 10.224.134.202 with SMTP id k10mr12294808qat.32.1423167717429; Thu, 05 Feb 2015 12:21:57 -0800 (PST) Received: from [192.168.8.100] ([181.202.19.170]) by mx.google.com with ESMTPSA id s63sm231635qgd.26.2015.02.05.12.21.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 12:21:56 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_5749EFEF-3D93-478A-B30F-3EF25F059030"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <539792956.415454.1423167096100.JavaMail.yahoo@mail.yahoo.com> Date: Thu, 5 Feb 2015 17:21:53 -0300 Message-Id: References: <539792956.415454.1423167096100.JavaMail.yahoo@mail.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 20:22:04 -0000 --Apple-Mail=_5749EFEF-3D93-478A-B30F-3EF25F059030 Content-Type: multipart/alternative; boundary="Apple-Mail=_72702340-7325-4563-BB70-97148307CFB8" --Apple-Mail=_72702340-7325-4563-BB70-97148307CFB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We are discussing the minimum size, the max is currently 128 = characters. > On Feb 5, 2015, at 5:11 PM, Bill Mills wrote: >=20 > Is there a compelling reason to make that length fixed? =20 >=20 >=20 >=20 > On Thursday, February 5, 2015 10:10 AM, Brian Campbell = wrote: >=20 >=20 > 22-chars (128 bits) as a lower limit seems just fine for this case. >=20 > "ccm" works for me but I don't feel strongly about it either way. >=20 >=20 >=20 > On Thu, Feb 5, 2015 at 9:49 AM, John Bradley > wrote: > Inline >=20 >=20 > > On Feb 4, 2015, at 10:43 PM, Manger, James = > wrote: > > > >> Title : Proof Key for Code Exchange by OAuth Public = Clients > >> Filename : draft-ietf-oauth-spop-09.txt > >> https://tools.ietf.org/html/draft-ietf-oauth-spop-09 = > > > > > > Some nits on this draft: > > > > 1. 42 chars. > > The lower limit of 42 chars for code_verifier: is not mentioned in = prose (just the upper limit); is too high (128-bits=3D22-chars is = sufficient); and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 = bytes) gives 43 chars, not 42). >=20 > In my editors draft I fixed the 43 octet base64url encoding of = 32bytes. I originally had 43 but it got changed at some point >=20 > Is there working group feedback on making the lower limit clear in the = prose and if so what should it be? 22-chars (128 bits) or 43 char (256 = bits)? >=20 >=20 > > > > 2. > > Quotes around "code_verifier" and "code_challenge" in prose are = okay, though not really necessary as the underscore is enough to = distinguish them as technical labels. Quotes around these terms in = formula is bad as it looks like the formula applies to the 13 or 14 = chars of the label. The quoting is also used inconsistently. > > Suggestion: remove all quotes around "code_verifier" and = "code_challenge" in prose and formula. > > For example, change ASCII("code_verifier") to ASCII(code_verifier). > > >=20 > I am going to leave this for a later formatting cleanup at the moment, = I need to find a good style compromise that works with rfcmarkup. >=20 > > 3. > > Two ways to check code_verifier are given in appendix B, whereas = only one of these is mentioned in section 4.6. > > SHA256(verifier) =3D=3D=3D B64-DECODE(challenge) > > B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge > > > > I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and = drop the 1st from appendix B). It is simpler to mention only one. It = also means base64url-decoding is never done, and doesn't need to be = mentioned in the spec. > > > Yes when I added the example I realized that the normative text was = the more complicated way to do the comparison. >=20 > I will go back and refactor the main text to talk about the simpler = comparison and drop the base64url-decode references. > > > > 4. > > Expand "MTI" to "mandatory to implement". >=20 > Done in editors draft. > > > > P.S. Suggesting code challenge method names not exceed 8 chars to be = compact is a bit perverse given the field holding these values has the = long name "code_challenge_method" ;) >=20 > On the topic of the parameter name "code_challange_method", James = has a point in that it is a bit long. >=20 > We could shorten it to "ccm". If we want to change the name sooner = is better than later. >=20 > It is that balance between compactness and clear parameter names for = developers, that we keep running into. >=20 > I don't know that encouraging longer parameter values is the best = direction. >=20 > Feedback please >=20 > John B. > > > > -- > > James Manger > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_72702340-7325-4563-BB70-97148307CFB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We are discussing the minimum size,  the max is = currently 128 characters.


On Feb 5, 2015, at 5:11 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Is there a compelling reason to make that length fixed? =  



On Thursday, = February 5, 2015 10:10 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
=


22-chars (128 = bits) as a lower limit seems just fine for this case.

"ccm" works for me but I = don't feel strongly about it either way.



On Thu, Feb 5, 2015 at 9:49 AM, John = Bradley <ve7jtb@ve7jtb.com> wrote:
Inline


> On Feb 4, 2015, at 10:43 PM, Manger, James <James.H.Manger@team.telstra.com> wrote:
>
>>    Title           : = Proof Key for Code Exchange by OAuth Public Clients
>>      Filename        : = draft-ietf-oauth-spop-09.txt
>> https://tools.ietf.org/html/draft-ietf-oauth-spop-09
>
>
> Some nits on this draft:
>
> 1. 42 chars.
> The lower limit of 42 chars for code_verifier: is not mentioned in = prose (just the upper limit); is too high (128-bits=3D22-chars is = sufficient); and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 = bytes) gives 43 chars, not 42).

In my editors draft I fixed the 43 octet base64url encoding of = 32bytes.  I originally had 43 but it got changed at some point

Is there working group feedback on making the lower limit clear in the = prose and if so what should it be?  22-chars (128 bits) or 43 char = (256 bits)?


>
> 2.
> Quotes around "code_verifier" and "code_challenge" in prose are = okay, though not really necessary as the underscore is enough to = distinguish them as technical labels. Quotes around these terms in = formula is bad as it looks like the formula applies to the 13 or 14 = chars of the label. The quoting is also used inconsistently.
> Suggestion: remove all quotes around "code_verifier" and = "code_challenge" in prose and formula.
> For example, change ASCII("code_verifier") to = ASCII(code_verifier).
>

I am going to leave this for a later formatting cleanup at the = moment, I need to find a good style compromise that works with = rfcmarkup.

> 3.
> Two ways to check code_verifier are given in appendix B, whereas = only one of these is mentioned in section 4.6.
>  SHA256(verifier) =3D=3D=3D B64-DECODE(challenge)
>  B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge
>
> I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and = drop the 1st from appendix B). It is simpler to mention only one. It = also means base64url-decoding is never done, and doesn't need to be = mentioned in the spec.
>
Yes when I added the example I realized that the normative text = was the more complicated way to do the comparison.

I will go back and refactor the main text to talk about the simpler = comparison and drop the base64url-decode references.
>
> 4.
> Expand "MTI" to "mandatory to implement".

Done in editors draft.
>
> P.S. Suggesting code challenge method names not exceed 8 chars to = be compact is a bit perverse given the field holding these values has = the long name "code_challenge_method" ;)

  On the topic of the parameter  name  = "code_challange_method",  James has a point in that it is a bit = long.

We could shorten it to "ccm".   If we want to change the name = sooner is better than later.

It is that balance between compactness and clear parameter names for = developers, that we keep running into.

I don't know that encouraging longer parameter values is the best = direction.

Feedback please

John B.
>
> --
> James Manger
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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



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


=

= --Apple-Mail=_72702340-7325-4563-BB70-97148307CFB8-- --Apple-Mail=_5749EFEF-3D93-478A-B30F-3EF25F059030 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAyMDUyMDIxNTRaMCMGCSqGSIb3DQEJBDEWBBTogngnQCABQGhQ9IhaRc1e rkyrxzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQA4WZoxV5Fje/oEG/OW9uqI6vEculXABOi6WKsUgTZ2A8kQ5Cy+V42x ioJzA5mOqFmN+f/RkGtxMJTuxVhCvCqUr29qtf1b3Qm3u+ZrnN8Qv53ZhzKFWzsBVc0RfFyR2bEf kYvlMEmnRpYM7B7iFW7OElWw+fGefFLmLXc5Wl/Mo/TrqtslY8E5bt/gloqhHZEicqwdGTyt+FsL 2LK/QNhtGeqG1+0XmCzP6ivijhvXljTFEdgl5FiBDqgmZMIoLVVJs+VzUfTd1J6U8k5LW8cGSW7v 13QRmXtmQRimDYWVrQOt+AU6p/9WFf+3QwtgHyJNr9bv/IArtyeN6gkKHVUCAAAAAAAA --Apple-Mail=_5749EFEF-3D93-478A-B30F-3EF25F059030-- From nobody Thu Feb 5 12:54:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0031A8B84 for ; Thu, 5 Feb 2015 12:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poipe72EpTm8 for ; Thu, 5 Feb 2015 12:54:23 -0800 (PST) Received: from nm38-vm0.bullet.mail.bf1.yahoo.com (nm38-vm0.bullet.mail.bf1.yahoo.com [72.30.239.16]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2442F1A8AF6 for ; Thu, 5 Feb 2015 12:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1423169662; bh=DJsYO/oLGLp+Lxn59qAp0lx4xNzbubWmiAa2QGw7LQ0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=T9LKKTZpw0NEUMdXS0DqfcB3wEALxnGcZpFtAWLr5ifufLbOeay7X/ZsRBbua+TQ9biqjjZBxExouX4Vz8wcZBtxXF55j2NwbcHX6PgfAYh//xo1bLwrG7vh0YJzcgwj0wLovc+jX1tNrwtIII14M+++r9Bmm1f0IawedVwEOeme6EYo4X0n0GHFX/C4msvD3/78TtdDNeBWhFBV06c4EpyePWfeXmolMSOsjqNKCavZekTmCj/U5+Kk1fBwah1CuUI2aVy4Sg5r4ZOiSJVAH+H1wDcA32uP3NyjQPU34pdCX45hKNx5MX4DPOQ3a2j9YxMKrR9OQf6qTSVQYN47aA== Received: from [66.196.81.172] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2015 20:54:22 -0000 Received: from [98.139.212.239] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2015 20:54:22 -0000 Received: from [127.0.0.1] by omp1048.mail.bf1.yahoo.com with NNFMP; 05 Feb 2015 20:54:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 258358.40147.bm@omp1048.mail.bf1.yahoo.com X-YMail-OSG: cgoA8rMVM1lVdUzpTUTUtuInc6T5uZXNGuvwKD9fqy79P8WfMj0uJpoQg2lJEdG UI1Ljff2IT2q9RUvqRw9tjBkokGIFSJdcn7DgeJSo6iGQF45Rcyfyyc4uYffE74Lq_ItSTQTRyw3 tSVIcokE.QAOsAJ8ryq_Ht2vnZBkVnxte5Bl8h5sJpGrfCurCIvbig1BdKqlU3DQrf2qpx0PVenO uox1Jixo2CumFmbgZWRJp8anUE7wihwVyBZCDc27q1JOw9meAqfehseYsL6wWh70e7q6A2yQvnd4 Z11UQY5dze92Ntvm_yzurhNfMivUWt4sOkmdVFpGcJTPC8heNib10eUuH.LwVq_TE6ihyQjtvT6T zIiYwtIRQA93Qgd0KPC8qeI8.edkt4mYPP2TQNB8PaVGjteueXYbcWFIyfCq_71uuz2SI7Jy1P8l fQV_X.gGtjjhkkihiJZxvlke2xsrhwW2OvM2VWJeHgjyVJNX_Dv55WVjFMCvf9l8uVgNe3l2M44Q z5_T6mQN1iVS9Zg-- Received: by 76.13.27.196; Thu, 05 Feb 2015 20:54:21 +0000 Date: Thu, 5 Feb 2015 20:54:21 +0000 (UTC) From: Bill Mills To: John Bradley Message-ID: <179064624.461521.1423169661115.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_461520_1231378395.1423169661105" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 20:54:25 -0000 ------=_Part_461520_1231378395.1423169661105 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah, BNF builtin parser error, that's 42*128. =C2=A0I had parsed that as 128= unreserved as the name.=20 On Thursday, February 5, 2015 12:47 PM, John Bradley wrote: =20 We are discussing the minimum size, =C2=A0the max is currently 128 charact= ers. On Feb 5, 2015, at 5:11 PM, Bill Mills wrote: Is there a compelling reason to make that length fixed? =C2=A0 =20 On Thursday, February 5, 2015 10:10 AM, Brian Campbell wrote: =20 22-chars (128 bits) as a lower limit seems just fine for this case. "ccm" works for me but I don't feel strongly about it either way. On Thu, Feb 5, 2015 at 9:49 AM, John Bradley wrote: Inline > On Feb 4, 2015, at 10:43 PM, Manger, James wrote: > >>=C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Proof Key f= or Code Exchange by OAuth Public Clients >>=C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-oau= th-spop-09.txt >> https://tools.ietf.org/html/draft-ietf-oauth-spop-09 > > > Some nits on this draft: > > 1. 42 chars. > The lower limit of 42 chars for code_verifier: is not mentioned in prose = (just the upper limit); is too high (128-bits=3D22-chars is sufficient); an= d doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 chars= , not 42). In my editors draft I fixed the 43 octet base64url encoding of 32bytes.=C2= =A0 I originally had 43 but it got changed at some point Is there working group feedback on making the lower limit clear in the pros= e and if so what should it be?=C2=A0 22-chars (128 bits) or 43 char (256 bi= ts)? > > 2. > Quotes around "code_verifier" and "code_challenge" in prose are okay, tho= ugh not really necessary as the underscore is enough to distinguish them as= technical labels. Quotes around these terms in formula is bad as it looks = like the formula applies to the 13 or 14 chars of the label. The quoting is= also used inconsistently. > Suggestion: remove all quotes around "code_verifier" and "code_challenge"= in prose and formula. > For example, change ASCII("code_verifier") to ASCII(code_verifier). > I am going to leave this for a later formatting cleanup at the moment, I ne= ed to find a good style compromise that works with rfcmarkup. > 3. > Two ways to check code_verifier are given in appendix B, whereas only one= of these is mentioned in section 4.6. >=C2=A0 SHA256(verifier) =3D=3D=3D B64-DECODE(challenge) >=C2=A0 B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge > > I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop th= e 1st from appendix B). It is simpler to mention only one. It also means ba= se64url-decoding is never done, and doesn't need to be mentioned in the spe= c. > Yes when I added the example I realized that the normative text was the mor= e complicated way to do the comparison. I will go back and refactor the main text to talk about the simpler compari= son and drop the base64url-decode references. > > 4. > Expand "MTI" to "mandatory to implement". Done in editors draft. > > P.S. Suggesting code challenge method names not exceed 8 chars to be comp= act is a bit perverse given the field holding these values has the long nam= e "code_challenge_method" ;) =C2=A0 On the topic of the parameter=C2=A0 name=C2=A0 "code_challange_metho= d",=C2=A0 James has a point in that it is a bit long. We could shorten it to "ccm".=C2=A0 =C2=A0If we want to change the name soo= ner is better than later. It is that balance between compactness and clear parameter names for develo= pers, that we keep running into. I don't know that encouraging longer parameter values is the best direction= . Feedback please John B. > > -- > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_461520_1231378395.1423169661105 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, BNF builtin parser error, that's 4= 2*128.  I had parsed that as 128unreserved as the name.
<= div class=3D"qtdSeparateBR">

On Thursday, February 5, 2015 12:47 PM, John Bradley <v= e7jtb@ve7jtb.com> wrote:


We are discussing the minimum s= ize,  the max is currently 128 characters.

=
On Feb 5, 2015, at 5:11= PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Is there a compelling reason to make that length fixed?  

=

On Thursday, February 5, 2015 10:10 AM, Brian Campbell = <bcampbell@pingidentity.com> wrote:


22-chars (128 bits) as a lower limit seems just f= ine for this case.

"ccm" works for me but I don't feel stro= ngly about it either way.



On Thu, Feb 5, 201= 5 at 9:49 AM, John Bradley <ve7j= tb@ve7jtb.com> wrote:
Inline


> On Feb 4, 2015, at 10:43 PM, Manger, James <James.H.Manger@team.telstra.com> wrote:
>
>>    Title           : Proof= Key for Code Exchange by OAuth Public Clients
>>      Filename        : draft-ie= tf-oauth-spop-09.txt
>> h= ttps://tools.ietf.org/html/draft-ietf-oauth-spop-09
>
>
> Some nits on this draft:
>
> 1. 42 chars.
> The lower limit of 42 chars for code_verifier: is not mentioned in pro= se (just the upper limit); is too high (128-bits=3D22-chars is sufficient);= and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 ch= ars, not 42).

In my editors draft I fixed the 43 octet base64url encoding of 32byt= es.  I originally had 43 but it got changed at some point

Is there working group feedback on making the lower limit clear in the pros= e and if so what should it be?  22-chars (128 bits) or 43 char (256 bi= ts)?


>
> 2.
> Quotes around "code_verifier" and "code_challenge" in prose are okay, = though not really necessary as the underscore is enough to distinguish them= as technical labels. Quotes around these terms in formula is bad as it loo= ks like the formula applies to the 13 or 14 chars of the label. The quoting= is also used inconsistently.
> Suggestion: remove all quotes around "code_verifier" and "code_challen= ge" in prose and formula.
> For example, change ASCII("code_verifier") to ASCII(code_verifier). >

I am going to leave this for a later formatting cleanup at the momen= t, I need to find a good style compromise that works with rfcmarkup.

> 3.
> Two ways to check code_verifier are given in appendix B, whereas only = one of these is mentioned in section 4.6.
>  SHA256(verifier) =3D=3D=3D B64-DECODE(challenge)
>  B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge
>
> I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop= the 1st from appendix B). It is simpler to mention only one. It also means= base64url-decoding is never done, and doesn't need to be mentioned in the = spec.
>
Yes when I added the example I realized that the normative text was = the more complicated way to do the comparison.

I will go back and refactor the main text to talk about the simpler compari= son and drop the base64url-decode references.
>
> 4.
> Expand "MTI" to "mandatory to implement".

Done in editors draft.
>
> P.S. Suggesting code challenge method names not exceed 8 chars to be c= ompact is a bit perverse given the field holding these values has the long = name "code_challenge_method" ;)

  On the topic of the parameter  name  "code_challang= e_method",  James has a point in that it is a bit long.

We could shorten it to "ccm".   If we want to change the name soo= ner is better than later.

It is that balance between compactness and clear parameter names for develo= pers, that we keep running into.

I don't know that encouraging longer parameter values is the best direction= .

Feedback please

John B.
>
> --
> James Manger
>
> _______________________________________________
> OAuth mailing list
> OAu= th@ietf.org
> https://www.iet= f.org/mailman/listinfo/oauth


____________________= ___________________________
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org= /mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv7116967267" target=3D"_blank"= href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/= mailman/listinfo/oauth
=



<= br>
------=_Part_461520_1231378395.1423169661105-- From nobody Thu Feb 5 12:58:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204981A7007 for ; Thu, 5 Feb 2015 12:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUz_bhlQ2g-h for ; Thu, 5 Feb 2015 12:57:59 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59FF1A8791 for ; Thu, 5 Feb 2015 12:57:56 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id p6so8519163qcv.1 for ; Thu, 05 Feb 2015 12:57:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1QYk2L1QryUSAPkVKukJZSEo+0FVKkBGKTde/ygiK4k=; b=DozUevWgWUp66F0sbi0kj8UMQpY6p71LwbNGANqZc0QIOT7t8q1jvIbKwTz5kjXrIn 7qQVCpEn36qvykyQcywQlvlVZ45Rm6NsWYN+NlIHjoQFyXKrQzKCtSlNAbUXhJP29YV0 peiSYC7QyPPBBpv4yVSfx9qU3bgk6gYzA9AcaCw4PDcDd3lsqtL4XYy2Ja/jgpLWL8RD G60fW/TCRhwLOLq0HzieDS7KRqEIKNGTQ6eYy0/Hn7U6U3ROKaMJH2TJK+G05qmZrSx2 yYeciWe2ELlHKgRkWAM+/ftqb9rkHWT87ZHPE0VZh2e+7h6Pdz2GMFzb7Ts0fCJjoz8t Y7sg== X-Gm-Message-State: ALoCoQmbrHf+IR7n9UyKP/dFLojP46Pda+4wqoBkcs7KN6uc3QH4+/kOKOzYGOmX9nQoIfeBJ431 X-Received: by 10.140.32.166 with SMTP id h35mr135069qgh.31.1423169875733; Thu, 05 Feb 2015 12:57:55 -0800 (PST) Received: from [192.168.8.100] ([181.202.19.170]) by mx.google.com with ESMTPSA id k3sm362343qao.0.2015.02.05.12.57.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 12:57:55 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_DE9BC09D-8FAA-4280-B8A7-93A1F8AD7459"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <179064624.461521.1423169661115.JavaMail.yahoo@mail.yahoo.com> Date: Thu, 5 Feb 2015 17:57:50 -0300 Message-Id: <6E833DEA-546B-458A-871A-7246D908641B@ve7jtb.com> References: <179064624.461521.1423169661115.JavaMail.yahoo@mail.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 20:58:03 -0000 --Apple-Mail=_DE9BC09D-8FAA-4280-B8A7-93A1F8AD7459 Content-Type: multipart/alternative; boundary="Apple-Mail=_BA9E24E1-9B6B-443F-A0E3-893B1F43EAEA" --Apple-Mail=_BA9E24E1-9B6B-443F-A0E3-893B1F43EAEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes the current draft has 43 to 128 characters unreserved = 43*128unreserved =20 You can blame me for a lot of things but ABNF is not one of them:) John B. > On Feb 5, 2015, at 5:54 PM, Bill Mills wrote: >=20 > Ah, BNF builtin parser error, that's 42*128. I had parsed that as = 128unreserved as the name. >=20 >=20 > On Thursday, February 5, 2015 12:47 PM, John Bradley = wrote: >=20 >=20 > We are discussing the minimum size, the max is currently 128 = characters. >=20 >=20 >> On Feb 5, 2015, at 5:11 PM, Bill Mills > wrote: >>=20 >> Is there a compelling reason to make that length fixed? =20 >>=20 >>=20 >>=20 >> On Thursday, February 5, 2015 10:10 AM, Brian Campbell = > wrote: >>=20 >>=20 >> 22-chars (128 bits) as a lower limit seems just fine for this case. >>=20 >> "ccm" works for me but I don't feel strongly about it either way. >>=20 >>=20 >>=20 >> On Thu, Feb 5, 2015 at 9:49 AM, John Bradley > wrote: >> Inline >>=20 >>=20 >> > On Feb 4, 2015, at 10:43 PM, Manger, James = > wrote: >> > >> >> Title : Proof Key for Code Exchange by OAuth Public = Clients >> >> Filename : draft-ietf-oauth-spop-09.txt >> >> https://tools.ietf.org/html/draft-ietf-oauth-spop-09 = >> > >> > >> > Some nits on this draft: >> > >> > 1. 42 chars. >> > The lower limit of 42 chars for code_verifier: is not mentioned in = prose (just the upper limit); is too high (128-bits=3D22-chars is = sufficient); and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 = bytes) gives 43 chars, not 42). >>=20 >> In my editors draft I fixed the 43 octet base64url encoding of = 32bytes. I originally had 43 but it got changed at some point >>=20 >> Is there working group feedback on making the lower limit clear in = the prose and if so what should it be? 22-chars (128 bits) or 43 char = (256 bits)? >>=20 >>=20 >> > >> > 2. >> > Quotes around "code_verifier" and "code_challenge" in prose are = okay, though not really necessary as the underscore is enough to = distinguish them as technical labels. Quotes around these terms in = formula is bad as it looks like the formula applies to the 13 or 14 = chars of the label. The quoting is also used inconsistently. >> > Suggestion: remove all quotes around "code_verifier" and = "code_challenge" in prose and formula. >> > For example, change ASCII("code_verifier") to ASCII(code_verifier). >> > >>=20 >> I am going to leave this for a later formatting cleanup at the = moment, I need to find a good style compromise that works with = rfcmarkup. >>=20 >> > 3. >> > Two ways to check code_verifier are given in appendix B, whereas = only one of these is mentioned in section 4.6. >> > SHA256(verifier) =3D=3D=3D B64-DECODE(challenge) >> > B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge >> > >> > I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and = drop the 1st from appendix B). It is simpler to mention only one. It = also means base64url-decoding is never done, and doesn't need to be = mentioned in the spec. >> > >> Yes when I added the example I realized that the normative text was = the more complicated way to do the comparison. >>=20 >> I will go back and refactor the main text to talk about the simpler = comparison and drop the base64url-decode references. >> > >> > 4. >> > Expand "MTI" to "mandatory to implement". >>=20 >> Done in editors draft. >> > >> > P.S. Suggesting code challenge method names not exceed 8 chars to = be compact is a bit perverse given the field holding these values has = the long name "code_challenge_method" ;) >>=20 >> On the topic of the parameter name "code_challange_method", = James has a point in that it is a bit long. >>=20 >> We could shorten it to "ccm". If we want to change the name sooner = is better than later. >>=20 >> It is that balance between compactness and clear parameter names for = developers, that we keep running into. >>=20 >> I don't know that encouraging longer parameter values is the best = direction. >>=20 >> Feedback please >>=20 >> John B. >> > >> > -- >> > James Manger >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_BA9E24E1-9B6B-443F-A0E3-893B1F43EAEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes the current draft has 43 to 128 characters unreserved =  43*128unreserved  

You can blame me for a lot of things but ABNF is not one of = them:)

John = B.


On = Feb 5, 2015, at 5:54 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Ah, BNF builtin parser error, that's 42*128.  I had = parsed that as 128unreserved as the name.


On Thursday, = February 5, 2015 12:47 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:


=
We are discussing the minimum size,  the max is = currently 128 characters.


On = Feb 5, 2015, at 5:11 PM, Bill Mills <wmills_92105@yahoo.com> = wrote:

Is there a compelling reason = to make that length fixed?  



On = Thursday, February 5, 2015 10:10 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:
=

22-chars (128 bits) as a lower limit seems just = fine for this case.

"ccm" works for me but I = don't feel strongly about it either way.



On = Thu, Feb 5, 2015 at 9:49 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
Inline


> On Feb 4, 2015, at 10:43 PM, Manger, James <James.H.Manger@team.telstr= a.com> wrote:
>
>>    Title           : = Proof Key for Code Exchange by OAuth Public Clients
>>      Filename        : = draft-ietf-oauth-spop-09.txt
>> https://tool= s.ietf.org/html/draft-ietf-oauth-spop-09
>
>
> Some nits on this draft:
>
> 1. 42 chars.
> The lower limit of 42 chars for code_verifier: is not mentioned in = prose (just the upper limit); is too high (128-bits=3D22-chars is = sufficient); and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 = bytes) gives 43 chars, not 42).
=
In my editors draft I fixed the 43 octet base64url encoding of = 32bytes.  I originally had 43 but it got changed at some point

Is there working group feedback on making the lower limit clear in the = prose and if so what should it be?  22-chars (128 bits) or 43 char = (256 bits)?


>
> 2.
> Quotes around "code_verifier" and "code_challenge" in prose are = okay, though not really necessary as the underscore is enough to = distinguish them as technical labels. Quotes around these terms in = formula is bad as it looks like the formula applies to the 13 or 14 = chars of the label. The quoting is also used inconsistently.
> Suggestion: remove all quotes around "code_verifier" and = "code_challenge" in prose and formula.
> For example, change ASCII("code_verifier") to = ASCII(code_verifier).
>

I am going to leave this for a later formatting cleanup at the = moment, I need to find a good style compromise that works with = rfcmarkup.

> 3.
> Two ways to check code_verifier are given in appendix B, whereas = only one of these is mentioned in section 4.6.
>  SHA256(verifier) =3D=3D=3D B64-DECODE(challenge)
>  B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge
>
> I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and = drop the 1st from appendix B). It is simpler to mention only one. It = also means base64url-decoding is never done, and doesn't need to be = mentioned in the spec.
>
Yes when I added the example I realized that the normative text = was the more complicated way to do the comparison.

I will go back and refactor the main text to talk about the simpler = comparison and drop the base64url-decode references.
>
> 4.
> Expand "MTI" to "mandatory to implement".

Done in editors draft.
>
> P.S. Suggesting code challenge method names not exceed 8 chars to = be compact is a bit perverse given the field holding these values has = the long name "code_challenge_method" ;)

  On the topic of the parameter  name  = "code_challange_method",  James has a point in that it is a bit = long.

We could shorten it to "ccm".   If we want to change the name = sooner is better than later.

It is that balance between compactness and clear parameter names for = developers, that we keep running into.

I don't know that encouraging longer parameter values is the best = direction.

Feedback please

John B.
>
> --
> James Manger
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/= mailman/listinfo/oauth


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



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


=



=

= --Apple-Mail=_BA9E24E1-9B6B-443F-A0E3-893B1F43EAEA-- --Apple-Mail=_DE9BC09D-8FAA-4280-B8A7-93A1F8AD7459 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAyMDUyMDU3NTBaMCMGCSqGSIb3DQEJBDEWBBQ4Ow6J2ieqo2XO2Vr0OILf 1BJuXTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCT6/kWuXOxYxdQn7gpD5FhzTyvFvfzS3kBPNn9HQVKYAJ8akElRUCR Zl/JpSRPufsGmn2mchHR/L+rVwxzSR6CPxvnioQa+bfA97dsz5RxWdeUK7lumOiuElv7iFAlnKzz CR2Zx58gXJWgYz6eCO7rE/ZH2WXqJbd4nv1G7K/eCS48v++OMk9H6+5eyRXyFsm1FatahBARtlEW qVEOeZ7LJ29doNOqOSiAj2rwBtVeUJORQjRFmSSP/qkypXlh4saZmOas2gFCBEEcLQ5EarFesQcJ WOA+bTsVa+GDH5uhaIOA1qiNJDOSi3b8LoJN351yb0+lUmHtOiD3t2mUHSwlAAAAAAAA --Apple-Mail=_DE9BC09D-8FAA-4280-B8A7-93A1F8AD7459-- From nobody Thu Feb 5 15:24:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3F71A0397; Thu, 5 Feb 2015 15:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duul40r3uS81; Thu, 5 Feb 2015 15:24:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EF21A1F73; Thu, 5 Feb 2015 15:24:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205232401.25501.77172.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 15:24:01 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 23:24:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Authors : Nat Sakimura John Bradley Naveen Agarwal Filename : draft-ietf-oauth-spop-10.txt Pages : 18 Date : 2015-02-05 Abstract: OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-spop-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 5 16:00:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A071A700B for ; Thu, 5 Feb 2015 16:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3jVFldS_S00 for ; Thu, 5 Feb 2015 16:00:33 -0800 (PST) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CD31A7011 for ; Thu, 5 Feb 2015 16:00:32 -0800 (PST) Received: from mail-ig0-f181.google.com ([209.85.213.181]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKVNQEH6K/vu/eiyvDT2OGg9L+fhC1j9/y@postini.com; Thu, 05 Feb 2015 16:00:32 PST Received: by mail-ig0-f181.google.com with SMTP id hn18so3173280igb.2 for ; Thu, 05 Feb 2015 16:00:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=APtMK150id7LmSeZ5XsS3D9+jl1IjrDZTHc5lIVvUDQ=; b=JsbSNTHag0SK9MF7S/L2gcIqaXxMmFcZMDY4e6ZZDccJbpy+mvmpm/4L5m2t+M3lpB 9CQSnQXNLgyfHxUkfZmUL5LqZHpNtNTLm/k0cufQWkctj/JOV4vYG+XRlpCRZ/0+K7PG nOiUsTkFM4P9Y2Yjql6UCLZYAnwKw+lNjQj6J5rEcPm+a50IAe2Xyeo4g974RF/eSUwQ twLG7XtlA4ZLU8Y/uo9xw/uHiWNQxKcAhEouUrl+7UTswG7YwT1SpvAYv+ReIkSPwJFJ PXAJTNiErfiO/On9/DHUkjVLeflZOic/aCklQC05YJCJ5DjtpNP/oiNhUotK+ydnIcEz 4WwQ== X-Gm-Message-State: ALoCoQnDCetaxrOADBA0ItmXuUfq+yA9dhHoFf3j5VQi/fdxCyxDtYkDW1BGuysN44Jy2FQVoNO266Gnic352YtkcBSKlnWRHt3N9xuQ3xsdBVHoqPg+tvtpl9Yi9XAW4wWIzRzl8owS X-Received: by 10.107.156.85 with SMTP id f82mr7924909ioe.45.1423180831351; Thu, 05 Feb 2015 16:00:31 -0800 (PST) X-Received: by 10.107.156.85 with SMTP id f82mr7924894ioe.45.1423180831210; Thu, 05 Feb 2015 16:00:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Thu, 5 Feb 2015 16:00:01 -0800 (PST) In-Reply-To: References: <20150204234040.19482.87437.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E12851EBA8C3@WSMSG3153V.srv.dir.telstra.com> <97C03A16-4299-44A5-B121-58C6542DF6C1@ve7jtb.com> From: Brian Campbell Date: Thu, 5 Feb 2015 17:00:01 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a1141c3f4e561a9050e601b3d Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 00:00:37 -0000 --001a1141c3f4e561a9050e601b3d Content-Type: text/plain; charset=UTF-8 To clarify what I said there: 22-chars (128 bits) seems like way more than enough for a lower limit when using the "plain" challenge method. When using the "S256" challenge method, exactly 43 char (256 bits) should probably always be used. On Thu, Feb 5, 2015 at 11:09 AM, Brian Campbell wrote: > 22-chars (128 bits) as a lower limit seems just fine for this case. > > "ccm" works for me but I don't feel strongly about it either way. > > > > On Thu, Feb 5, 2015 at 9:49 AM, John Bradley wrote: > >> Inline >> >> >> > On Feb 4, 2015, at 10:43 PM, Manger, James < >> James.H.Manger@team.telstra.com> wrote: >> > >> >> Title : Proof Key for Code Exchange by OAuth Public >> Clients >> >> Filename : draft-ietf-oauth-spop-09.txt >> >> https://tools.ietf.org/html/draft-ietf-oauth-spop-09 >> > >> > >> > Some nits on this draft: >> > >> > 1. 42 chars. >> > The lower limit of 42 chars for code_verifier: is not mentioned in >> prose (just the upper limit); is too high (128-bits=22-chars is >> sufficient); and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) >> gives 43 chars, not 42). >> >> In my editors draft I fixed the 43 octet base64url encoding of 32bytes. >> I originally had 43 but it got changed at some point >> >> Is there working group feedback on making the lower limit clear in the >> prose and if so what should it be? 22-chars (128 bits) or 43 char (256 >> bits)? >> >> >> > >> > 2. >> > Quotes around "code_verifier" and "code_challenge" in prose are okay, >> though not really necessary as the underscore is enough to distinguish them >> as technical labels. Quotes around these terms in formula is bad as it >> looks like the formula applies to the 13 or 14 chars of the label. The >> quoting is also used inconsistently. >> > Suggestion: remove all quotes around "code_verifier" and >> "code_challenge" in prose and formula. >> > For example, change ASCII("code_verifier") to ASCII(code_verifier). >> > >> >> I am going to leave this for a later formatting cleanup at the moment, I >> need to find a good style compromise that works with rfcmarkup. >> >> > 3. >> > Two ways to check code_verifier are given in appendix B, whereas only >> one of these is mentioned in section 4.6. >> > SHA256(verifier) === B64-DECODE(challenge) >> > B64-ENCODE(SHA256(verifier)) === challenge >> > >> > I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop >> the 1st from appendix B). It is simpler to mention only one. It also means >> base64url-decoding is never done, and doesn't need to be mentioned in the >> spec. >> > >> Yes when I added the example I realized that the normative text was the >> more complicated way to do the comparison. >> >> I will go back and refactor the main text to talk about the simpler >> comparison and drop the base64url-decode references. >> > >> > 4. >> > Expand "MTI" to "mandatory to implement". >> >> Done in editors draft. >> > >> > P.S. Suggesting code challenge method names not exceed 8 chars to be >> compact is a bit perverse given the field holding these values has the long >> name "code_challenge_method" ;) >> >> On the topic of the parameter name "code_challange_method", James >> has a point in that it is a bit long. >> >> We could shorten it to "ccm". If we want to change the name sooner is >> better than later. >> >> It is that balance between compactness and clear parameter names for >> developers, that we keep running into. >> >> I don't know that encouraging longer parameter values is the best >> direction. >> >> Feedback please >> >> John B. >> > >> > -- >> > James Manger >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --001a1141c3f4e561a9050e601b3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To clarify what I said there: 22-chars (128 bits) seems li= ke way more than enough for a lower limit when using the "plain" = challenge method. When using the "S256" challenge method, exactly= 43 char (256 bits) should probably always be used. =C2=A0

On Thu, Feb 5, 2015 at 11:0= 9 AM, Brian Campbell <bcampbell@pingidentity.com> w= rote:
22-chars (128= bits) as a lower limit seems just fine for this case.

"c= cm" works for me but I don't feel strongly about it either way.


On Thu, Feb 5, 2015 at 9:49 AM, John = Bradley <ve7jtb@ve7jtb.com> wrote:
Inline


> On Feb 4, 2015, at 10:43 PM, Manger, James <James.H.Manger@team.telstra.c= om> wrote:
>
>>=C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Proof= Key for Code Exchange by OAuth Public Clients
>>=C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ie= tf-oauth-spop-09.txt
>> https://tools.ietf.org/html/draft-ietf-oauth-spop-09 >
>
> Some nits on this draft:
>
> 1. 42 chars.
> The lower limit of 42 chars for code_verifier: is not mentioned in pro= se (just the upper limit); is too high (128-bits=3D22-chars is sufficient);= and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 4= 3 chars, not 42).

In my editors draft I fixed the 43 octet base64url encoding of 32byt= es.=C2=A0 I originally had 43 but it got changed at some point

Is there working group feedback on making the lower limit clear in the pros= e and if so what should it be?=C2=A0 22-chars (128 bits) or 43 char (256 bi= ts)?


>
> 2.
> Quotes around "code_verifier" and "code_challenge"= in prose are okay, though not really necessary as the underscore is enough= to distinguish them as technical labels. Quotes around these terms in form= ula is bad as it looks like the formula applies to the 13 or 14 chars of th= e label. The quoting is also used inconsistently.
> Suggestion: remove all quotes around "code_verifier" and &qu= ot;code_challenge" in prose and formula.
> For example, change ASCII("code_verifier") to ASCII(code_ver= ifier).
>

I am going to leave this for a later formatting cleanup at the momen= t, I need to find a good style compromise that works with rfcmarkup.

> 3.
> Two ways to check code_verifier are given in appendix B, whereas only = one of these is mentioned in section 4.6.
>=C2=A0 SHA256(verifier) =3D=3D=3D B64-DECODE(challenge)
>=C2=A0 B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge
>
> I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop= the 1st from appendix B). It is simpler to mention only one. It also means= base64url-decoding is never done, and doesn't need to be mentioned in = the spec.
>
Yes when I added the example I realized that the normative text was = the more complicated way to do the comparison.

I will go back and refactor the main text to talk about the simpler compari= son and drop the base64url-decode references.
>
> 4.
> Expand "MTI" to "mandatory to implement".

Done in editors draft.
>
> P.S. Suggesting code challenge method names not exceed 8 chars to be c= ompact is a bit perverse given the field holding these values has the long = name "code_challenge_method" ;)

=C2=A0 On the topic of the parameter=C2=A0 name=C2=A0 "code_cha= llange_method",=C2=A0 James has a point in that it is a bit long.

We could shorten it to "ccm".=C2=A0 =C2=A0If we want to change th= e name sooner is better than later.

It is that balance between compactness and clear parameter names for develo= pers, that we keep running into.

I don't know that encouraging longer parameter values is the best direc= tion.

Feedback please

John B.
>
> --
> James Manger
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth


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



--001a1141c3f4e561a9050e601b3d-- From nobody Fri Feb 6 13:27:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB731A6EFE for ; Fri, 6 Feb 2015 13:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0xz1GQjrHWP for ; Fri, 6 Feb 2015 13:27:40 -0800 (PST) Received: from mx0a-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9F51A0155 for ; Fri, 6 Feb 2015 13:27:39 -0800 (PST) Received: from pps.filterd (m0074408.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.14.7/8.14.7) with SMTP id t16LPIvC025538 for ; Fri, 6 Feb 2015 15:27:38 -0600 Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by mx0a-0019e102.pphosted.com with ESMTP id 1sd48rg2xq-1 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Fri, 06 Feb 2015 15:27:38 -0600 Received: from BLUPR04MB691.namprd04.prod.outlook.com (10.141.205.149) by BLUPR04MB691.namprd04.prod.outlook.com (10.141.205.149) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 6 Feb 2015 21:27:36 +0000 Received: from BLUPR04MB691.namprd04.prod.outlook.com ([10.141.205.149]) by BLUPR04MB691.namprd04.prod.outlook.com ([10.141.205.149]) with mapi id 15.01.0075.002; Fri, 6 Feb 2015 21:27:36 +0000 From: Adam Lewis To: OAuth WG Thread-Topic: Confusion on Implicit Grant flow Thread-Index: AdBCU7lczcAZFshKSMOM30KEynNz8A== Date: Fri, 6 Feb 2015 21:27:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.149.88.198] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR04MB691; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR04MB691; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(15975445007)(62966003)(450100001)(102836002)(40100003)(2900100001)(77096005)(74316001)(122556002)(16236675004)(76576001)(54356999)(229853001)(110136001)(77156002)(18717965001)(46102003)(33656002)(19625215002)(19609705001)(107886001)(66066001)(86362001)(19580395003)(99286002)(2656002)(50986999)(87936001)(92566002)(19300405004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR04MB691; H:BLUPR04MB691.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BLUPR04MB6918C7701D0DB90B0FA6B0D95380BLUPR04MB691namprd_" MIME-Version: 1.0 X-OriginatorOrg: motorolasolutions.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2015 21:27:36.0440 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 93f5baf9-414a-4f1b-88bc-33f3013923d7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR04MB691 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=7.97038224309432e-08 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.99939988688917 urlsuspect_oldscore=0.99939988688917 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.99939988688917 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1502060218 Archived-At: Subject: [OAUTH-WG] Confusion on Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 21:27:42 -0000 --_000_BLUPR04MB6918C7701D0DB90B0FA6B0D95380BLUPR04MB691namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Having spent most of my time with native apps and web apps, I now am lookin= g at use cases where I need to implement a user-agent-based app. The Impli= cit flow seems to be optimized for this. To test my understanding, this flow is for a JavaScript client (or similar)= executing within a web browser. At step (a) the client directs the UA to the authorization server, but the = authorization server redirects the UA to a web-hosted client resource. Why= ? It says so that the web-hosted client resources can push javascript (or = other) back into the UA so it can extract the access token in the fragment;= but some sort of javascript is already running in the browser, since it in= itiated the authorization request in the first place. So why this extra st= ep? Why not treat the javascript client running in the UA like a native ap= p and handle the redirect uri? I know this was well thought out when the spec was written, so trying to fi= gure out what I'm missing? Tx! adam --_000_BLUPR04MB6918C7701D0DB90B0FA6B0D95380BLUPR04MB691namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Having spent most of my time with native apps and we= b apps, I now am looking at use cases where I need to implement a user-agen= t-based app.  The Implicit flow seems to be optimized for this.

 

To test my understanding, this flow is for a JavaScr= ipt client (or similar) executing within a web browser.

 

At step (a) the client directs the UA to the authori= zation server, but the authorization server redirects the UA to a web-hoste= d client resource.  Why?  It says so that the web-hosted client r= esources can push javascript (or other) back into the UA so it can extract the access token in the fragment; but some s= ort of javascript is already running in the browser, since it initiated the= authorization request in the first place.  So why this extra step?&nb= sp; Why not treat the javascript client running in the UA like a native app and handle the redirect uri?

 

I know this was well thought out when the spec was w= ritten, so trying to figure out what I’m missing?

 

 

 

Tx!
adam

--_000_BLUPR04MB6918C7701D0DB90B0FA6B0D95380BLUPR04MB691namprd_-- From nobody Fri Feb 6 13:37:54 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533711A8870 for ; Fri, 6 Feb 2015 13:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTB9oBDbNJjl for ; Fri, 6 Feb 2015 13:37:46 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945801A879B for ; Fri, 6 Feb 2015 13:37:45 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id r5so14124382qcx.11 for ; Fri, 06 Feb 2015 13:37:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=WszxFu+ehtKw0ARLro4rLWoQA7eocgpf2+f97f86dL0=; b=Jbx02eQ1WJp8Up5JLqhta+NeXbF2RefTCIbQ0pwUuO4Zy/2hIRvBKus8pi+MWnVY2S rejI3hymNdZv7ToXY/Z3941iZyAJmtz6S2HRn1scHUcAkaaZGXcKBB6BFSJYNs6wdUlV 9UjCtQmDZWZvTc3rxjw5611Euv+VIAl2agIlRISGnVvYj+WDKMbX6qalNRbNG5L/igwk ASnrtBzE1VymD6u3E+SUpGJSfKVwUSRfUaZdyCb+SGfU6GxCEtkF5dpdGU1d7yI9j1q1 voRSlXSBCQizgiqJY7tk+wdpuBkq3Ml1a44XJwgxUwktMifv6gXw7T9c3NJ8zGkhngqG 64/w== X-Gm-Message-State: ALoCoQmIfFjk/FOwJ8BDTYOgUEoXibNbTU8rpgrtFTbmY7TofOppawyRjSktYZ6PxJqxPfrH6aZM X-Received: by 10.224.161.138 with SMTP id r10mr12766284qax.21.1423258664646; Fri, 06 Feb 2015 13:37:44 -0800 (PST) Received: from [192.168.1.35] (186-79-116-126.baf.movistar.cl. [186.79.116.126]) by mx.google.com with ESMTPSA id i19sm3792023qaq.19.2015.02.06.13.37.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Feb 2015 13:37:43 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_76147FA7-95A8-4606-A6D6-76859844C8CE"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Fri, 6 Feb 2015 18:37:39 -0300 Message-Id: <5E181E6C-C66B-47AE-BAE6-361C3D4D08C2@ve7jtb.com> References: To: Adam Lewis X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 21:37:48 -0000 --Apple-Mail=_76147FA7-95A8-4606-A6D6-76859844C8CE Content-Type: multipart/alternative; boundary="Apple-Mail=_F3FD2FB7-B008-48E5-89C8-3055E86AF1F7" --Apple-Mail=_F3FD2FB7-B008-48E5-89C8-3055E86AF1F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It isn=E2=80=99t an extra step, the call back via 302 has to be to a = URI in the location header. The JS loaded by that URI may already be = cached in the browser as part of the APP. The cached JS typically extracts the token and uses it. The token is = never passed to the server where the JS is loaded from. (yes it could = be, but if your are doing that then use code or hybrid code+token) Ther are other ways that could be done using pure Java Script cross = origin messaging eg post-message. However though some people (Google = and others) do use that in there custom integrations, a standard for = that has not been established. (there are some real security issues around post message that need to be = considered first) John B. > On Feb 6, 2015, at 6:27 PM, Adam Lewis = wrote: >=20 > Hi, > =20 > Having spent most of my time with native apps and web apps, I now am = looking at use cases where I need to implement a user-agent-based app. = The Implicit flow seems to be optimized for this. > =20 > To test my understanding, this flow is for a JavaScript client (or = similar) executing within a web browser. > =20 > At step (a) the client directs the UA to the authorization server, but = the authorization server redirects the UA to a web-hosted client = resource. Why? It says so that the web-hosted client resources can = push javascript (or other) back into the UA so it can extract the access = token in the fragment; but some sort of javascript is already running in = the browser, since it initiated the authorization request in the first = place. So why this extra step? Why not treat the javascript client = running in the UA like a native app and handle the redirect uri? > =20 > I know this was well thought out when the spec was written, so trying = to figure out what I=E2=80=99m missing? > =20 > =20 > =20 > Tx! > adam > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_F3FD2FB7-B008-48E5-89C8-3055E86AF1F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It isn=E2=80=99t an extra step,  the call back via 302 = has to be to a URI in the location header.  The JS loaded by that = URI may already be cached in the browser as part of the APP.

The cached JS typically = extracts the token and uses it.  The token is never passed to the = server where the JS is loaded from. (yes it could be, but if your are = doing that then use code or hybrid code+token)

Ther are other ways that = could be done using pure Java Script cross origin messaging eg = post-message.   However though some people (Google and others) do = use that in there custom integrations, a standard for that has not been = established.
(there are some real security issues = around post message that need to be considered first)

John B.


On = Feb 6, 2015, at 6:27 PM, Adam Lewis <Adam.Lewis@motorolasolutions.com> wrote:

Hi,
 
Having = spent most of my time with native apps and web apps, I now am looking at = use cases where I need to implement a user-agent-based app.  The = Implicit flow seems to be optimized for this.
 
To test = my understanding, this flow is for a JavaScript client (or similar) = executing within a web browser.
 
At step (a) the client directs the UA = to the authorization server, but the authorization server redirects the = UA to a web-hosted client resource.  Why?  It says so that the = web-hosted client resources can push javascript (or other) back into the = UA so it can extract the access token in the fragment; but some sort of = javascript is already running in the browser, since it initiated the = authorization request in the first place.  So why this extra = step?  Why not treat the javascript client running in the UA like a = native app and handle the redirect uri?
 
I know this was well thought out when = the spec was written, so trying to figure out what I=E2=80=99m = missing?
 
 
 
Tx!
adam
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_F3FD2FB7-B008-48E5-89C8-3055E86AF1F7-- --Apple-Mail=_76147FA7-95A8-4606-A6D6-76859844C8CE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAyMDYyMTM3MzlaMCMGCSqGSIb3DQEJBDEWBBS+47kRvVxr8ZTNtZYy8+ej pFQ/azCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBxpHxLiVbJn12dmCQf9UNkqRIib0NX9IGST06XEAQoGmuNcwC4fex8 /2yotxGAz5thQLmNTTZXBQ4XtIRT6SXBIVMZy1Ip9fOA4gx3MbqLIKReJOdb8V6a8nYa28d1riSZ hx7JUbnE2QYK5frMprsF32QVf+qYOdZLZeE+xCywip4sRR/WXCkB9kT8ZhK3eipPJGFrtWDhwWUS ZRutZAYzZpC3Qja6/Ud7JVp317WZ7G+AFDlQMDwg+6ZTcMg1RYBT4NemFKDCTAo19RWrXpf6WJud Z0P6nMLBODYF2heNHIaNHxddGTeFEPb8OY2P39Nv/98tMDoVl42QV2BfaURpAAAAAAAA --Apple-Mail=_76147FA7-95A8-4606-A6D6-76859844C8CE-- From nobody Fri Feb 6 13:41:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366181A8898 for ; Fri, 6 Feb 2015 13:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rdr0eisxhTNv for ; Fri, 6 Feb 2015 13:41:30 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B347A1A888A for ; Fri, 6 Feb 2015 13:41:06 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id a141so14174139oig.5 for ; Fri, 06 Feb 2015 13:41:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=J4EzFZqA32+5NvqMLx+WChupfSnU5tsCiTdqsqiAY0M=; b=nLNc0kjboBf7mvWZztTNeOAC8pqmVeouGtRsoxt+ZUfatOF04DpGAR9EGAPsCpHv61 20vZKeJjflCiilgUrw1cjxvxFlEwWd9lYmkHJLpdbUojM+wBMSJlv9V3cu51yvXCbBbn D8hl4MJgL2ueMLb+OTi8elj06DYZ2d6TY04eIbooById8TO0PFm6A/Bv6oMYLkGp+2cy wKw0TJRyjeWSPk3+OujLQ1w6xg4CZbeaHhY+903cIec7BqkdFtytMXytmOSh9UGJfrhf KK93yLi9t7V9HCJZAxh5EsqzWdD/BjJzusjHUNLOXlZjBPxhbYUfsa7+miSuwhvkfYjG /dag== X-Received: by 10.60.52.202 with SMTP id v10mr3921994oeo.46.1423258865978; Fri, 06 Feb 2015 13:41:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.97.107 with HTTP; Fri, 6 Feb 2015 13:40:45 -0800 (PST) In-Reply-To: References: From: Josh Mandel Date: Fri, 6 Feb 2015 13:40:45 -0800 Message-ID: To: Adam Lewis Content-Type: multipart/alternative; boundary=001a11330cbe2150a9050e7247f5 Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 21:41:33 -0000 --001a11330cbe2150a9050e7247f5 Content-Type: text/plain; charset=ISO-8859-1 Hi Adam, I'm not 100% sure what you're envisioning as an alternative to the implicit flow, but if I'm reading between the lines of your question correctly, there are two key parts to the answer, because the implicit flow is designed to accomplish two key goals (vs. the authorization code grant): 1. Shave off one round-trip HTTP request (the step of exchanging a code for a token) 2. Avoid unnecessarily leading the token to the client's back-end web server Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes advantage of the fact that a URL's "#hash" is not sent to the server with an HTTP request. By embedding the token in a "#hash", it won't inadvertently appear in server logs, for example. So with the implicit flow, I can (for example) statically host a browser-based app at Amazon S3 without having access tokens leak to Amazon. (Of course, if your threat model includes a compromised server, then bets are off on this point.) Hope this helps, -Josh On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis wrote: > Hi, > > > > Having spent most of my time with native apps and web apps, I now am > looking at use cases where I need to implement a user-agent-based app. The > Implicit flow seems to be optimized for this. > > > > To test my understanding, this flow is for a JavaScript client (or > similar) executing within a web browser. > > > > At step (a) the client directs the UA to the authorization server, but the > authorization server redirects the UA to a web-hosted client resource. > Why? It says so that the web-hosted client resources can push javascript > (or other) back into the UA so it can extract the access token in the > fragment; but some sort of javascript is already running in the browser, > since it initiated the authorization request in the first place. So why > this extra step? Why not treat the javascript client running in the UA > like a native app and handle the redirect uri? > > > > I know this was well thought out when the spec was written, so trying to > figure out what I'm missing? > > > > > > > > Tx! > adam > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11330cbe2150a9050e7247f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Adam,

I'm not 100% sure what you= 're envisioning as an alternative to the implicit flow, but if I'm = reading between the lines of your question correctly, there are two key par= ts to the answer, because the implicit flow is designed to accomplish two k= ey goals (vs. the authorization code grant):

1. Sh= ave off one round-trip HTTP request (the step of exchanging a code for a to= ken)
2. Avoid unnecessarily leading the token to the client's= back-end web server

Goal 1 is straightforward. Fo= r goal 2: OAuth2's implicit flow takes advantage of the fact that a URL= 's "#hash" is not sent to the server with an HTTP request. By= embedding the token in a "#hash", it won't inadvertently app= ear in server logs, for example. So with the implicit flow, I can (for exam= ple) statically host a browser-based app at Amazon S3 without having access= tokens leak to Amazon. (Of course, if your threat model includes a comprom= ised server, then bets are off on this point.)

Hop= e this helps,

  -Josh



On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis <Adam.Lewis@m= otorolasolutions.com> wrote:

Hi,

 

Having spent most of my time with native apps and we= b apps, I now am looking at use cases where I need to implement a user-agen= t-based app.  The Implicit flow seems to be optimized for this.=

 

To test my understanding, this flow is for a JavaScr= ipt client (or similar) executing within a web browser.

 

At step (a) the client directs the UA to the authori= zation server, but the authorization server redirects the UA to a web-hoste= d client resource.  Why?  It says so that the web-hosted client r= esources can push javascript (or other) back into the UA so it can extract the access token in the fragment; but some s= ort of javascript is already running in the browser, since it initiated the= authorization request in the first place.  So why this extra step?&nb= sp; Why not treat the javascript client running in the UA like a native app and handle the redirect uri?

 

I know this was well thought out when the spec was w= ritten, so trying to figure out what I’m missing?

 

 

 

Tx! adam


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


--001a11330cbe2150a9050e7247f5-- From nobody Mon Feb 9 12:50:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C7F1A87C6 for ; Mon, 9 Feb 2015 12:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqvVesmSLeF7 for ; Mon, 9 Feb 2015 12:06:48 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB151A8842 for ; Mon, 9 Feb 2015 12:05:43 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t19K5hDI000554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 9 Feb 2015 15:05:43 -0500 Received: from [10.10.61.137] (vpn-61-137.rdu2.redhat.com [10.10.61.137]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t19K5gNw016724 for ; Mon, 9 Feb 2015 15:05:42 -0500 Message-ID: <54D91317.9010101@redhat.com> Date: Mon, 09 Feb 2015 15:05:43 -0500 From: Bill Burke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 20:06:50 -0000 Due to the security risks of implicit Grant flow, our Javascript adapter only supports Auth Code Grant flow. Our IDP has an extra step of allowing you to specify a valid CORS origin for an application. Anybody see any problems with this kind of approach? Implicit Grant Flow just seemed really risky to even support as a protocol. On 2/6/2015 4:40 PM, Josh Mandel wrote: > Hi Adam, > > I'm not 100% sure what you're envisioning as an alternative to the > implicit flow, but if I'm reading between the lines of your question > correctly, there are two key parts to the answer, because the implicit > flow is designed to accomplish two key goals (vs. the authorization code > grant): > > 1. Shave off one round-trip HTTP request (the step of exchanging a code > for a token) > 2. Avoid unnecessarily leading the token to the client's back-end web server > > Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes > advantage of the fact that a URL's "#hash" is not sent to the server > with an HTTP request. By embedding the token in a "#hash", it won't > inadvertently appear in server logs, for example. So with the implicit > flow, I can (for example) statically host a browser-based app at Amazon > S3 without having access tokens leak to Amazon. (Of course, if your > threat model includes a compromised server, then bets are off on this > point.) > > Hope this helps, > > -Josh > > > > On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis > > wrote: > > Hi,____ > > __ __ > > Having spent most of my time with native apps and web apps, I now am > looking at use cases where I need to implement a user-agent-based > app. The Implicit flow seems to be optimized for this.____ > > __ __ > > To test my understanding, this flow is for a JavaScript client (or > similar) executing within a web browser.____ > > __ __ > > At step (a) the client directs the UA to the authorization server, > but the authorization server redirects the UA to a web-hosted client > resource. Why? It says so that the web-hosted client resources can > push javascript (or other) back into the UA so it can extract the > access token in the fragment; but some sort of javascript is already > running in the browser, since it initiated the authorization request > in the first place. So why this extra step? Why not treat the > javascript client running in the UA like a native app and handle the > redirect uri?____ > > __ __ > > I know this was well thought out when the spec was written, so > trying to figure out what I’m missing?____ > > __ __ > > __ __ > > __ __ > > Tx! > adam____ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From nobody Mon Feb 9 12:52:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339FE1A8736 for ; Mon, 9 Feb 2015 12:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlqaEO5zRiAP for ; Mon, 9 Feb 2015 12:11:39 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 44E2C1A87A8 for ; Mon, 9 Feb 2015 12:10:43 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C43A6180092; Mon, 9 Feb 2015 12:10:10 -0800 (PST) To: torsten@lodderstedt.net, mark.mcgloin@ie.ibm.com, phil.hunt@yahoo.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150209201010.C43A6180092@rfc-editor.org> Date: Mon, 9 Feb 2015 12:10:10 -0800 (PST) Archived-At: Cc: david.gladstone@nib.co.nz, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6819 (4267) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 20:11:41 -0000 The following errata report has been submitted for RFC6819, "OAuth 2.0 Threat Model and Security Considerations". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6819&eid=4267 -------------------------------------- Type: Editorial Reported by: David Gladstone Section: 4.4.1.11 Original Text ------------- If an authorization server includes a nontrivial amount of entropy Corrected Text -------------- If an authorization server includes a trivial amount of entropy Notes ----- The threat being described outlines a scenario where too little entropy is involved; countermeasures include using non-trivial amounts of entropy. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6819 (draft-ietf-oauth-v2-threatmodel-08) -------------------------------------- Title : OAuth 2.0 Threat Model and Security Considerations Publication Date : January 2013 Author(s) : T. Lodderstedt, Ed., M. McGloin, P. Hunt Category : INFORMATIONAL Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Feb 9 12:59:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76071A88B4 for ; Mon, 9 Feb 2015 12:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke8_GU1anQ3O for ; Mon, 9 Feb 2015 12:16:11 -0800 (PST) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC3DE1A88A4 for ; Mon, 9 Feb 2015 12:16:10 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id c9so24958773qcz.7 for ; Mon, 09 Feb 2015 12:16:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Yow/nw2CXboch0GFd5i/K8mJV4jcSwloSElZfjgcvAI=; b=Yc/QtggV3RG9/BPrX78eXqsYMGqIvcJmHel1sVHCS9LA0iQGalr4ZGtMEl4vocg77H 4mnsb3xrfKude474j9nWmlKo3C9lTQAdOxSLjMX2df0cwzTOVXd0uKEjhDbJ9nW8CEip QZGb/s9WtZxMqd22JcAyMhSy6CTfU8wxShTjxpq3v5RNsK4b9YB3jXiD8XBRmr/Iu0tk 0ObO7l9xiutncXpEX5QOspDcNQTRuA1NaVMM561hFhfPLaF2nOT4dDPLVG/MUygaBLvE Wmvl6GIe1p7ZZuXQ3NXBpK4i/6OXCSzaEqdQO0yOt7X7w/gfz1Qm4J5ZlxeTff0yeKvm 7CMg== X-Gm-Message-State: ALoCoQnBH8Z2e5tlkTXk9TbCVeXs672LRemje36wh5XWxHcmOYuvO96AjaihrHc+sHWfjdoqfXkF X-Received: by 10.140.44.134 with SMTP id g6mr42237691qga.85.1423512969957; Mon, 09 Feb 2015 12:16:09 -0800 (PST) Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id f46sm12889603qgd.3.2015.02.09.12.16.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Feb 2015 12:16:09 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_AF558BD8-2116-4972-9BE4-A43EBC36DF8F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <54D91317.9010101@redhat.com> Date: Mon, 9 Feb 2015 17:16:04 -0300 Message-Id: <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> References: <54D91317.9010101@redhat.com> To: Bill Burke X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 20:16:14 -0000 --Apple-Mail=_AF558BD8-2116-4972-9BE4-A43EBC36DF8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 If you don't have a client secret, or are storing the the client secret = in the Javascrypt, then you are probably more at risk using code than = implicit. Implicit is risky because running a OAuth client in the browser is = risky. Using code in that case makes it no better, and arguably worse. Perhaps I don't understand the environment. John B. > On Feb 9, 2015, at 5:05 PM, Bill Burke wrote: >=20 > Due to the security risks of implicit Grant flow, our Javascript = adapter only supports Auth Code Grant flow. Our IDP has an extra step = of allowing you to specify a valid CORS origin for an application. = Anybody see any problems with this kind of approach? Implicit Grant = Flow just seemed really risky to even support as a protocol. >=20 >=20 > On 2/6/2015 4:40 PM, Josh Mandel wrote: >> Hi Adam, >>=20 >> I'm not 100% sure what you're envisioning as an alternative to the >> implicit flow, but if I'm reading between the lines of your question >> correctly, there are two key parts to the answer, because the = implicit >> flow is designed to accomplish two key goals (vs. the authorization = code >> grant): >>=20 >> 1. Shave off one round-trip HTTP request (the step of exchanging a = code >> for a token) >> 2. Avoid unnecessarily leading the token to the client's back-end web = server >>=20 >> Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes >> advantage of the fact that a URL's "#hash" is not sent to the server >> with an HTTP request. By embedding the token in a "#hash", it won't >> inadvertently appear in server logs, for example. So with the = implicit >> flow, I can (for example) statically host a browser-based app at = Amazon >> S3 without having access tokens leak to Amazon. (Of course, if your >> threat model includes a compromised server, then bets are off on this >> point.) >>=20 >> Hope this helps, >>=20 >> -Josh >>=20 >>=20 >>=20 >> On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis >> > > wrote: >>=20 >> Hi,____ >>=20 >> __ __ >>=20 >> Having spent most of my time with native apps and web apps, I now = am >> looking at use cases where I need to implement a user-agent-based >> app. The Implicit flow seems to be optimized for this.____ >>=20 >> __ __ >>=20 >> To test my understanding, this flow is for a JavaScript client (or >> similar) executing within a web browser.____ >>=20 >> __ __ >>=20 >> At step (a) the client directs the UA to the authorization server, >> but the authorization server redirects the UA to a web-hosted = client >> resource. Why? It says so that the web-hosted client resources = can >> push javascript (or other) back into the UA so it can extract the >> access token in the fragment; but some sort of javascript is = already >> running in the browser, since it initiated the authorization = request >> in the first place. So why this extra step? Why not treat the >> javascript client running in the UA like a native app and handle = the >> redirect uri?____ >>=20 >> __ __ >>=20 >> I know this was well thought out when the spec was written, so >> trying to figure out what I=92m missing?____ >>=20 >> __ __ >>=20 >> __ __ >>=20 >> __ __ >>=20 >> Tx! >> adam____ >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > --=20 > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_AF558BD8-2116-4972-9BE4-A43EBC36DF8F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAyMDkyMDE2MDVaMCMGCSqGSIb3DQEJBDEWBBRIxzVQV24FsFW7ro5RMoIU +4TnuTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQB7YqorRUk2T6b2KocMTpAfKR2mfG0MVow147hkULa4GGF50xrvhf85 6nSP8sf7ykpiglG/tHH04JEwqJLjiinfe9Q1xpvsIsEuWbPPv/0eNKUh+F3Eaoyx1f1ssHWK6ieB YFnffJ91GW3/nTYmYLqegVSjfWt0IuL6RZCA9bQjF+krL1IZ4+W0gPhXS8PYUKUg2UcQ69NLUioH F93t1yIsN6wykde9kxHgUUJ9bxBUgH47Z9CwcwlEEM2ihQbIxA7hWCOEw76QCzyU1G7R5dtKv2XJ JIeO6Al17HIQAvAKrijWjTfN4Z8WCp1KiSMMn+GqRpa4o6yIDnvtgAhBoIqWAAAAAAAA --Apple-Mail=_AF558BD8-2116-4972-9BE4-A43EBC36DF8F-- From nobody Mon Feb 9 13:28:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756C31A88E2 for ; Mon, 9 Feb 2015 12:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3MO6OWgghfj for ; Mon, 9 Feb 2015 12:50:16 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C93E1A88E8 for ; Mon, 9 Feb 2015 12:50:16 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t19KoFYT012804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 9 Feb 2015 15:50:15 -0500 Received: from [10.10.61.137] (vpn-61-137.rdu2.redhat.com [10.10.61.137]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t19KoDRm019718; Mon, 9 Feb 2015 15:50:14 -0500 Message-ID: <54D91D87.8040303@redhat.com> Date: Mon, 09 Feb 2015 15:50:15 -0500 From: Bill Burke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John Bradley References: <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> In-Reply-To: <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 20:50:19 -0000 If you don't have a client secret, why is Javascript-based auth code grant flow more risky? We also require SSL and valid redirect URI patterns to be registered for the application. The code can only ever be sent to specific URLs and can only be used once. CORS origin validation is also an extra step we do to ensure a rogue javascript app isn't making any code-to-token requests. I'm just trying to figure out if we missed anything... On 2/9/2015 3:16 PM, John Bradley wrote: > If you don't have a client secret, or are storing the the client secret in the Javascrypt, then you are probably more at risk using code than implicit. > > Implicit is risky because running a OAuth client in the browser is risky. Using code in that case makes it no better, and arguably worse. > > Perhaps I don't understand the environment. > > John B. > >> On Feb 9, 2015, at 5:05 PM, Bill Burke wrote: >> >> Due to the security risks of implicit Grant flow, our Javascript adapter only supports Auth Code Grant flow. Our IDP has an extra step of allowing you to specify a valid CORS origin for an application. Anybody see any problems with this kind of approach? Implicit Grant Flow just seemed really risky to even support as a protocol. >> >> >> On 2/6/2015 4:40 PM, Josh Mandel wrote: >>> Hi Adam, >>> >>> I'm not 100% sure what you're envisioning as an alternative to the >>> implicit flow, but if I'm reading between the lines of your question >>> correctly, there are two key parts to the answer, because the implicit >>> flow is designed to accomplish two key goals (vs. the authorization code >>> grant): >>> >>> 1. Shave off one round-trip HTTP request (the step of exchanging a code >>> for a token) >>> 2. Avoid unnecessarily leading the token to the client's back-end web server >>> >>> Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes >>> advantage of the fact that a URL's "#hash" is not sent to the server >>> with an HTTP request. By embedding the token in a "#hash", it won't >>> inadvertently appear in server logs, for example. So with the implicit >>> flow, I can (for example) statically host a browser-based app at Amazon >>> S3 without having access tokens leak to Amazon. (Of course, if your >>> threat model includes a compromised server, then bets are off on this >>> point.) >>> >>> Hope this helps, >>> >>> -Josh >>> >>> >>> >>> On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis >>> >> > wrote: >>> >>> Hi,____ >>> >>> __ __ >>> >>> Having spent most of my time with native apps and web apps, I now am >>> looking at use cases where I need to implement a user-agent-based >>> app. The Implicit flow seems to be optimized for this.____ >>> >>> __ __ >>> >>> To test my understanding, this flow is for a JavaScript client (or >>> similar) executing within a web browser.____ >>> >>> __ __ >>> >>> At step (a) the client directs the UA to the authorization server, >>> but the authorization server redirects the UA to a web-hosted client >>> resource. Why? It says so that the web-hosted client resources can >>> push javascript (or other) back into the UA so it can extract the >>> access token in the fragment; but some sort of javascript is already >>> running in the browser, since it initiated the authorization request >>> in the first place. So why this extra step? Why not treat the >>> javascript client running in the UA like a native app and handle the >>> redirect uri?____ >>> >>> __ __ >>> >>> I know this was well thought out when the spec was written, so >>> trying to figure out what I’m missing?____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> Tx! >>> adam____ >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From nobody Mon Feb 9 13:36:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECD11A88E3 for ; Mon, 9 Feb 2015 13:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEvJrR1g3aTR for ; Mon, 9 Feb 2015 13:02:58 -0800 (PST) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676791A882F for ; Mon, 9 Feb 2015 13:02:58 -0800 (PST) Received: by mail-qg0-f53.google.com with SMTP id f51so23665483qge.12 for ; Mon, 09 Feb 2015 13:02:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=uvp9DKao4+MDlpo5R2AxmTTuxelMt5pekUkstZbvYIo=; b=dcxOeHyX/+l7mQd6fxTD37m4RNQwLdLxVa1gQHYwA/toY78eIIhDh7cCAF+Dwg1fHZ aZaOcVA4Du1/GV7MoyKTedvrp/n9fptdLzb9331AZsf/4nZnxIql/ALBbiWgm5UzarmC AFBdi3kNXqx1HNwlX1xydkBnD8XcswSVeoxUl6MhHcMcm9UyhEwHQ1FhpNeJXhEPdTUD 4x10jT8lxxm2ltIXR2mxlhofkJhQqF/1AoPR4jD/u9t7DW07Ud8DJn5YeH6t31AvSFU0 llDWHfqhDNEIXYDL21hGZlKosdgvkJqzZ4ha6UvhEzQjG1hh5QVzlqSNcz41ChQv+CCo HGrA== X-Gm-Message-State: ALoCoQl2jY8+APOMpRtBFRg88pcQI1yAlK3v4/M9Eb0tQmw3zusDfnZ7USBICt6Gvmx0lPmaZFPh X-Received: by 10.140.19.78 with SMTP id 72mr44393360qgg.37.1423515777219; Mon, 09 Feb 2015 13:02:57 -0800 (PST) Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id t60sm12939993qge.49.2015.02.09.13.02.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Feb 2015 13:02:56 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_3F37A281-39B1-4315-86AD-C3CDBBB597D7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <54D91D87.8040303@redhat.com> Date: Mon, 9 Feb 2015 18:02:52 -0300 Message-Id: References: <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com> To: Bill Burke X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 21:03:01 -0000 --Apple-Mail=_3F37A281-39B1-4315-86AD-C3CDBBB597D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 You are passing code in a query parameter, and without a secret that is = more likely to be leaked than sending token in the fragment directly = from the authorization endpoint to the browser JS in a fragment. You have several extra round trips for no security benefit. In your = case the code in the query parameter goes from the browser to the = redirect endpoint then must be sent back to the browser, and then to the = token endpoint. So yes using code for that is less secure. Both rely solely on the registered redirect URI for security, but = implicit has fewer hopes and is more friendly to JS. John B. > On Feb 9, 2015, at 5:50 PM, Bill Burke wrote: >=20 > If you don't have a client secret, why is Javascript-based auth code = grant flow more risky? We also require SSL and valid redirect URI = patterns to be registered for the application. The code can only ever = be sent to specific URLs and can only be used once. CORS origin = validation is also an extra step we do to ensure a rogue javascript app = isn't making any code-to-token requests. >=20 > I'm just trying to figure out if we missed anything... >=20 > On 2/9/2015 3:16 PM, John Bradley wrote: >> If you don't have a client secret, or are storing the the client = secret in the Javascrypt, then you are probably more at risk using code = than implicit. >>=20 >> Implicit is risky because running a OAuth client in the browser is = risky. Using code in that case makes it no better, and arguably worse. >>=20 >> Perhaps I don't understand the environment. >>=20 >> John B. >>=20 >>> On Feb 9, 2015, at 5:05 PM, Bill Burke wrote: >>>=20 >>> Due to the security risks of implicit Grant flow, our Javascript = adapter only supports Auth Code Grant flow. Our IDP has an extra step = of allowing you to specify a valid CORS origin for an application. = Anybody see any problems with this kind of approach? Implicit Grant = Flow just seemed really risky to even support as a protocol. >>>=20 >>>=20 >>> On 2/6/2015 4:40 PM, Josh Mandel wrote: >>>> Hi Adam, >>>>=20 >>>> I'm not 100% sure what you're envisioning as an alternative to the >>>> implicit flow, but if I'm reading between the lines of your = question >>>> correctly, there are two key parts to the answer, because the = implicit >>>> flow is designed to accomplish two key goals (vs. the authorization = code >>>> grant): >>>>=20 >>>> 1. Shave off one round-trip HTTP request (the step of exchanging a = code >>>> for a token) >>>> 2. Avoid unnecessarily leading the token to the client's back-end = web server >>>>=20 >>>> Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes >>>> advantage of the fact that a URL's "#hash" is not sent to the = server >>>> with an HTTP request. By embedding the token in a "#hash", it won't >>>> inadvertently appear in server logs, for example. So with the = implicit >>>> flow, I can (for example) statically host a browser-based app at = Amazon >>>> S3 without having access tokens leak to Amazon. (Of course, if your >>>> threat model includes a compromised server, then bets are off on = this >>>> point.) >>>>=20 >>>> Hope this helps, >>>>=20 >>>> -Josh >>>>=20 >>>>=20 >>>>=20 >>>> On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis >>>> >>> > wrote: >>>>=20 >>>> Hi,____ >>>>=20 >>>> __ __ >>>>=20 >>>> Having spent most of my time with native apps and web apps, I = now am >>>> looking at use cases where I need to implement a = user-agent-based >>>> app. The Implicit flow seems to be optimized for this.____ >>>>=20 >>>> __ __ >>>>=20 >>>> To test my understanding, this flow is for a JavaScript client = (or >>>> similar) executing within a web browser.____ >>>>=20 >>>> __ __ >>>>=20 >>>> At step (a) the client directs the UA to the authorization = server, >>>> but the authorization server redirects the UA to a web-hosted = client >>>> resource. Why? It says so that the web-hosted client resources = can >>>> push javascript (or other) back into the UA so it can extract = the >>>> access token in the fragment; but some sort of javascript is = already >>>> running in the browser, since it initiated the authorization = request >>>> in the first place. So why this extra step? Why not treat the >>>> javascript client running in the UA like a native app and handle = the >>>> redirect uri?____ >>>>=20 >>>> __ __ >>>>=20 >>>> I know this was well thought out when the spec was written, so >>>> trying to figure out what I=92m missing?____ >>>>=20 >>>> __ __ >>>>=20 >>>> __ __ >>>>=20 >>>> __ __ >>>>=20 >>>> Tx! >>>> adam____ >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > --=20 > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com --Apple-Mail=_3F37A281-39B1-4315-86AD-C3CDBBB597D7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAyMDkyMTAyNTJaMCMGCSqGSIb3DQEJBDEWBBSt/Zf1QvgBdZn6blg4lst1 fW/ITDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCO6Y2C9D6ZS3Ka8GGg7qckdBqj32rETwXQvAF4sbRnHilD4xbDOQ7Q T/T+ZjcgJlGgcEd/CjLUSkn+aAJe1cxnQXDdvLbcZyN4o4mr43AX7aPkd14GPozSVOY/vzks8Q86 3vT8XZxlhv+JPG3GOb2WIyZaGcYs+EU5gvSpZg3PoIoQyKbscl4Slq3ZshZ2xYcJziDPrCBhI6MA 9gtZeVXh3uwK62M7tCN6JU9n2IFfZgjlhmtNqYL/zD8GnANdmIsbQEjje08UnHADBn8CgdAcEZtR zhF0ePKkSXwSaySWD9ZnzfDyVupsmyxAZ+eJsv3cEwzCSK/3hZfBtXGYTnSXAAAAAAAA --Apple-Mail=_3F37A281-39B1-4315-86AD-C3CDBBB597D7-- From nobody Mon Feb 9 14:02:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A311A8928 for ; Mon, 9 Feb 2015 13:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc6xG746iWUN for ; Mon, 9 Feb 2015 13:21:19 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32341A1A48 for ; Mon, 9 Feb 2015 13:21:19 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t19LLIZ1022622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Feb 2015 21:21:19 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t19LLHIT018653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Feb 2015 21:21:17 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t19LLHIq022184 for ; Mon, 9 Feb 2015 21:21:17 GMT Received: from [10.159.227.236] (/10.159.227.236) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Feb 2015 13:21:16 -0800 Message-ID: <54D924CB.6070504@oracle.com> Date: Mon, 09 Feb 2015 13:21:15 -0800 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: oauth@ietf.org References: <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080606060501080909070100" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 21:21:28 -0000 This is a multi-part message in MIME format. --------------080606060501080909070100 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit The implicit flow depends upon a subtle and little known aspect of browser behavior - that the URI fragment component isn't propagated across redirects. I havent checked this recently - but I am aware that several folks have found that some browser versions dont comply with this requirement. http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-with-oauth-2 The additional round-trip issue is also unclear. The implicit flow requires an additional redirect (round-trip) to retrieve JS which retrieves the access token from the fragment URI. How is that different from a HTTPs callback to exchange the access code for the access token? - prateek > You are passing code in a query parameter, and without a secret that is more likely to be leaked than sending token in the fragment directly from the authorization endpoint to the browser JS in a fragment. > > You have several extra round trips for no security benefit. In your case the code in the query parameter goes from the browser to the redirect endpoint then must be sent back to the browser, and then to the token endpoint. > > So yes using code for that is less secure. > > Both rely solely on the registered redirect URI for security, but implicit has fewer hopes and is more friendly to JS. > > John B. >> On Feb 9, 2015, at 5:50 PM, Bill Burke wrote: >> >> If you don't have a client secret, why is Javascript-based auth code grant flow more risky? We also require SSL and valid redirect URI patterns to be registered for the application. The code can only ever be sent to specific URLs and can only be used once. CORS origin validation is also an extra step we do to ensure a rogue javascript app isn't making any code-to-token requests. >> >> I'm just trying to figure out if we missed anything... >> >> On 2/9/2015 3:16 PM, John Bradley wrote: >>> If you don't have a client secret, or are storing the the client secret in the Javascrypt, then you are probably more at risk using code than implicit. >>> >>> Implicit is risky because running a OAuth client in the browser is risky. Using code in that case makes it no better, and arguably worse. >>> >>> Perhaps I don't understand the environment. >>> >>> John B. >>> >>>> On Feb 9, 2015, at 5:05 PM, Bill Burke wrote: >>>> >>>> Due to the security risks of implicit Grant flow, our Javascript adapter only supports Auth Code Grant flow. Our IDP has an extra step of allowing you to specify a valid CORS origin for an application. Anybody see any problems with this kind of approach? Implicit Grant Flow just seemed really risky to even support as a protocol. >>>> >>>> >>>> On 2/6/2015 4:40 PM, Josh Mandel wrote: >>>>> Hi Adam, >>>>> >>>>> I'm not 100% sure what you're envisioning as an alternative to the >>>>> implicit flow, but if I'm reading between the lines of your question >>>>> correctly, there are two key parts to the answer, because the implicit >>>>> flow is designed to accomplish two key goals (vs. the authorization code >>>>> grant): >>>>> >>>>> 1. Shave off one round-trip HTTP request (the step of exchanging a code >>>>> for a token) >>>>> 2. Avoid unnecessarily leading the token to the client's back-end web server >>>>> >>>>> Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes >>>>> advantage of the fact that a URL's "#hash" is not sent to the server >>>>> with an HTTP request. By embedding the token in a "#hash", it won't >>>>> inadvertently appear in server logs, for example. So with the implicit >>>>> flow, I can (for example) statically host a browser-based app at Amazon >>>>> S3 without having access tokens leak to Amazon. (Of course, if your >>>>> threat model includes a compromised server, then bets are off on this >>>>> point.) >>>>> >>>>> Hope this helps, >>>>> >>>>> -Josh >>>>> >>>>> >>>>> >>>>> On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis >>>>> >>>> > wrote: >>>>> >>>>> Hi,____ >>>>> >>>>> __ __ >>>>> >>>>> Having spent most of my time with native apps and web apps, I now am >>>>> looking at use cases where I need to implement a user-agent-based >>>>> app. The Implicit flow seems to be optimized for this.____ >>>>> >>>>> __ __ >>>>> >>>>> To test my understanding, this flow is for a JavaScript client (or >>>>> similar) executing within a web browser.____ >>>>> >>>>> __ __ >>>>> >>>>> At step (a) the client directs the UA to the authorization server, >>>>> but the authorization server redirects the UA to a web-hosted client >>>>> resource. Why? It says so that the web-hosted client resources can >>>>> push javascript (or other) back into the UA so it can extract the >>>>> access token in the fragment; but some sort of javascript is already >>>>> running in the browser, since it initiated the authorization request >>>>> in the first place. So why this extra step? Why not treat the >>>>> javascript client running in the UA like a native app and handle the >>>>> redirect uri?____ >>>>> >>>>> __ __ >>>>> >>>>> I know this was well thought out when the spec was written, so >>>>> trying to figure out what I’m missing?____ >>>>> >>>>> __ __ >>>>> >>>>> __ __ >>>>> >>>>> __ __ >>>>> >>>>> Tx! >>>>> adam____ >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080606060501080909070100 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit The implicit flow depends upon a subtle and little known aspect of browser behavior - that the URI fragment component isn't propagated across redirects.

I havent checked this recently - but I am aware that several folks have found that some browser versions dont comply with this requirement.
http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-with-oauth-2

The additional round-trip issue is also unclear. The implicit flow requires an additional redirect (round-trip) to retrieve JS which retrieves the access token from the fragment URI.

How is that different from a HTTPs callback to exchange the access code for the access token?

- prateek

You are passing code in a query parameter, and without a secret that is more likely to be leaked than sending token in the fragment directly from the authorization endpoint to the browser JS in a fragment.

You have several extra round trips for no security benefit.   In your case the code in the query parameter goes from the browser to the redirect endpoint then must be sent back to the browser, and then to the token endpoint.

So yes using code for that is less secure.

Both rely solely on the registered redirect URI for security, but implicit has fewer hopes and is more friendly to JS.

John B.

On Feb 9, 2015, at 5:50 PM, Bill Burke <bburke@redhat.com> wrote:

If you don't have a client secret, why is Javascript-based auth code grant flow more risky?  We also require SSL and valid redirect URI patterns to be registered for the application.  The code can only ever be sent to specific URLs and can only be used once.  CORS origin validation is also an extra step we do to ensure a rogue javascript app isn't making any code-to-token requests.

I'm just trying to figure out if we missed anything...

On 2/9/2015 3:16 PM, John Bradley wrote:

If you don't have a client secret, or are storing the the client secret in the Javascrypt, then you are probably more at risk using code than implicit.

Implicit is risky because running a OAuth client in the browser is risky.  Using code in that case makes it no better, and arguably worse.

Perhaps I don't understand the environment.

John B.


On Feb 9, 2015, at 5:05 PM, Bill Burke <bburke@redhat.com> wrote:

Due to the security risks of implicit Grant flow, our Javascript adapter only supports  Auth Code Grant flow.  Our IDP has an extra step of allowing you to specify a valid CORS origin for an application.  Anybody see any problems with this kind of approach?  Implicit Grant Flow just seemed really risky to even support as a protocol.


On 2/6/2015 4:40 PM, Josh Mandel wrote:

Hi Adam,

I'm not 100% sure what you're envisioning as an alternative to the
implicit flow, but if I'm reading between the lines of your question
correctly, there are two key parts to the answer, because the implicit
flow is designed to accomplish two key goals (vs. the authorization code
grant):

1. Shave off one round-trip HTTP request (the step of exchanging a code
for a token)
2. Avoid unnecessarily leading the token to the client's back-end web server

Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes
advantage of the fact that a URL's "#hash" is not sent to the server
with an HTTP request. By embedding the token in a "#hash", it won't
inadvertently appear in server logs, for example. So with the implicit
flow, I can (for example) statically host a browser-based app at Amazon
S3 without having access tokens leak to Amazon. (Of course, if your
threat model includes a compromised server, then bets are off on this
point.)

Hope this helps,

  -Josh



On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis
<Adam.Lewis@motorolasolutions.com
<mailto:Adam.Lewis@motorolasolutions.com>> wrote:

   Hi,____

   __ __

   Having spent most of my time with native apps and web apps, I now am
   looking at use cases where I need to implement a user-agent-based
   app.  The Implicit flow seems to be optimized for this.____

   __ __

   To test my understanding, this flow is for a JavaScript client (or
   similar) executing within a web browser.____

   __ __

   At step (a) the client directs the UA to the authorization server,
   but the authorization server redirects the UA to a web-hosted client
   resource.  Why?  It says so that the web-hosted client resources can
   push javascript (or other) back into the UA so it can extract the
   access token in the fragment; but some sort of javascript is already
   running in the browser, since it initiated the authorization request
   in the first place.  So why this extra step?  Why not treat the
   javascript client running in the UA like a native app and handle the
   redirect uri?____

   __ __

   I know this was well thought out when the spec was written, so
   trying to figure out what I’m missing?____

   __ __

   __ __

   __ __

   Tx!
   adam____


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




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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

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


        

        
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


      

      

      

      

      

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


    

    

  


--------------080606060501080909070100--


From nobody Mon Feb  9 14:06:01 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D041A1A48 for ; Mon,  9 Feb 2015 13:31:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjxd_Fwjf6Po for ; Mon,  9 Feb 2015 13:31:24 -0800 (PST)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1C21A8940 for ; Mon,  9 Feb 2015 13:31:23 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id i8so3591081qcq.5 for ; Mon, 09 Feb 2015 13:31:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hf6/XqE2Rza8On9oK7qFZAzI25YCYCqtvtaIORfeW9E=; b=EG6BeZJq500bFcucG/xeGTYhTRrscjZKOOU4ZttP7YcCykXT4NL8833+vDrzo3zuoS dPHPndZAg0EmUnihJ66nxdB4z4aAP/OS2lq8EfuGXPf6APpQNhaCF2PztHaNKhA/VCyc pKBaJNE7amVg4nrk+r4ty8ClmfRZn3PxPQgFl/fq6jBX3/Bdo0MeQASnJ4O4970mv5ys b3OIgXbNlN4BM9hkx3BdYBMGypTbc+y23SwjA605uBmRTeKF7qrjk5LtHQKGEYkOpV4h t4iy7D91dpODWqwXkGb7G5EG/V5rwN+WEdbJ59V//SNkLhTVl2ylnitcLsnjoSpHyWYx T86w==
X-Gm-Message-State: ALoCoQnTn5+U+moCcq7Z0xExKx2W8OZIODgNLV8SuSVOR3l7O6tOEeUtsDLZzU8P01xvilsO03UA
X-Received: by 10.224.87.138 with SMTP id w10mr45327937qal.79.1423517482598; Mon, 09 Feb 2015 13:31:22 -0800 (PST)
Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id d5sm4921161qam.43.2015.02.09.13.31.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Feb 2015 13:31:22 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_5F6A6F93-3D6A-4573-BF3E-121AD43B8CCD"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: <54D924CB.6070504@oracle.com>
Date: Mon, 9 Feb 2015 18:31:17 -0300
Message-Id: <3B0DDA4D-F540-4E23-9842-275532F7405F@ve7jtb.com>
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D924CB.6070504@oracle.com>
To: Prateek Mishra 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Feb 2015 21:31:28 -0000

--Apple-Mail=_5F6A6F93-3D6A-4573-BF3E-121AD43B8CCD
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_EBD76CEC-1F4F-47FD-8B3D-3456BCACCD5A"


--Apple-Mail=_EBD76CEC-1F4F-47FD-8B3D-3456BCACCD5A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Typically the implicit callback JS is part of the application that is =
already loaded and cached in the browser.

The implicit flow doesn=92t depend on on the fragment not being =
re-appended to the resource location URI in the 302.  It would =
admittedly be more secure if that didn=92t happen. =20
Re-appending the fragment is the correct browser behaviour according to =
the W3C.

I still think you are farther ahead with that than leaking the code in =
the referrer.

Implicit if done correctly has the token in one leg.  code on the other =
hand has the code in 4 legs and the token in one.

It is having the JS make the exchange of code for the AT without a =
secret that is the problem in my opinion.

If the client is a server that is doing the code -> token exchange then =
the answer is different, but the question was for a JS only client.

John B.


> On Feb 9, 2015, at 6:21 PM, Prateek Mishra  =
wrote:
>=20
> The implicit flow depends upon a subtle and little known aspect of =
browser behavior - that the URI fragment component isn't propagated =
across redirects.=20
>=20
> I havent checked this recently - but I am aware that several folks =
have found that some browser versions dont comply with this requirement.
> =
http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-=
with-oauth-2 =

>=20
> The additional round-trip issue is also unclear. The implicit flow =
requires an additional redirect (round-trip) to retrieve JS which =
retrieves the access token from the fragment URI.=20
>=20
> How is that different from a HTTPs callback to exchange the access =
code for the access token?
>=20
> - prateek
>=20
>> You are passing code in a query parameter, and without a secret that =
is more likely to be leaked than sending token in the fragment directly =
from the authorization endpoint to the browser JS in a fragment.
>>=20
>> You have several extra round trips for no security benefit.   In your =
case the code in the query parameter goes from the browser to the =
redirect endpoint then must be sent back to the browser, and then to the =
token endpoint.
>>=20
>> So yes using code for that is less secure.
>>=20
>> Both rely solely on the registered redirect URI for security, but =
implicit has fewer hopes and is more friendly to JS.
>>=20
>> John B.
>>> On Feb 9, 2015, at 5:50 PM, Bill Burke  =
 wrote:
>>>=20
>>> If you don't have a client secret, why is Javascript-based auth code =
grant flow more risky?  We also require SSL and valid redirect URI =
patterns to be registered for the application.  The code can only ever =
be sent to specific URLs and can only be used once.  CORS origin =
validation is also an extra step we do to ensure a rogue javascript app =
isn't making any code-to-token requests.
>>>=20
>>> I'm just trying to figure out if we missed anything...
>>>=20
>>> On 2/9/2015 3:16 PM, John Bradley wrote:
>>>> If you don't have a client secret, or are storing the the client =
secret in the Javascrypt, then you are probably more at risk using code =
than implicit.
>>>>=20
>>>> Implicit is risky because running a OAuth client in the browser is =
risky.  Using code in that case makes it no better, and arguably worse.
>>>>=20
>>>> Perhaps I don't understand the environment.
>>>>=20
>>>> John B.
>>>>=20
>>>>> On Feb 9, 2015, at 5:05 PM, Bill Burke  =
 wrote:
>>>>>=20
>>>>> Due to the security risks of implicit Grant flow, our Javascript =
adapter only supports  Auth Code Grant flow.  Our IDP has an extra step =
of allowing you to specify a valid CORS origin for an application.  =
Anybody see any problems with this kind of approach?  Implicit Grant =
Flow just seemed really risky to even support as a protocol.
>>>>>=20
>>>>>=20
>>>>> On 2/6/2015 4:40 PM, Josh Mandel wrote:
>>>>>> Hi Adam,
>>>>>>=20
>>>>>> I'm not 100% sure what you're envisioning as an alternative to =
the
>>>>>> implicit flow, but if I'm reading between the lines of your =
question
>>>>>> correctly, there are two key parts to the answer, because the =
implicit
>>>>>> flow is designed to accomplish two key goals (vs. the =
authorization code
>>>>>> grant):
>>>>>>=20
>>>>>> 1. Shave off one round-trip HTTP request (the step of exchanging =
a code
>>>>>> for a token)
>>>>>> 2. Avoid unnecessarily leading the token to the client's back-end =
web server
>>>>>>=20
>>>>>> Goal 1 is straightforward. For goal 2: OAuth2's implicit flow =
takes
>>>>>> advantage of the fact that a URL's "#hash" is not sent to the =
server
>>>>>> with an HTTP request. By embedding the token in a "#hash", it =
won't
>>>>>> inadvertently appear in server logs, for example. So with the =
implicit
>>>>>> flow, I can (for example) statically host a browser-based app at =
Amazon
>>>>>> S3 without having access tokens leak to Amazon. (Of course, if =
your
>>>>>> threat model includes a compromised server, then bets are off on =
this
>>>>>> point.)
>>>>>>=20
>>>>>> Hope this helps,
>>>>>>=20
>>>>>>   -Josh
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis
>>>>>> 
>>>>>>  =
> wrote:
>>>>>>=20
>>>>>>    Hi,____
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    Having spent most of my time with native apps and web apps, I =
now am
>>>>>>    looking at use cases where I need to implement a =
user-agent-based
>>>>>>    app.  The Implicit flow seems to be optimized for this.____
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    To test my understanding, this flow is for a JavaScript client =
(or
>>>>>>    similar) executing within a web browser.____
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    At step (a) the client directs the UA to the authorization =
server,
>>>>>>    but the authorization server redirects the UA to a web-hosted =
client
>>>>>>    resource.  Why?  It says so that the web-hosted client =
resources can
>>>>>>    push javascript (or other) back into the UA so it can extract =
the
>>>>>>    access token in the fragment; but some sort of javascript is =
already
>>>>>>    running in the browser, since it initiated the authorization =
request
>>>>>>    in the first place.  So why this extra step?  Why not treat =
the
>>>>>>    javascript client running in the UA like a native app and =
handle the
>>>>>>    redirect uri?____
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    I know this was well thought out when the spec was written, so
>>>>>>    trying to figure out what I=92m missing?____
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    Tx!
>>>>>>    adam____
>>>>>>=20
>>>>>>=20
>>>>>>    _______________________________________________
>>>>>>    OAuth mailing list
>>>>>>    OAuth@ietf.org   =

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

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

>>>>>>=20
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com 
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/oauth =

>>> --=20
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com 
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_EBD76CEC-1F4F-47FD-8B3D-3456BCACCD5A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Typically the implicit callback JS is part of the application =
that is already loaded and cached in the browser.

The implicit flow doesn=92t depend on =
on the fragment not being re-appended to the resource location URI in =
the 302.  It would admittedly be more secure if that didn=92t =
happen.  
Re-appending the fragment is the =
correct browser behaviour according to the W3C.

I still think you are farther ahead =
with that than leaking the code in the referrer.

Implicit if done correctly has the =
token in one leg.  code on the other hand has the code in 4 legs =
and the token in one.

It is having the JS make the exchange of code for the AT =
without a secret that is the problem in my opinion.

If the client is a =
server that is doing the code -> token exchange then the answer is =
different, but the question was for a JS only client.

John B.


On =
Feb 9, 2015, at 6:21 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:


 =20
    
 =20
  

    The implicit flow depends upon a subtle and little known aspect of
    browser behavior - that the URI fragment component isn't propagated
    across redirects. 

    

    I havent checked this recently - but I am aware that several folks
    have found that some browser versions dont comply with this
    requirement.

http://weblog.bulknews.net/post/85008516879/covert-r=
edirect-vulnerability-with-oauth-2

    

    The additional round-trip issue is also unclear. The implicit flow
    requires an additional redirect (round-trip) to retrieve JS which
    retrieves the access token from the fragment URI. 

    

    How is that different from a HTTPs callback to exchange the access
    code for the access token?

    

    - prateek

    

    

      
You are passing code in a query =
parameter, and without a secret that is more likely to be leaked than =
sending token in the fragment directly from the authorization endpoint =
to the browser JS in a fragment.

You have several extra round trips for no security benefit.   In your =
case the code in the query parameter goes from the browser to the =
redirect endpoint then must be sent back to the browser, and then to the =
token endpoint.

So yes using code for that is less secure.

Both rely solely on the registered redirect URI for security, but =
implicit has fewer hopes and is more friendly to JS.

John B.


      

        
On Feb 9, 2015, at 5:50 PM, Bill Burke =
<bburke@redhat.com> wrote:

If you don't have a client secret, why is Javascript-based auth code =
grant flow more risky?  We also require SSL and valid redirect URI =
patterns to be registered for the application.  The code can only ever =
be sent to specific URLs and can only be used once.  CORS origin =
validation is also an extra step we do to ensure a rogue javascript app =
isn't making any code-to-token requests.

I'm just trying to figure out if we missed anything...

On 2/9/2015 3:16 PM, John Bradley wrote:


        

          
If you don't have a client secret, =
or are storing the the client secret in the Javascrypt, then you are =
probably more at risk using code than implicit.

Implicit is risky because running a OAuth client in the browser is =
risky.  Using code in that case makes it no better, and arguably worse.

Perhaps I don't understand the environment.

John B.



          

            
On Feb 9, 2015, at 5:05 PM, Bill =
Burke <bburke@redhat.com> wrote:

Due to the security risks of implicit Grant flow, our Javascript adapter =
only supports  Auth Code Grant flow.  Our IDP has an extra step of =
allowing you to specify a valid CORS origin for an application.  Anybody =
see any problems with this kind of approach?  Implicit Grant Flow just =
seemed really risky to even support as a protocol.


On 2/6/2015 4:40 PM, Josh Mandel wrote:


            

              
Hi Adam,

I'm not 100% sure what you're envisioning as an alternative to the
implicit flow, but if I'm reading between the lines of your question
correctly, there are two key parts to the answer, because the implicit
flow is designed to accomplish two key goals (vs. the authorization code
grant):

1. Shave off one round-trip HTTP request (the step of exchanging a code
for a token)
2. Avoid unnecessarily leading the token to the client's back-end web =
server

Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes
advantage of the fact that a URL's "#hash" is not sent to the server
with an HTTP request. By embedding the token in a "#hash", it won't
inadvertently appear in server logs, for example. So with the implicit
flow, I can (for example) statically host a browser-based app at Amazon
S3 without having access tokens leak to Amazon. (Of course, if your
threat model includes a compromised server, then bets are off on this
point.)

Hope this helps,

  -Josh



On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis
<Adam.Lewis@motorolasoluti=
ons.com
<mailto:Adam.Lewis@mot=
orolasolutions.com>> wrote:

   Hi,____

   __ __

   Having spent most of my time with native apps and web apps, I now am
   looking at use cases where I need to implement a user-agent-based
   app.  The Implicit flow seems to be optimized for this.____

   __ __

   To test my understanding, this flow is for a JavaScript client (or
   similar) executing within a web browser.____

   __ __

   At step (a) the client directs the UA to the authorization server,
   but the authorization server redirects the UA to a web-hosted client
   resource.  Why?  It says so that the web-hosted client resources can
   push javascript (or other) back into the UA so it can extract the
   access token in the fragment; but some sort of javascript is already
   running in the browser, since it initiated the authorization request
   in the first place.  So why this extra step?  Why not treat the
   javascript client running in the UA like a native app and handle the
   redirect uri?____

   __ __

   I know this was well thought out when the spec was written, so
   trying to figure out what I=92m missing?____

   __ __

   __ __

   __ __

   Tx!
   adam____


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




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



            

            
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

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


          

          

        

        
--=20
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


      

      

      

      

      

      
_______________________________________________
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=_EBD76CEC-1F4F-47FD-8B3D-3456BCACCD5A--

--Apple-Mail=_5F6A6F93-3D6A-4573-BF3E-121AD43B8CCD
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMDkyMTMxMThaMCMGCSqGSIb3DQEJBDEWBBQtvy1fcUgK1L7Ier3reVsN
ewOEBzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAcWjYupv2A7sNp+cCykzoYT2ACcSifbRKQ8W/t3TKXQ6UXfBdqRMQ4
ZnasP2bVnuYL6c25pvCfBrq+HUS4B+Q/1stOXo2dPct/VS5rx5M5WoyIjRIWUUWTQ5WSnu79KenX
ZxqXd5Uo35/iMAKma88UKm66Gi2RMwZmtx+zO0EYhqR8mHJIvktW86oK+ZGvgSxDNmfEF+iiLmB6
NY7r6TLHn1BtDmiS1sTpGjnLByfcHAtlwdUJBIY93e635by/PNMriELAt9583NpaJ4aCL7rAS9p2
3b0sckppY6/ueY78IPQmUpSM+I+K05f+dz4dFbnUs+idG/0DdHPemy0mZQ5UAAAAAAAA
--Apple-Mail=_5F6A6F93-3D6A-4573-BF3E-121AD43B8CCD--


From nobody Mon Feb  9 14:15:39 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626921A8853 for ; Mon,  9 Feb 2015 13:44:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TADx5OwTgYLe for ; Mon,  9 Feb 2015 13:44:28 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC9A1A6EF2 for ; Mon,  9 Feb 2015 13:44:28 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t19LiRUH002652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 9 Feb 2015 16:44:28 -0500
Received: from [10.10.61.137] (vpn-61-137.rdu2.redhat.com [10.10.61.137]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t19LiQO4015667; Mon, 9 Feb 2015 16:44:27 -0500
Message-ID: <54D92A3C.4060106@redhat.com>
Date: Mon, 09 Feb 2015 16:44:28 -0500
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: John Bradley 
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Feb 2015 21:44:31 -0000

For implicit flow, wouldn't the token be available in the browser 
history and could also possibly be bookmarked by accident or on purpose? 
  If a code is bookmarked, so what?  It is only valid for a tiny window 
(milliseconds).

Please tell me how a code is more likely to be leaked without a client 
secret when it can only be sent via SSL to a validated URL.


On 2/9/2015 4:02 PM, John Bradley wrote:
> You are passing code in a query parameter, and without a secret that is more likely to be leaked than sending token in the fragment directly from the authorization endpoint to the browser JS in a fragment.
>
> You have several extra round trips for no security benefit.   In your case the code in the query parameter goes from the browser to the redirect endpoint then must be sent back to the browser, and then to the token endpoint.
>
> So yes using code for that is less secure.
>
> Both rely solely on the registered redirect URI for security, but implicit has fewer hopes and is more friendly to JS.
>
> John B.
>> On Feb 9, 2015, at 5:50 PM, Bill Burke  wrote:
>>
>> If you don't have a client secret, why is Javascript-based auth code grant flow more risky?  We also require SSL and valid redirect URI patterns to be registered for the application.  The code can only ever be sent to specific URLs and can only be used once.  CORS origin validation is also an extra step we do to ensure a rogue javascript app isn't making any code-to-token requests.
>>
>> I'm just trying to figure out if we missed anything...
>>
>> On 2/9/2015 3:16 PM, John Bradley wrote:
>>> If you don't have a client secret, or are storing the the client secret in the Javascrypt, then you are probably more at risk using code than implicit.
>>>
>>> Implicit is risky because running a OAuth client in the browser is risky.  Using code in that case makes it no better, and arguably worse.
>>>
>>> Perhaps I don't understand the environment.
>>>
>>> John B.
>>>
>>>> On Feb 9, 2015, at 5:05 PM, Bill Burke  wrote:
>>>>
>>>> Due to the security risks of implicit Grant flow, our Javascript adapter only supports  Auth Code Grant flow.  Our IDP has an extra step of allowing you to specify a valid CORS origin for an application.  Anybody see any problems with this kind of approach?  Implicit Grant Flow just seemed really risky to even support as a protocol.
>>>>
>>>>
>>>> On 2/6/2015 4:40 PM, Josh Mandel wrote:
>>>>> Hi Adam,
>>>>>
>>>>> I'm not 100% sure what you're envisioning as an alternative to the
>>>>> implicit flow, but if I'm reading between the lines of your question
>>>>> correctly, there are two key parts to the answer, because the implicit
>>>>> flow is designed to accomplish two key goals (vs. the authorization code
>>>>> grant):
>>>>>
>>>>> 1. Shave off one round-trip HTTP request (the step of exchanging a code
>>>>> for a token)
>>>>> 2. Avoid unnecessarily leading the token to the client's back-end web server
>>>>>
>>>>> Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes
>>>>> advantage of the fact that a URL's "#hash" is not sent to the server
>>>>> with an HTTP request. By embedding the token in a "#hash", it won't
>>>>> inadvertently appear in server logs, for example. So with the implicit
>>>>> flow, I can (for example) statically host a browser-based app at Amazon
>>>>> S3 without having access tokens leak to Amazon. (Of course, if your
>>>>> threat model includes a compromised server, then bets are off on this
>>>>> point.)
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>>    -Josh
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis
>>>>> >>>> > wrote:
>>>>>
>>>>>     Hi,____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     Having spent most of my time with native apps and web apps, I now am
>>>>>     looking at use cases where I need to implement a user-agent-based
>>>>>     app.  The Implicit flow seems to be optimized for this.____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     To test my understanding, this flow is for a JavaScript client (or
>>>>>     similar) executing within a web browser.____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     At step (a) the client directs the UA to the authorization server,
>>>>>     but the authorization server redirects the UA to a web-hosted client
>>>>>     resource.  Why?  It says so that the web-hosted client resources can
>>>>>     push javascript (or other) back into the UA so it can extract the
>>>>>     access token in the fragment; but some sort of javascript is already
>>>>>     running in the browser, since it initiated the authorization request
>>>>>     in the first place.  So why this extra step?  Why not treat the
>>>>>     javascript client running in the UA like a native app and handle the
>>>>>     redirect uri?____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     I know this was well thought out when the spec was written, so
>>>>>     trying to figure out what I’m missing?____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     __ __
>>>>>
>>>>>     __ __
>>>>>
>>>>>     Tx!
>>>>>     adam____
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     OAuth mailing list
>>>>>     OAuth@ietf.org 
>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Mon Feb  9 14:33:46 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE441A895C for ; Mon,  9 Feb 2015 14:04:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nNzlix40NrR for ; Mon,  9 Feb 2015 14:03:57 -0800 (PST)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA661A883B for ; Mon,  9 Feb 2015 14:03:57 -0800 (PST)
Received: by mail-qa0-f53.google.com with SMTP id k15so3102870qaq.12 for ; Mon, 09 Feb 2015 14:03:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=XKUkF4VBn7IKsA+BToKU2N0+vPSpiHEGWTKsfYL8xFI=; b=Q9vyIFM2tQSH/PxvvWLdHL8hD3DwKP+lmsyc7t8j16/mjvpkHJy2aZWjqlWba6EoAz mNCNbchBlMUCOrpU+I+Df4OQQmKg2SU75SKNCKm4cyAhZ+aV44b0yvApT6+zurwq9nv4 OwFLzlXpy5SNcVcHGLlZjftAVuENc77F5XSr3XmGomaYC06uqWPqxxl3gEjUvKKq0sTH kgUsBkuoDpaOv0mjP9bPFTWwJzptKY7DSs4PnVvnY8heEahzK8aa2AKdRyo32dx8RvRz 8XOl+937Uys6vW6PxuGAKMdOlxy2H8vhN4gNkzgqb8JEnQNiptS96QKV+wRAP3DBSU1F 9A1A==
X-Gm-Message-State: ALoCoQn/vWqxqiMK8HLWC8KtgeLsHObX5MwZ+OLlE6M4qKiE/sRED58QZAEClZ/ENg4dxWqulz9o
X-Received: by 10.140.44.134 with SMTP id g6mr43184669qga.85.1423519436552; Mon, 09 Feb 2015 14:03:56 -0800 (PST)
Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id t10sm13154747qaj.23.2015.02.09.14.03.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Feb 2015 14:03:55 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_5CF0AAD6-9D92-4FC9-9B7E-7DFDF77BC112"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: <54D92A3C.4060106@redhat.com>
Date: Mon, 9 Feb 2015 19:03:49 -0300
Message-Id: <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com>
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D92A3C.4060106@redhat.com>
To: Bill Burke 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Feb 2015 22:04:00 -0000

--Apple-Mail=_5CF0AAD6-9D92-4FC9-9B7E-7DFDF77BC112
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

OK, I don't know if the WG has discussed the issue of fragments in =
browser history. =20

So you are trading off several round trips against the possibility of a =
token leaking in browser history or bookmark?

One extension that Connect introduced was a "code id_token" response =
type that is fragment encoded.  That would let you pass the code =
directly to the JS saving two legs.=20

On the wire with a registered https redirect implicit has less hops to =
protect, but you are correct that in the browser there might be threats =
that could extract the AT from the fragment if it is logged in the =
browser.

The real answer will eventually be using token binding to lock AT to =
browser instances.  =20

John B.
> On Feb 9, 2015, at 6:44 PM, Bill Burke  wrote:
>=20
> For implicit flow, wouldn't the token be available in the browser =
history and could also possibly be bookmarked by accident or on purpose? =
 If a code is bookmarked, so what?  It is only valid for a tiny window =
(milliseconds).
>=20
> Please tell me how a code is more likely to be leaked without a client =
secret when it can only be sent via SSL to a validated URL.
>=20
>=20
> On 2/9/2015 4:02 PM, John Bradley wrote:
>> You are passing code in a query parameter, and without a secret that =
is more likely to be leaked than sending token in the fragment directly =
from the authorization endpoint to the browser JS in a fragment.
>>=20
>> You have several extra round trips for no security benefit.   In your =
case the code in the query parameter goes from the browser to the =
redirect endpoint then must be sent back to the browser, and then to the =
token endpoint.
>>=20
>> So yes using code for that is less secure.
>>=20
>> Both rely solely on the registered redirect URI for security, but =
implicit has fewer hopes and is more friendly to JS.
>>=20
>> John B.
>>> On Feb 9, 2015, at 5:50 PM, Bill Burke  wrote:
>>>=20
>>> If you don't have a client secret, why is Javascript-based auth code =
grant flow more risky?  We also require SSL and valid redirect URI =
patterns to be registered for the application.  The code can only ever =
be sent to specific URLs and can only be used once.  CORS origin =
validation is also an extra step we do to ensure a rogue javascript app =
isn't making any code-to-token requests.
>>>=20
>>> I'm just trying to figure out if we missed anything...
>>>=20
>>> On 2/9/2015 3:16 PM, John Bradley wrote:
>>>> If you don't have a client secret, or are storing the the client =
secret in the Javascrypt, then you are probably more at risk using code =
than implicit.
>>>>=20
>>>> Implicit is risky because running a OAuth client in the browser is =
risky.  Using code in that case makes it no better, and arguably worse.
>>>>=20
>>>> Perhaps I don't understand the environment.
>>>>=20
>>>> John B.
>>>>=20
>>>>> On Feb 9, 2015, at 5:05 PM, Bill Burke  wrote:
>>>>>=20
>>>>> Due to the security risks of implicit Grant flow, our Javascript =
adapter only supports  Auth Code Grant flow.  Our IDP has an extra step =
of allowing you to specify a valid CORS origin for an application.  =
Anybody see any problems with this kind of approach?  Implicit Grant =
Flow just seemed really risky to even support as a protocol.
>>>>>=20
>>>>>=20
>>>>> On 2/6/2015 4:40 PM, Josh Mandel wrote:
>>>>>> Hi Adam,
>>>>>>=20
>>>>>> I'm not 100% sure what you're envisioning as an alternative to =
the
>>>>>> implicit flow, but if I'm reading between the lines of your =
question
>>>>>> correctly, there are two key parts to the answer, because the =
implicit
>>>>>> flow is designed to accomplish two key goals (vs. the =
authorization code
>>>>>> grant):
>>>>>>=20
>>>>>> 1. Shave off one round-trip HTTP request (the step of exchanging =
a code
>>>>>> for a token)
>>>>>> 2. Avoid unnecessarily leading the token to the client's back-end =
web server
>>>>>>=20
>>>>>> Goal 1 is straightforward. For goal 2: OAuth2's implicit flow =
takes
>>>>>> advantage of the fact that a URL's "#hash" is not sent to the =
server
>>>>>> with an HTTP request. By embedding the token in a "#hash", it =
won't
>>>>>> inadvertently appear in server logs, for example. So with the =
implicit
>>>>>> flow, I can (for example) statically host a browser-based app at =
Amazon
>>>>>> S3 without having access tokens leak to Amazon. (Of course, if =
your
>>>>>> threat model includes a compromised server, then bets are off on =
this
>>>>>> point.)
>>>>>>=20
>>>>>> Hope this helps,
>>>>>>=20
>>>>>>   -Josh
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis
>>>>>> >>>>> > wrote:
>>>>>>=20
>>>>>>    Hi,____
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    Having spent most of my time with native apps and web apps, I =
now am
>>>>>>    looking at use cases where I need to implement a =
user-agent-based
>>>>>>    app.  The Implicit flow seems to be optimized for this.____
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    To test my understanding, this flow is for a JavaScript client =
(or
>>>>>>    similar) executing within a web browser.____
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    At step (a) the client directs the UA to the authorization =
server,
>>>>>>    but the authorization server redirects the UA to a web-hosted =
client
>>>>>>    resource.  Why?  It says so that the web-hosted client =
resources can
>>>>>>    push javascript (or other) back into the UA so it can extract =
the
>>>>>>    access token in the fragment; but some sort of javascript is =
already
>>>>>>    running in the browser, since it initiated the authorization =
request
>>>>>>    in the first place.  So why this extra step?  Why not treat =
the
>>>>>>    javascript client running in the UA like a native app and =
handle the
>>>>>>    redirect uri?____
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    I know this was well thought out when the spec was written, so
>>>>>>    trying to figure out what I=92m missing?____
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    __ __
>>>>>>=20
>>>>>>    Tx!
>>>>>>    adam____
>>>>>>=20
>>>>>>=20
>>>>>>    _______________________________________________
>>>>>>    OAuth mailing list
>>>>>>    OAuth@ietf.org 
>>>>>>    https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>=20
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>=20
>=20
> --=20
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com


--Apple-Mail=_5CF0AAD6-9D92-4FC9-9B7E-7DFDF77BC112
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMDkyMjAzNTBaMCMGCSqGSIb3DQEJBDEWBBTehm1UJ8uLv5//Wc8eYrSV
u/uRzzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAZwmCruf1QPLBxTaWJquBfxtaLWzbx4ZFak/0eeWmLwy26du+QAZEo
p7nvZOEudXbFxgXSdnS31VvDeioBrdgEerAjYwcEi3Pp1s/pg2iIED23WTiTWZN9f+4KuEFfdTSh
RQymu+xxFcHJvCgacf8SolV/SvWUafphjXEC51u0EOB6Lp6o8YEf8c3tdvL73A26YmlAE957ezER
rKFM02eNoXZqJk2I9gxGfBnpc5qbOd5ppwsXqh7aKMtXwxllmZ6k49pERXiV8S0vDbG/9WsNXpu0
zeliQ+RTyCPHDyIXA7FSwWuisy70x1LsC9OKWP34J4NAVimdZ3FvKCyJTE/pAAAAAAAA
--Apple-Mail=_5CF0AAD6-9D92-4FC9-9B7E-7DFDF77BC112--


From nobody Mon Feb  9 14:51:21 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7A91A8A63 for ; Mon,  9 Feb 2015 14:32:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc4_FVlM-joz for ; Mon,  9 Feb 2015 14:32:24 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5830F1A8A52 for ; Mon,  9 Feb 2015 14:32:24 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t19MWNmP026426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 9 Feb 2015 17:32:23 -0500
Received: from [10.10.61.137] (vpn-61-137.rdu2.redhat.com [10.10.61.137]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t19MWMXA004847; Mon, 9 Feb 2015 17:32:23 -0500
Message-ID: <54D93578.9050105@redhat.com>
Date: Mon, 09 Feb 2015 17:32:24 -0500
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: John Bradley 
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D92A3C.4060106@redhat.com> <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com>
In-Reply-To: <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Feb 2015 22:32:26 -0000

On 2/9/2015 5:03 PM, John Bradley wrote:
> OK, I don't know if the WG has discussed the issue of fragments in browser history.
>
> So you are trading off several round trips against the possibility of a token leaking in browser history or bookmark?
>

Yes, bookmarking tokens is a little scary, IMO, as we've already run 
into users bookmarking URLs with codes in them.

Also, wasn't there additional security vulnerabilities surrounding 
implicit flow?  Maybe these were just the product of incorrect 
implementations, I don't remember, it was a while ago.

> One extension that Connect introduced was a "code id_token" response type that is fragment encoded.  That would let you pass the code directly to the JS saving two legs.
>

It looks like OIDC added a "response_mode" parameter where you can 
specify "query" or "fragment".  Thanks for pointing this out!


Thanks for all the help.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Mon Feb  9 14:56:51 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90C41A8A25 for ; Mon,  9 Feb 2015 14:42:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss97FC8-BiZ1 for ; Mon,  9 Feb 2015 14:42:15 -0800 (PST)
Received: from relay2.gtri.gatech.edu (relay2.gtri.gatech.edu [130.207.199.168]) by ietfa.amsl.com (Postfix) with ESMTP id 4BED31A8A1D for ; Mon,  9 Feb 2015 14:42:14 -0800 (PST)
X-ASG-Debug-ID: 1423521729-0768e41c96482000001-2rbJmR
Received: from APATLISDMAIL02.core.gtri.org (apatlisdmail02.core.gtri.org [10.41.31.66]) by relay2.gtri.gatech.edu with ESMTP id mLvovngso9GFRQIi; Mon, 09 Feb 2015 14:42:09 -0800 (PST)
X-Barracuda-Envelope-From: Anwar.Reddick@gtri.gatech.edu
Received: from APATLISDMAIL02.core.gtri.org (10.41.31.66) by APATLISDMAIL02.core.gtri.org (10.41.31.66) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 9 Feb 2015 17:42:09 -0500
Received: from APATLISDMAIL02.core.gtri.org ([fe80::3826:8bd1:e211:9431]) by APATLISDMAIL02.core.gtri.org ([fe80::3826:8bd1:e211:9431%18]) with mapi id 15.00.0995.028; Mon, 9 Feb 2015 17:42:09 -0500
From: "Reddick, Anwar" 
To: Bill Burke , John Bradley 
Thread-Topic: [OAUTH-WG] Confusion on Implicit Grant flow
X-ASG-Orig-Subj: Re: [OAUTH-WG] Confusion on Implicit Grant flow
Thread-Index: AdBCU7lczcAZFshKSMOM30KEynNz8AAK7+GAAJOOJYAAAFyJAAABMaCAAABwzQAAAXPvAAAArQCAAAD/jgD//67mmA==
Date: Mon, 9 Feb 2015 22:42:08 +0000
Message-ID: 
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D92A3C.4060106@redhat.com> <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com>, <54D93578.9050105@redhat.com>
In-Reply-To: <54D93578.9050105@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_e293564ad29d42bfab7e521afbd20a83APATLISDMAIL02coregtrio_"
MIME-Version: 1.0
X-Barracuda-Connect: apatlisdmail02.core.gtri.org[10.41.31.66]
X-Barracuda-Start-Time: 1423521729
X-Barracuda-URL: http://130.207.199.168:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at gtri.gatech.edu
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.15088 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Feb 2015 22:42:18 -0000

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

Hi Bill,

I'm not sure if I have permission to post to the OAuth list. Anyway, if you=
r page that does the OAuth processing includes third party scripts, then th=
ose scripts will probably have access to the code, client secret, and acces=
s token. I believe this concern is addressed in the security section of RFC=
 6749.

E. Anwar Reddick
Research Scientist
Georgia Tech Research Institute

----- Reply message -----
From: "Bill Burke" 
To: "John Bradley" 
Cc: "oauth@ietf.org" 
Subject: [OAUTH-WG] Confusion on Implicit Grant flow
Date: Mon, Feb 9, 2015 5:33 PM



On 2/9/2015 5:03 PM, John Bradley wrote:
> OK, I don't know if the WG has discussed the issue of fragments in browse=
r history.
>
> So you are trading off several round trips against the possibility of a t=
oken leaking in browser history or bookmark?
>

Yes, bookmarking tokens is a little scary, IMO, as we've already run
into users bookmarking URLs with codes in them.

Also, wasn't there additional security vulnerabilities surrounding
implicit flow?  Maybe these were just the product of incorrect
implementations, I don't remember, it was a while ago.

> One extension that Connect introduced was a "code id_token" response type=
 that is fragment encoded.  That would let you pass the code directly to th=
e JS saving two legs.
>

It looks like OIDC added a "response_mode" parameter where you can
specify "query" or "fragment".  Thanks for pointing this out!


Thanks for all the help.


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

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

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















Hi Bill,







I'm not sure if I have permission to post to the OAuth list. Anyway, i=
f your page that does the OAuth processing includes third party scripts, th=
en those scripts will probably have access to the code, client secret, and =
access token. I believe this concern
 is addressed in the security section of RFC 6749.







E. Anwar Reddick


Research Scientist


Georgia Tech Research Institute




----- Reply message -----

From: "Bill Burke" <bburke@redhat.com>

To: "John Bradley" <ve7jtb@ve7jtb.com>

Cc: "oauth@ietf.org" <oauth@ietf.org>

Subject: [OAUTH-WG] Confusion on Implicit Grant flow

Date: Mon, Feb 9, 2015 5:33 PM













On 2/9/2015 5:03 PM, John Bradley wrote:

> OK, I don't know if the WG has discussed the issue of fragments in bro=
wser history.

>

> So you are trading off several round trips against the possibility of =
a token leaking in browser history or bookmark?

>



Yes, bookmarking tokens is a little scary, IMO, as we've already run 

into users bookmarking URLs with codes in them.



Also, wasn't there additional security vulnerabilities surrounding 

implicit flow?  Maybe these were just the product of incorrect 

implementations, I don't remember, it was a while ago.



> One extension that Connect introduced was a "code id_token" =
response type that is fragment encoded.  That would let you pass the c=
ode directly to the JS saving two legs.

>



It looks like OIDC added a "response_mode" parameter where you ca=
n 

specify "query" or "fragment".  Thanks for pointin=
g this out!





Thanks for all the help.





-- 

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth







--_000_e293564ad29d42bfab7e521afbd20a83APATLISDMAIL02coregtrio_--


From nobody Mon Feb  9 15:01:09 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921191A8A13; Mon,  9 Feb 2015 14:46:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvGb66NicZez; Mon,  9 Feb 2015 14:46:46 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E52E11A8A52; Mon,  9 Feb 2015 14:46:44 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150209224644.19408.92346.idtracker@ietfa.amsl.com>
Date: Mon, 09 Feb 2015 14:46:44 -0800
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Feb 2015 22:46:47 -0000

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

        Title           : OAuth 2.0 Token Introspection
        Author          : Justin Richer
	Filename        : draft-ietf-oauth-introspection-05.txt
	Pages           : 13
	Date            : 2015-02-09

Abstract:
   This specification defines a method for a protected resource to query
   an OAuth 2.0 authorization server to determine the active state of an
   OAuth 2.0 token and to determine meta-information about this token.
   OAuth 2.0 deployments can use this method to convey information about
   the authorization context of the token from the authorization server
   to the protected resource.



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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-introspection-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-05


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

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


From nobody Mon Feb  9 15:05:20 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BA11A8A25; Mon,  9 Feb 2015 14:47:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJsEFWpCAO0X; Mon,  9 Feb 2015 14:47:32 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 306E21A8A73; Mon,  9 Feb 2015 14:47:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150209224718.17694.31238.idtracker@ietfa.amsl.com>
Date: Mon, 09 Feb 2015 14:47:18 -0800
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-23.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Feb 2015 22:47:34 -0000

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

        Title           : OAuth 2.0 Dynamic Client Registration Protocol
        Authors         : Justin Richer
                          Michael B. Jones
                          John Bradley
                          Maciej Machulak
                          Phil Hunt
	Filename        : draft-ietf-oauth-dyn-reg-23.txt
	Pages           : 38
	Date            : 2015-02-09

Abstract:
   This specification defines mechanisms for dynamically registering
   OAuth 2.0 clients with authorization servers.  Registration requests
   send a set of desired client metadata values to the authorization
   server.  The resulting registration responses return a client
   identifier to use at the authorization server and the client metadata
   values registered for the client.  The client can then use this
   registration information to communicate with the authorization server
   using the OAuth 2.0 protocol.  This specification also defines a set
   of common client metadata fields and values for clients to use during
   registration.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-23

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-23


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

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


From nobody Mon Feb  9 15:06:56 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FF21A8A7B; Mon,  9 Feb 2015 14:47:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lObR98BvEZxX; Mon,  9 Feb 2015 14:47:41 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFAE1A8A61; Mon,  9 Feb 2015 14:47:30 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150209224730.16371.41799.idtracker@ietfa.amsl.com>
Date: Mon, 09 Feb 2015 14:47:30 -0800
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-09.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Feb 2015 22:47:43 -0000

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

        Title           : OAuth 2.0 Dynamic Client Registration Management Protocol
        Authors         : Justin Richer
                          Michael B. Jones
                          John Bradley
                          Maciej Machulak
	Filename        : draft-ietf-oauth-dyn-reg-management-09.txt
	Pages           : 17
	Date            : 2015-02-09

Abstract:
   This specification defines methods for management of dynamic OAuth
   2.0 client registrations for use cases in which the properties of a
   registered client may need to be changed during the lifetime of the
   client.  Not all authorization servers supporting dynamic client
   registration will support these management methods.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-09


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

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


From nobody Mon Feb  9 15:11:27 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764821A8A6A for ; Mon,  9 Feb 2015 14:50:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level: 
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSpdo94RMfhk for ; Mon,  9 Feb 2015 14:50:33 -0800 (PST)
Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id D34851A8A13 for ; Mon,  9 Feb 2015 14:50:32 -0800 (PST)
Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6BFFF42E092 for ; Mon,  9 Feb 2015 17:50:32 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 657B442E072 for ; Mon,  9 Feb 2015 17:50:32 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.185]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0224.002; Mon, 9 Feb 2015 17:50:32 -0500
From: "Richer, Justin P." 
To: "" 
Thread-Topic: New Draft Versions
Thread-Index: AQHQRLrOR2mwGtXjxkeApEc6WoDNAg==
Date: Mon, 9 Feb 2015 22:50:31 +0000
Message-ID: <81277BAD-0A2B-4CD2-94BA-8620CDEE9003@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.16.55]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [OAUTH-WG] New Draft Versions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Feb 2015 22:50:35 -0000

I've just posted draft updates to the Introspection, Dynamic Registration, =
and Dynamic Registration Management drafts in order to update my associated=
 email address and organization. The introspection update also contains a c=
ouple of typo fixes (thanks to those who found them!).

No other changes have been made.

 -- Justin=


From nobody Mon Feb  9 15:28:15 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435C81A8A67 for ; Mon,  9 Feb 2015 14:59:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5icDTZ-WerhC for ; Mon,  9 Feb 2015 14:59:10 -0800 (PST)
Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C051A8940 for ; Mon,  9 Feb 2015 14:59:09 -0800 (PST)
Received: by mail-qc0-f177.google.com with SMTP id m20so11595710qcx.8 for ; Mon, 09 Feb 2015 14:59:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=/BaTIo9NHTOMzjH6YyVONxfhwZZ1D16r/o0wgz9hPkw=; b=LtqthMJluhbDyui2HjvBXA9FEdlon2qh19oztV6sa/sJ6ViAE07FO/tTElg9KroS+X tiL84thxMkLeLTLdxd9yO52+pnBIZkmxdYcItZusjqxXAeCMaVzOg73hm9511rxYZFHW PogJ3OEjjxoWIb687zCwuz4669TVjGElAt90+2Pcf+psmhPntPwsO7F4mvb5FFflbWGT cr2uVLIkq+GSns3TxIhL1U3l7drzRog2PfXLgwCkZLZkRPBCKWY0j3EgJT4wEcWldGSK A8JyY1WOAsSHtUYKrOGnOTGQYA7dfa+n8mL/2FKoLSqjiUK68QZJuQZe9pVg1/nCjMJ0 w31Q==
X-Gm-Message-State: ALoCoQkx6+Zkh98U2Wr6xKQWcd9XftD6+Qs8DRyAv8ERXVVopHNVybhLOzvxNK4uD/A3pgzEKYaQ
X-Received: by 10.140.106.228 with SMTP id e91mr43847019qgf.19.1423522748952;  Mon, 09 Feb 2015 14:59:08 -0800 (PST)
Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id 34sm13246429qgh.28.2015.02.09.14.59.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Feb 2015 14:59:08 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_B98BFEE9-5417-4824-BFF1-3C5CFA4CADFF"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: <54D93578.9050105@redhat.com>
Date: Mon, 9 Feb 2015 19:59:04 -0300
Message-Id: <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com>
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D92A3C.4060106@redhat.com> <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com> <54D93578.9050105@redhat.com>
To: Bill Burke 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Feb 2015 22:59:12 -0000

--Apple-Mail=_B98BFEE9-5417-4824-BFF1-3C5CFA4CADFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

The security problem was people only doing host name matching on =
redirect_uri and attackers finding redirectors to use.   That impacted =
all public clients not just implicit. =20
Implicit took most of the heat because that was what Facebook was using, =
and they had the largest issue.

Connect has a response_mode that allows the response to be form encoded =
rather than fragment. =20
I read RFC 5849 as only allowing code to be query encoded.   The =
response_mode was intended for the new response types we defined in =
http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

The spec for response mode is here =
http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html

We haven't done anything with it recently.  I don't know if the OAuth WG =
wants to take it up.

John B.
> On Feb 9, 2015, at 7:32 PM, Bill Burke  wrote:
>=20
>=20
>=20
> On 2/9/2015 5:03 PM, John Bradley wrote:
>> OK, I don't know if the WG has discussed the issue of fragments in =
browser history.
>>=20
>> So you are trading off several round trips against the possibility of =
a token leaking in browser history or bookmark?
>>=20
>=20
> Yes, bookmarking tokens is a little scary, IMO, as we've already run =
into users bookmarking URLs with codes in them.
>=20
> Also, wasn't there additional security vulnerabilities surrounding =
implicit flow?  Maybe these were just the product of incorrect =
implementations, I don't remember, it was a while ago.
>=20
>> One extension that Connect introduced was a "code id_token" response =
type that is fragment encoded.  That would let you pass the code =
directly to the JS saving two legs.
>>=20
>=20
> It looks like OIDC added a "response_mode" parameter where you can =
specify "query" or "fragment".  Thanks for pointing this out!
>=20
>=20
> Thanks for all the help.
>=20
>=20
> --=20
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com


--Apple-Mail=_B98BFEE9-5417-4824-BFF1-3C5CFA4CADFF
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMDkyMjU5MDRaMCMGCSqGSIb3DQEJBDEWBBTjzmIGCN74FuLdqiDlJAoT
KC9BMDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQA7aetc+Mehh4QRA8+mv/diJyos/Ewl4KvCz7ydXG2OlGQ7cX1kIqBf
LQWRnDQjZ+n2QuDrSWgx8bdlcDzE4CZWr7hZ8wbgGZPIge0CSNBvjyjZ4QuNdW1qanJEYHIqjYdc
fSLDGi7PZ4IyHUu7eRvHiExYcdToLtuznoFMRcY10XXFZMhuYg6fnhwRohDNnQWTyiC8jaKxEExA
OAci7xrF+1UiqAwguA1qoSeySzIcTYOpF6AHHqgAgKa8wpm/3Od9PvCBvlElxFCqDYZC8s67NkzI
YUvvVgYVYx4EvNYSlNWhsG0viqptdJT5O/MrLLo8DkYE2WIdGVBq7Zi618/WAAAAAAAA
--Apple-Mail=_B98BFEE9-5417-4824-BFF1-3C5CFA4CADFF--


From nobody Tue Feb 10 02:17:09 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DA81A6F3C for ; Tue, 10 Feb 2015 02:17:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ILbmrn_lG8L for ; Tue, 10 Feb 2015 02:16:57 -0800 (PST)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4474B1A1B98 for ; Tue, 10 Feb 2015 02:16:48 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id l2so6263445wgh.9 for ; Tue, 10 Feb 2015 02:16:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KLWtN99hLck7GgDmmhGnwmiIfWx1CXAStcwHi2IecSM=; b=zESXPpeQAHB84VmZozspMU5ogMqXAWOXyXugEXcoYVSIYV5Ob3idxc6HfbXtb8yZke qJDMNVDFDSKHfvBJIA9CLx9HbRKeXDDIjY1lA+dsbHCmEVxch18lnsYbR+Gm1N8Ll9AN eISlBQ2sT00McxWeI/Q44ptVlNx06Wjh0Fcn1uGMrAQnFWzrS3VaGkMdlnl4cJrbre/3 3Jl07w9Ghr262zdF5cEAFOWFdFjIK+sxkxPzCPSb+mHmTERbq2fJ7TgGUqz4UeykoUIc 0yf+ax7xiUOKw6Rrw4+VUYzFj8jIn1BQmVrnNB2exmgzkFIq9izxTFXETIBfoxEOHNFK +hmQ==
X-Received: by 10.194.173.138 with SMTP id bk10mr49116695wjc.112.1423563406941;  Tue, 10 Feb 2015 02:16:46 -0800 (PST)
Received: from [192.168.2.7] ([79.97.121.237]) by mx.google.com with ESMTPSA id hz9sm20088567wjb.17.2015.02.10.02.16.46 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Feb 2015 02:16:46 -0800 (PST)
Message-ID: <54D9DA7E.8010606@gmail.com>
Date: Tue, 10 Feb 2015 10:16:30 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: oauth@ietf.org
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D92A3C.4060106@redhat.com> <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com> <54D93578.9050105@redhat.com> <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com>
In-Reply-To: <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Feb 2015 10:17:05 -0000

Hi John
On 09/02/15 22:59, John Bradley wrote:
> The security problem was people only doing host name matching on redirect_uri and attackers finding redirectors to use.   That impacted all public clients not just implicit.
> Implicit took most of the heat because that was what Facebook was using, and they had the largest issue.
>
> Connect has a response_mode that allows the response to be form encoded rather than fragment.
> I read RFC 5849 as only allowing code to be query encoded.   The response_mode was intended for the new response types we defined in http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>
> The spec for response mode is here http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>
> We haven't done anything with it recently.  I don't know if the OAuth WG wants to take it up.
>
What is your opinion on providing a feature 'symmetric' to the one where 
a signed and/or encrypted code request is passed to AS ? The feature 
would return a signed and/or encrypted code in the redirect URI as usual.

I'm not sure it would help the implicit clients though...Unless the 
encryption key can be derived from a combination of the client_id and 
some extra piece of information encoded in the JS script but also known 
to AS (via the registration, etc)

Thanks, Sergey




> John B.
>> On Feb 9, 2015, at 7:32 PM, Bill Burke  wrote:
>>
>>
>>
>> On 2/9/2015 5:03 PM, John Bradley wrote:
>>> OK, I don't know if the WG has discussed the issue of fragments in browser history.
>>>
>>> So you are trading off several round trips against the possibility of a token leaking in browser history or bookmark?
>>>
>>
>> Yes, bookmarking tokens is a little scary, IMO, as we've already run into users bookmarking URLs with codes in them.
>>
>> Also, wasn't there additional security vulnerabilities surrounding implicit flow?  Maybe these were just the product of incorrect implementations, I don't remember, it was a while ago.
>>
>>> One extension that Connect introduced was a "code id_token" response type that is fragment encoded.  That would let you pass the code directly to the JS saving two legs.
>>>
>>
>> It looks like OIDC added a "response_mode" parameter where you can specify "query" or "fragment".  Thanks for pointing this out!
>>
>>
>> Thanks for all the help.
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


From nobody Tue Feb 10 04:08:06 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECC11A019B for ; Tue, 10 Feb 2015 04:07:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level: 
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBIT4oAY0FeE for ; Tue, 10 Feb 2015 04:07:28 -0800 (PST)
Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697C61A01AE for ; Tue, 10 Feb 2015 04:07:18 -0800 (PST)
Received: from mail-ig0-f173.google.com ([209.85.213.173]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKVNn0bS2sVDkGCdLnlLA7LwTdNXc1rykI@postini.com; Tue, 10 Feb 2015 04:07:18 PST
Received: by mail-ig0-f173.google.com with SMTP id a13so23099404igq.0 for ; Tue, 10 Feb 2015 04:07:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4I3rPIpRfb/Ac6QqPXGp9OKgIPCzvkyU8+GbatI+2X4=; b=JdGnMyEScL/pDAplV13HnYgrNYGdcJJtS8ZWucm7+grPbJr/X6rhYdcDVN2jF0RM1c wzStFXBCHPjSlDGDqGscQmdmU/bvyKDWPFs/YPW7xr55Yt7y+LifYtbwWuRJujQQ8R0S B2L7PbItovP8Jf7l3XnxphdKD8wzlboHrriCTq9vcSVdbADpxxioPUTig61pYo45Gfxp DwC9eZ2Er56H40TvY1ho2XnDvEwDMw7X+c48sF3hZ2/0gSAIP/wmLzyyMfiyb4dDF0IJ ITn7bD/CTkI2dJE4aYaROWEz2eEnunF8cKE896msFN7BtziroCQxdvN36GQgHUsNMD9C SCuA==
X-Gm-Message-State: ALoCoQnwHnzn7je52rvBUVsdROWyKV1heWgTHpKE8MSLtJhPuQQruv551KtV6bpsCzp8QFy87ySF9D7VA+sEw2x2LUEOmWihK36cmG257BaECSznw2fX9TO5l6Uc7r/JNWmG2mZRA7jL
X-Received: by 10.43.67.3 with SMTP id xs3mr30005121icb.39.1423570029539; Tue, 10 Feb 2015 04:07:09 -0800 (PST)
X-Received: by 10.43.67.3 with SMTP id xs3mr30005109icb.39.1423570029402; Tue, 10 Feb 2015 04:07:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.33.75 with HTTP; Tue, 10 Feb 2015 04:06:39 -0800 (PST)
In-Reply-To: <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com>
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D92A3C.4060106@redhat.com> <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com> <54D93578.9050105@redhat.com> <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com>
From: Brian Campbell 
Date: Tue, 10 Feb 2015 05:06:39 -0700
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001a11c2162eea7676050ebab9e2
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Feb 2015 12:07:42 -0000

--001a11c2162eea7676050ebab9e2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 9, 2015 at 3:59 PM, John Bradley  wrote:

> Connect has a response_mode that allows the response to be form encoded
> rather than fragment.
> I read RFC 5849 as only allowing code to be query encoded.   The
> response_mode was intended for the new response types we defined in
> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>

Actually response_mode is defined in that spec itself in section 2.1
.



>
> The spec for response mode is here
> http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>

And that spec is actually to define a new response mode, form_post, which
encodes authorization response parameters as HTML form values that are
auto-submitted (via javascript) by the user agent and transmitted via HTTP
POST to the Client=E2=80=99s redirect URI.

--001a11c2162eea7676050ebab9e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Feb 9, 2015 at 3:59 PM, John Bradley <ve7jtb@ve7jtb.com>=
; wrote:

Connect has a response_mode that allows the response to be form encoded rat=
her than fragment.

I read RFC 5849 as only allowing code to be query encoded.=C2=A0 =C2=A0The =
response_mode was intended for the new response types we defined in http://openid.net/specs/oauth-v2-multiple-response-types-1_0.=
html

Actually response_mode is defi=
ned in that spec itself in section 2.1. 
=C2=A0



The spec for response mode is here http://openid.net/s=
pecs/oauth-v2-form-post-response-mode-1_0.html
And that spec is actually to define a new response mode, form_p=
ost, which encodes authorization response parameters as HTML form values th=
at are auto-submitted (via javascript) by the user agent and transmitted vi=
a HTTP POST to the Client=E2=80=99s redirect URI.


--001a11c2162eea7676050ebab9e2--


From nobody Tue Feb 10 05:15:34 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E19C1A0204 for ; Tue, 10 Feb 2015 05:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJDKYxF1fOdf for ; Tue, 10 Feb 2015 05:15:17 -0800 (PST)
Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0FB1A01F2 for ; Tue, 10 Feb 2015 05:15:14 -0800 (PST)
Received: by mail-qc0-f175.google.com with SMTP id c9so28333802qcz.6 for ; Tue, 10 Feb 2015 05:15:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=q5Y7Xv4GbiL3DFMjbn3J9BSA7kpNscpQdIAKuLaTaFg=; b=k6o14vmw9AQZnqEMlkzfBgKU86JskYA82wwNXL5yNhG7zppjNnIlRqUZfPj0cZj3WR AN3JhlCMxpcP/Re3LnQqQetiw5TZS3x3WlWt68FY6jTjYkoJUT8bCFRmBn9xKwDse+sw U+iTKZWV43tIhaA52q8mglWAqyrMrpp8bo/2JKApElXM2SJpTmLZIBakfHFejKvLSFM4 EmI0rkHma1SHuKuB1PpEAhQpzSzNf85nyAuZM34/3Le2rYedPHaFpfKLxjRsfI0LAr8F x2ff9qkEqmpondVL5j+Mi1p+w8NG5Ub+zSsUJLc4y5PU3pQsHmdU3iUuEKQUlLqeqXjK Ktew==
X-Gm-Message-State: ALoCoQkH1Po6Wy+5w1lu8zPevS5oh/VOnc96fqqgeuvRs4QMYfEIdFXd9EMa5QrkQ65bu0Nb4EiO
X-Received: by 10.224.75.7 with SMTP id w7mr53384055qaj.6.1423574113927; Tue, 10 Feb 2015 05:15:13 -0800 (PST)
Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id 34sm15135241qgh.28.2015.02.10.05.15.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Feb 2015 05:15:13 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_54AB1EF1-7196-4781-BE3E-49FF6DB4E503"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: <54D9DA7E.8010606@gmail.com>
Date: Tue, 10 Feb 2015 10:15:08 -0300
Message-Id: 
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D92A3C.4060106@redhat.com> <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com> <54D93578.9050105@redhat.com> <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com> <54D9DA7E.8010606@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Feb 2015 13:15:30 -0000

--Apple-Mail=_54AB1EF1-7196-4781-BE3E-49FF6DB4E503
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The issue is maintaining key material in the browser.

Web Crypto will help with that , but is not deployed widely in browsers =
at the moment.

Thinking about it a bit someone could make a more secure flow for JS =
clients using code and some Connect extensions now.

If I were concerned about logging the AT, then I would have the JS make =
a CORS call to the authorization endpoint with:
response_type=3Dcode+id_token              =
[http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html]
code_challenge=3D(challenge value)        [ =
https://tools.ietf.org/html/draft-ietf-oauth-spop-02]
code_challenge_method=3DS256

The response is fragment encoded,  and the id_token contains a detached =
sig of code for the JS to verify along with the client as the "aud" =
signed with RSA key of the AS as the default.
The JS would be the callback URI and extract the code and id_tokens

The JS then makes a CORS call to the token_endpoint sending
code_verifier=3D(verifier value)

Code could be logged but wouldn't be usable without knowing the =
code_verifier.
This effectively turns the JS into a semi confidential client.   =20

We have been looking at PKCE/SPOP for native apps, but nothing would =
stop it from working with JS clients.

In Connect the JS client crates a nonce value and sends that with the =
request.  That value comes back in the signed_id token allowing the JS =
to know that the code and id_token are in reply to it's request and not =
replayed from another session.

I think using token binding to associate the JS clients TLS key to the =
AT so that it cannot be replayed from a different browser is the best =
option over the longer term.
That provides the best protection from plugins and scripts extracting =
the AT from the running JS.

John B.

> On Feb 10, 2015, at 7:16 AM, Sergey Beryozkin  =
wrote:
>=20
> Hi John
> On 09/02/15 22:59, John Bradley wrote:
>> The security problem was people only doing host name matching on =
redirect_uri and attackers finding redirectors to use.   That impacted =
all public clients not just implicit.
>> Implicit took most of the heat because that was what Facebook was =
using, and they had the largest issue.
>>=20
>> Connect has a response_mode that allows the response to be form =
encoded rather than fragment.
>> I read RFC 5849 as only allowing code to be query encoded.   The =
response_mode was intended for the new response types we defined in =
http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>>=20
>> The spec for response mode is here =
http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>=20
>> We haven't done anything with it recently.  I don't know if the OAuth =
WG wants to take it up.
>>=20
> What is your opinion on providing a feature 'symmetric' to the one =
where a signed and/or encrypted code request is passed to AS ? The =
feature would return a signed and/or encrypted code in the redirect URI =
as usual.
>=20
> I'm not sure it would help the implicit clients though...Unless the =
encryption key can be derived from a combination of the client_id and =
some extra piece of information encoded in the JS script but also known =
to AS (via the registration, etc)
>=20
> Thanks, Sergey
>=20
>=20
>=20
>=20
>> John B.
>>> On Feb 9, 2015, at 7:32 PM, Bill Burke  wrote:
>>>=20
>>>=20
>>>=20
>>> On 2/9/2015 5:03 PM, John Bradley wrote:
>>>> OK, I don't know if the WG has discussed the issue of fragments in =
browser history.
>>>>=20
>>>> So you are trading off several round trips against the possibility =
of a token leaking in browser history or bookmark?
>>>>=20
>>>=20
>>> Yes, bookmarking tokens is a little scary, IMO, as we've already run =
into users bookmarking URLs with codes in them.
>>>=20
>>> Also, wasn't there additional security vulnerabilities surrounding =
implicit flow?  Maybe these were just the product of incorrect =
implementations, I don't remember, it was a while ago.
>>>=20
>>>> One extension that Connect introduced was a "code id_token" =
response type that is fragment encoded.  That would let you pass the =
code directly to the JS saving two legs.
>>>>=20
>>>=20
>>> It looks like OIDC added a "response_mode" parameter where you can =
specify "query" or "fragment".  Thanks for pointing this out!
>>>=20
>>>=20
>>> Thanks for all the help.
>>>=20
>>>=20
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_54AB1EF1-7196-4781-BE3E-49FF6DB4E503
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMTAxMzE1MDlaMCMGCSqGSIb3DQEJBDEWBBSs5HLGGa5fFqbM+xBTTWT2
74RQZTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCyiVQ5RGwHolaTlrNYNgk7DwGNM2CpD79bOa5f/Gkqy1UgBjwIBVA/
kt4NvB6y3KpBXfTcjvwk8G8f7lA+h4/2/lRK0fhS1b6brw5pGmk+KEjUd9kmUNHTW9mXXlRik4Qb
zwT2EfMb2su/rWN6LbkIvAT3hHF/LUT70JGjNfBJ1iBDK41mxAHI91qPx5B4gyGtAOoAt2sefe56
/2t1rkb3pMninpO+4DASkUaDFFlVe/Mg4tAAmJnkrULfOmGG6BVA2OL0zFin1oGEozv9ZkycitHv
nFIm9CI9ll2k5dmHlHZQ4Dbiqo4gcYMWj5zQh3e/gw1HfV+QlsRBJxXCy1FHAAAAAAAA
--Apple-Mail=_54AB1EF1-7196-4781-BE3E-49FF6DB4E503--


From nobody Tue Feb 10 05:35:35 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAE91A026F for ; Tue, 10 Feb 2015 05:35:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M8E69JsmN-K for ; Tue, 10 Feb 2015 05:35:25 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E00A1A0277 for ; Tue, 10 Feb 2015 05:35:07 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1ADZ6uX032072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 10 Feb 2015 08:35:06 -0500
Received: from [10.10.58.35] (vpn-58-35.rdu2.redhat.com [10.10.58.35]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1ADZ4fn027570; Tue, 10 Feb 2015 08:35:05 -0500
Message-ID: <54DA090B.1010107@redhat.com>
Date: Tue, 10 Feb 2015 08:35:07 -0500
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Brian Campbell , John Bradley 
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D92A3C.4060106@redhat.com> <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com> <54D93578.9050105@redhat.com> <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Feb 2015 13:35:32 -0000

On 2/10/2015 7:06 AM, Brian Campbell wrote:
>
>
> On Mon, Feb 9, 2015 at 3:59 PM, John Bradley  > wrote:
>
>     Connect has a response_mode that allows the response to be form
>     encoded rather than fragment.
>     I read RFC 5849 as only allowing code to be query encoded.   The
>     response_mode was intended for the new response types we defined in
>     http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>
>
> Actually response_mode is defined in that spec itself in section 2.1
> .
>

Yeah, and it looks like you can use it for anything.  It only defines 
default modes for various response types (code, token, etc.)

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Tue Feb 10 06:01:15 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538421A026E for ; Tue, 10 Feb 2015 06:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdGRIsJrPx0P for ; Tue, 10 Feb 2015 06:01:09 -0800 (PST)
Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C097B1A02F1 for ; Tue, 10 Feb 2015 06:01:08 -0800 (PST)
Received: by mail-qg0-f54.google.com with SMTP id z60so26236582qgd.13 for ; Tue, 10 Feb 2015 06:01:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8/LWdr3pfiBIflD/Vksg45CyF8xA8rqmY/kNi12VAsQ=; b=WcxcPfvRnA4Xg93ZON8tSgfrFfXllZACEP3T/VzQA5EE6pbAgqK/trDAtt5zQdvwHC /4pBJw+MMUOYXV7kSpPy41z7IxcwOUTyZGylbUNmrCSyxpTeLFQ3EmbFEWfeSOn7B0hm tagW/QEDQuUvJE+QHrcBqIp+kBPGcuIj2YVtujcZJfzQuc4ciep2NQ79fzVBh1TTRBVF eCsVOdqSjMhjXjKntldFmQKtViPjjKXl6g/AtQaF5+hOxBOX+aVh7NrnVQGPEMDkNTFy VSucq/YuI8WRy/YEr9tXaIm8eIAkwRwY1uya+kc95VaFlsTbhhk8X0jS/HEVbHt9zwB1 dLEA==
X-Gm-Message-State: ALoCoQlsxCRU6j2g5TNQJmHDxMfCkP/cq0vTxzacSpREPFQY103khqYmd1qcW+MzRvM+pGTOcH9W
X-Received: by 10.224.127.6 with SMTP id e6mr41265480qas.42.1423576866960; Tue, 10 Feb 2015 06:01:06 -0800 (PST)
Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id l93sm15266195qgd.23.2015.02.10.06.01.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Feb 2015 06:01:06 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_FE77C8A0-2E9F-4F91-995A-DDAB8E3CC2D7"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: <54DA090B.1010107@redhat.com>
Date: Tue, 10 Feb 2015 11:00:59 -0300
Message-Id: 
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D92A3C.4060106@redhat.com> <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com> <54D93578.9050105@redhat.com> <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com>  <54DA090B.1010107@redhat.com>
To: Bill Burke 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Feb 2015 14:01:13 -0000

--Apple-Mail=_FE77C8A0-2E9F-4F91-995A-DDAB8E3CC2D7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The code and implicit response_type are defined in RFC 6749. =20
https://tools.ietf.org/html/rfc6749#section-4.1.2
https://tools.ietf.org/html/rfc6749#section-4.2.2

It describes one way to encode the response in each case with no mention =
of that being extended.   In the text there is no normative MUST.

I personally think changing the encoding of code via response_mode might =
be a technical violation of RFC 6749,  it will defiantly cause interop =
problems.

The multiple response type spec restates the defaults from RFC 6749, but =
doesn't explicitly say that you can change them with response_mode.

In Connect we were careful not to override anything in RFC 6749.

In your deployment using response_mode with code might work perfectly =
fine. =20
Interop problems by implementations not expecting response_mode with the =
code response_type are the only real concern.

John B.


> On Feb 10, 2015, at 10:35 AM, Bill Burke  wrote:
>=20
>=20
>=20
> On 2/10/2015 7:06 AM, Brian Campbell wrote:
>>=20
>>=20
>> On Mon, Feb 9, 2015 at 3:59 PM, John Bradley > > wrote:
>>=20
>>    Connect has a response_mode that allows the response to be form
>>    encoded rather than fragment.
>>    I read RFC 5849 as only allowing code to be query encoded.   The
>>    response_mode was intended for the new response types we defined =
in
>>    http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>>=20
>>=20
>> Actually response_mode is defined in that spec itself in section 2.1
>> =
.
>>=20
>=20
> Yeah, and it looks like you can use it for anything.  It only defines =
default modes for various response types (code, token, etc.)
>=20
> --=20
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com


--Apple-Mail=_FE77C8A0-2E9F-4F91-995A-DDAB8E3CC2D7
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMTAxNDAwNjBaMCMGCSqGSIb3DQEJBDEWBBT2Tg5BM/UbbfgaL4qNhqPD
THF0tjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBARVKItjzu7RPGg3ML9c2GPEr+l4AGnDgPGSm/5WTmw852G1Tu8oXM
97RtCw64TrrgxEY0MBlVOTge5xc0F/9sEOwdhTm6iKn2tj/IMzUqPricqvVhdv0EIyqyuF6SfKIh
sIW2tXC7SNg8CCkG+GN8BiSVQ5O1SxOLYZMbwOKbCAY+G+cbFWLezYlS2ijfFAWvfC3i84fJhiWx
2qpdcLkB9ubbXgAkXp6YVHYbbo+ALeMNDpLrqLQOArSMCDDZtNYo0splqBNVeqbOpPgEOVZMZD0y
9VB6kYoQVvKaMb9vMxBEjrgEmkbdtPpvxjvQg2cIBo10ElnvmwU8gSshnNXOAAAAAAAA
--Apple-Mail=_FE77C8A0-2E9F-4F91-995A-DDAB8E3CC2D7--


From nobody Tue Feb 10 06:27:28 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA65B1A0270 for ; Tue, 10 Feb 2015 06:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zPAAaNvkKfO for ; Tue, 10 Feb 2015 06:27:23 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7B21A0267 for ; Tue, 10 Feb 2015 06:27:23 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1AERMK4023136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 10 Feb 2015 09:27:22 -0500
Received: from [10.10.58.35] (vpn-58-35.rdu2.redhat.com [10.10.58.35]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1AERMYW022475 for ; Tue, 10 Feb 2015 09:27:22 -0500
Message-ID: <54DA154C.2070700@redhat.com>
Date: Tue, 10 Feb 2015 09:27:24 -0500
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: oauth@ietf.org
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D92A3C.4060106@redhat.com> <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com> <54D93578.9050105@redhat.com> <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com> <54D9DA7E.8010606@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: 
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Feb 2015 14:27:25 -0000

On 2/10/2015 8:15 AM, John Bradley wrote:
> The issue is maintaining key material in the browser.
>
> Web Crypto will help with that , but is not deployed widely in browsers at the moment.
>
> Thinking about it a bit someone could make a more secure flow for JS clients using code and some Connect extensions now.
>
> If I were concerned about logging the AT, then I would have the JS make a CORS call to the authorization endpoint with:
> response_type=code+id_token              [http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html]
> code_challenge=(challenge value)        [ https://tools.ietf.org/html/draft-ietf-oauth-spop-02]
> code_challenge_method=S256
>

Excellent.  Thanks.


> In Connect the JS client crates a nonce value and sends that with the request.  That value comes back in the signed_id token allowing the JS to know that the code and id_token are in reply to it's request and not replayed from another session.
>

Why would you need the nonce if the IDP guarantees that the code can 
only be used once?  The code, state, and redirect-uri are all validated 
by the IDP with the access token request.

Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Tue Feb 10 06:50:23 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F37F1A8A92 for ; Tue, 10 Feb 2015 06:50:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TtbCplNSHsN for ; Tue, 10 Feb 2015 06:50:13 -0800 (PST)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557161A7013 for ; Tue, 10 Feb 2015 06:49:39 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id x3so28696299qcv.3 for ; Tue, 10 Feb 2015 06:49:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=6BmIbcN8rUdeHCz0V9qDdetM0Y5JmhWcbRfXmVKi+A8=; b=V8p5ndT9QtRpU55ZlvjI0h5JTYgIyDAy2QZ8g1Tws1T5PLC3Pm8tFzfLCDwK/4Hba3 3ltPIMk49J7avR0gEvmltxcRPlurVJ1I8Hr2kVCl4bujOLaetXj6KImO3MjqCl7dfrv+ mc0WUtKZzzV8iAZXHOIjPDe8uy/b/mCIyI/rC894QCRmMhylzIEjGFrLfMsEsZE2uNEX IZcJf8JqOjA8dA8D+liBUwR8mPF30NZvnc+33iQ10ElaP/1eIXCkjUDlI/NywTeBdJuH JirzfcN0oSKIl6lSSOhYHyYfRvpdkg5Jxs8s0Z7tPXEnYTLZ6KD8W8Mm2qMiEH88Ld+y JgOg==
X-Gm-Message-State: ALoCoQkrHZse2Oan+ODGBju9w3FCI1fN8wYlRv/Gwjbu0bcZokg+ewR/qf3o3oe/0H87bNQVW+m1
X-Received: by 10.229.102.68 with SMTP id f4mr54209695qco.15.1423579778347; Tue, 10 Feb 2015 06:49:38 -0800 (PST)
Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id z7sm7108846qah.30.2015.02.10.06.49.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Feb 2015 06:49:37 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_959A1F42-CDE2-4EF6-AC9A-BF94DE2956C8"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: <54DA154C.2070700@redhat.com>
Date: Tue, 10 Feb 2015 11:49:33 -0300
Message-Id: <9F3B04D0-3BE6-4AFD-ADA0-91137B023864@ve7jtb.com>
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D92A3C.4060106@redhat.com> <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com> <54D93578.9050105@redhat.com> <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com> <54D9DA7E.8010606@gmail.com>  <54DA154C.2070700@redhat.com>
To: Bill Burke 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Feb 2015 14:50:19 -0000

--Apple-Mail=_959A1F42-CDE2-4EF6-AC9A-BF94DE2956C8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The nonce allows the client to insert a unique value into the id_token  =
to associate it with a particular browser session(Think SAML RequstID).  =
=20
That is useful for web server based clients.  It may or may not be =
useful in the JS case, as the client is the browser.

While code can only be used once, that doesn't stop someone from  =
intercepting a code/id_token from one session and replaying it in a =
different one to the same client.  =20

In the JS client case that would require a man in the middle between the =
browser and the AS, so is much harder for an attacker than the case =
where the client is a web server.

Using the PKCE code_challenge also lets the client detect if some =
substitution of the code has happened.

John B.
> On Feb 10, 2015, at 11:27 AM, Bill Burke  wrote:
>=20
>=20
>=20
> On 2/10/2015 8:15 AM, John Bradley wrote:
>> The issue is maintaining key material in the browser.
>>=20
>> Web Crypto will help with that , but is not deployed widely in =
browsers at the moment.
>>=20
>> Thinking about it a bit someone could make a more secure flow for JS =
clients using code and some Connect extensions now.
>>=20
>> If I were concerned about logging the AT, then I would have the JS =
make a CORS call to the authorization endpoint with:
>> response_type=3Dcode+id_token              =
[http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html]
>> code_challenge=3D(challenge value)        [ =
https://tools.ietf.org/html/draft-ietf-oauth-spop-02]
>> code_challenge_method=3DS256
>>=20
>=20
> Excellent.  Thanks.
>=20
>=20
>> In Connect the JS client crates a nonce value and sends that with the =
request.  That value comes back in the signed_id token allowing the JS =
to know that the code and id_token are in reply to it's request and not =
replayed from another session.
>>=20
>=20
> Why would you need the nonce if the IDP guarantees that the code can =
only be used once?  The code, state, and redirect-uri are all validated =
by the IDP with the access token request.
>=20
> Bill
>=20
> --=20
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_959A1F42-CDE2-4EF6-AC9A-BF94DE2956C8
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMTAxNDQ5MzNaMCMGCSqGSIb3DQEJBDEWBBRnQyAb3SUFUPw8NRrGoVpM
Mq1tUjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCIfgqmBAzwhyS4iFMbcL/hyNEqTpmAxG2/NwPLDn3c9XGP/YyrL3pv
aCApeVBgkdSeOeCHtKZw/Nbj41q6FaFyAgBtAJBofimUxf7os7xRCi18uVvCTw2xU0Or6f00TBfv
lQW9DKlCQApaQL8csvsYEZrL9UQrdTS11mgb2NUT1ue4ZdBpKoKVbina04hd+q315Oc9VtiX1Lql
HwTEjuhyiyX5zSNOOGaPyD9qxq5+PhBKHXIUGjPvXOrURSnUSM0YvRqU3bHUeM7eoZsY7r57B3JE
QEws73lCgJ7pxRO+UVPekaGTlkLjvF56JWPo2tyUf4S6N4ekmnbs4CZCczvDAAAAAAAA
--Apple-Mail=_959A1F42-CDE2-4EF6-AC9A-BF94DE2956C8--


From nobody Tue Feb 10 08:13:36 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F2D1A1A38 for ; Tue, 10 Feb 2015 08:13:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.566
X-Spam-Level: 
X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT3XRZwfANDH for ; Tue, 10 Feb 2015 08:13:13 -0800 (PST)
Received: from mx0a-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7FF1A1A33 for ; Tue, 10 Feb 2015 08:12:48 -0800 (PST)
Received: from pps.filterd (m0074410.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.14.7/8.14.7) with SMTP id t1AGA9Em026065; Tue, 10 Feb 2015 10:12:48 -0600
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by mx0a-0019e102.pphosted.com with ESMTP id 1sfj8p0a1n-1 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NOT); Tue, 10 Feb 2015 10:12:47 -0600
Received: from BLUPR04MB691.namprd04.prod.outlook.com (10.141.205.149) by BLUPR04MB690.namprd04.prod.outlook.com (10.141.205.146) with Microsoft SMTP Server (TLS) id 15.1.81.19; Tue, 10 Feb 2015 16:12:44 +0000
Received: from BLUPR04MB691.namprd04.prod.outlook.com ([10.141.205.149]) by BLUPR04MB691.namprd04.prod.outlook.com ([10.141.205.149]) with mapi id 15.01.0081.018; Tue, 10 Feb 2015 16:12:44 +0000
From: Adam Lewis 
To: John Bradley , Prateek Mishra 
Thread-Topic: [OAUTH-WG] Confusion on Implicit Grant flow
Thread-Index: AdBCU7lczcAZFshKSMOM30KEynNz8AAAdauAAJOOJYAAAFyKAAABMZ+AAABwzQAAAKRcgAAAWbWAACbHsZA=
Date: Tue, 10 Feb 2015 16:12:44 +0000
Message-ID: 
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D924CB.6070504@oracle.com> <3B0DDA4D-F540-4E23-9842-275532F7405F@ve7jtb.com>
In-Reply-To: <3B0DDA4D-F540-4E23-9842-275532F7405F@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [150.130.34.131]
authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR04MB690;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR04MB690;
x-forefront-prvs: 048396AFA0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(479174004)(24454002)(76576001)(2656002)(587094005)(62966003)(87936001)(18717965001)(66066001)(77156002)(16601075003)(74316001)(93886004)(50986999)(40100003)(54356999)(33656002)(76176999)(77096005)(92566002)(102836002)(15975445007)(19300405004)(2950100001)(2900100001)(19617315012)(99286002)(86362001)(46102003)(19609705001)(19580395003)(19580405001)(16236675004)(19625215002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR04MB690; H:BLUPR04MB691.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_BLUPR04MB6914D0257B18CDBE1A9909395240BLUPR04MB691namprd_"
MIME-Version: 1.0
X-OriginatorOrg: motorolasolutions.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2015 16:12:44.5604 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 93f5baf9-414a-4f1b-88bc-33f3013923d7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR04MB690
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1502100154
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Feb 2015 16:13:20 -0000

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

Hi John,

What do you mean by the app that is "already loaded and cached in the brows=
er?"  Where did this app come from initially?  Is this what comes from the =
web-hosted client resource in step D/E of section 4.2?  So the first time D=
/E *will* flow over the wire, and in all subsequent requests it will be cac=
hed?

And with respect to the web hosted client resource, is this a resource depl=
oyed by the same domain as the RS to facilitate the deployment of user-agen=
t-based apps to access the APIs exposed by that RS?


adam

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Monday, February 09, 2015 3:31 PM
To: Prateek Mishra
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow

Typically the implicit callback JS is part of the application that is alrea=
dy loaded and cached in the browser.

The implicit flow doesn't depend on on the fragment not being re-appended t=
o the resource location URI in the 302.  It would admittedly be more secure=
 if that didn't happen.
Re-appending the fragment is the correct browser behaviour according to the=
 W3C.

I still think you are farther ahead with that than leaking the code in the =
referrer.

Implicit if done correctly has the token in one leg.  code on the other han=
d has the code in 4 legs and the token in one.

It is having the JS make the exchange of code for the AT without a secret t=
hat is the problem in my opinion.

If the client is a server that is doing the code -> token exchange then the=
 answer is different, but the question was for a JS only client.

John B.


On Feb 9, 2015, at 6:21 PM, Prateek Mishra > wrote:

The implicit flow depends upon a subtle and little known aspect of browser =
behavior - that the URI fragment component isn't propagated across redirect=
s.

I havent checked this recently - but I am aware that several folks have fou=
nd that some browser versions dont comply with this requirement.
http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-w=
ith-oauth-2

The additional round-trip issue is also unclear. The implicit flow requires=
 an additional redirect (round-trip) to retrieve JS which retrieves the acc=
ess token from the fragment URI.

How is that different from a HTTPs callback to exchange the access code for=
 the access token?

- prateek



You are passing code in a query parameter, and without a secret that is mor=
e likely to be leaked than sending token in the fragment directly from the =
authorization endpoint to the browser JS in a fragment.



You have several extra round trips for no security benefit.   In your case =
the code in the query parameter goes from the browser to the redirect endpo=
int then must be sent back to the browser, and then to the token endpoint.



So yes using code for that is less secure.



Both rely solely on the registered redirect URI for security, but implicit =
has fewer hopes and is more friendly to JS.



John B.

On Feb 9, 2015, at 5:50 PM, Bill Burke  wrote:



If you don't have a client secret, why is Javascript-based auth code grant =
flow more risky?  We also require SSL and valid redirect URI patterns to be=
 registered for the application.  The code can only ever be sent to specifi=
c URLs and can only be used once.  CORS origin validation is also an extra =
step we do to ensure a rogue javascript app isn't making any code-to-token =
requests.



I'm just trying to figure out if we missed anything...



On 2/9/2015 3:16 PM, John Bradley wrote:

If you don't have a client secret, or are storing the the client secret in =
the Javascrypt, then you are probably more at risk using code than implicit=
.



Implicit is risky because running a OAuth client in the browser is risky.  =
Using code in that case makes it no better, and arguably worse.



Perhaps I don't understand the environment.



John B.



On Feb 9, 2015, at 5:05 PM, Bill Burke  wrote:



Due to the security risks of implicit Grant flow, our Javascript adapter on=
ly supports  Auth Code Grant flow.  Our IDP has an extra step of allowing y=
ou to specify a valid CORS origin for an application.  Anybody see any prob=
lems with this kind of approach?  Implicit Grant Flow just seemed really ri=
sky to even support as a protocol.





On 2/6/2015 4:40 PM, Josh Mandel wrote:

Hi Adam,



I'm not 100% sure what you're envisioning as an alternative to the

implicit flow, but if I'm reading between the lines of your question

correctly, there are two key parts to the answer, because the implicit

flow is designed to accomplish two key goals (vs. the authorization code

grant):



1. Shave off one round-trip HTTP request (the step of exchanging a code

for a token)

2. Avoid unnecessarily leading the token to the client's back-end web serve=
r



Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes

advantage of the fact that a URL's "#hash" is not sent to the server

with an HTTP request. By embedding the token in a "#hash", it won't

inadvertently appear in server logs, for example. So with the implicit

flow, I can (for example) statically host a browser-based app at Amazon

S3 without having access tokens leak to Amazon. (Of course, if your

threat model includes a compromised server, then bets are off on this

point.)



Hope this helps,



  -Josh







On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis



> wrote:



   Hi,____



   __ __



   Having spent most of my time with native apps and web apps, I now am

   looking at use cases where I need to implement a user-agent-based

   app.  The Implicit flow seems to be optimized for this.____



   __ __



   To test my understanding, this flow is for a JavaScript client (or

   similar) executing within a web browser.____



   __ __



   At step (a) the client directs the UA to the authorization server,

   but the authorization server redirects the UA to a web-hosted client

   resource.  Why?  It says so that the web-hosted client resources can

   push javascript (or other) back into the UA so it can extract the

   access token in the fragment; but some sort of javascript is already

   running in the browser, since it initiated the authorization request

   in the first place.  So why this extra step?  Why not treat the

   javascript client running in the UA like a native app and handle the

   redirect uri?____



   __ __



   I know this was well thought out when the spec was written, so

   trying to figure out what I'm missing?____



   __ __



   __ __



   __ __



   Tx!

   adam____





   _______________________________________________

   OAuth mailing list

   OAuth@ietf.org 

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









_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



--

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

--

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

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


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











Hi John,


 <=
/p>

What do you mean by the a=
pp that is “already loaded and cached in the browser?”  Wh=
ere did this app come from initially?  Is this what comes from the web=
-hosted
 client resource in step D/E of section 4.2?  So the first time D/E *<=
b>will* flow over the wire, and in all subsequent requests it will be c=
ached? 



 <=
/p>

And with respect to the w=
eb hosted client resource, is this a resource deployed by the same domain a=
s the RS to facilitate the deployment of user-agent-based
 apps to access the APIs exposed by that RS?


 <=
/p>

 <=
/p>

adam

 <=
/p>





From: OAuth [m=
ailto:oauth-bounces@ietf.org]
On Behalf Of John Bradley

Sent: Monday, February 09, 2015 3:31 PM

To: Prateek Mishra

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow<=
/span>






 


Typically the implicit callback JS is part of the ap=
plication that is already loaded and cached in the browser.




 






The implicit flow doesn’t depend on on the fra=
gment not being re-appended to the resource location URI in the 302.  =
It would admittedly be more secure if that didn’t happen.  =







Re-appending the fragment is the correct browser beh=
aviour according to the W3C.






 






I still think you are farther ahead with that than l=
eaking the code in the referrer.






 






Implicit if done correctly has the token in one leg.=
  code on the other hand has the code in 4 legs and the token in one.<=
o:p>






 






It is having the JS make the exchange of code for th=
e AT without a secret that is the problem in my opinion.






 






If the client is a server that is doing the code -&g=
t; token exchange then the answer is different, but the question was for a =
JS only client.






 






John B.






 






 












On Feb 9, 2015, at 6:21 PM, Prateek Mishra <prateek.mishra@oracle.com> w=
rote:




 






The implicit flow depends upon a subtle and little k=
nown aspect of browser behavior - that the URI fragment component isn't pro=
pagated across redirects.




I havent checked this recently - but I am aware that several folks have fou=
nd that some browser versions dont comply with this requirement.

http://weblog.bulknews.net/post/85008516879/covert-=
redirect-vulnerability-with-oauth-2



The additional round-trip issue is also unclear. The implicit flow requires=
 an additional redirect (round-trip) to retrieve JS which retrieves the acc=
ess token from the fragment URI.




How is that different from a HTTPs callback to exchange the access code for=
 the access token?



- prateek








You are passing code in a query parameter, and without a secret that i=
s more likely to be leaked than sending token in the fragment directly from=
 the authorization endpoint to the browser JS in a fragment.

 


You have several extra round trips for no security benefit.  =
; In your case the code in the query parameter goes from the browser to the=
 redirect endpoint then must be sent back to the browser, and then to the t=
oken endpoint.


 


So yes using code for that is less secure.


 


Both rely solely on the registered redirect URI for security, but impl=
icit has fewer hopes and is more friendly to JS.


 


John B.




On Feb 9, 2015, at 5:50 PM, Bill Burke <bburke@redhat.com> wrote:


 


If you don't have a client secret, why is Javascript-based auth code g=
rant flow more risky?  We also require SSL and valid redirect URI patt=
erns to be registered for the application.  The code can only ever be =
sent to specific URLs and can only be used once.  CORS origin validati=
on is also an extra step we do to ensure a rogue javascript app isn't makin=
g any code-to-token requests.


 


I'm just trying to figure out if we missed anything...

 


On 2/9/2015 3:16 PM, John Bradley wrote:




If you don't have a client secret, or are storing the the client secre=
t in the Javascrypt, then you are probably more at risk using code than imp=
licit.


 


Implicit is risky because running a OAuth client in the browser is ris=
ky.  Using code in that case makes it no better, and arguably worse.


 


Perhaps I don't understand the environment.


 


John B.


 




On Feb 9, 2015, at 5:05 PM, Bill Burke <bburke@redhat.com> wrote:


 


Due to the security risks of implicit Grant flow, our Javascript adapt=
er only supports  Auth Code Grant flow.  Our IDP has an extra ste=
p of allowing you to specify a valid CORS origin for an application.  =
Anybody see any problems with this kind of approach?  Implicit Grant F=
low just seemed really risky to even support as a protocol.

 


 


On 2/6/2015 4:40 PM, Josh Mandel wrote:




Hi Adam,


 


I'm not 100% sure what you're envisioning as an alternative to the


implicit flow, but if I'm reading between the lines of your question


correctly, there are two key parts to the answer, because the implicit=



flow is designed to accomplish two key goals (vs. the authorization co=
de


grant):


 


1. Shave off one round-trip HTTP request (the step of exchanging a cod=
e


for a token)


2. Avoid unnecessarily leading the token to the client's back-end web =
server


 


Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes


advantage of the fact that a URL's "#hash" is not sent to th=
e server


with an HTTP request. By embedding the token in a "#hash", i=
t won't


inadvertently appear in server logs, for example. So with the implicit=



flow, I can (for example) statically host a browser-based app at Amazo=
n


S3 without having access tokens leak to Amazon. (Of course, if your


threat model includes a compromised server, then bets are off on this<=
o:p>


point.)


 


Hope this helps,


 


  -Josh


 


 


 


On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis


<Adam.Lewis@mot=
orolasolutions.com


<mailto:Adam.Le=
wis@motorolasolutions.com>> wrote:


 


   Hi,____


 


   __ __


 


   Having spent most of my time with native apps and web app=
s, I now am


   looking at use cases where I need to implement a user-age=
nt-based


   app.  The Implicit flow seems to be optimized for th=
is.____


 


   __ __


 


   To test my understanding, this flow is for a JavaScript c=
lient (or


   similar) executing within a web browser.____

 


   __ __


 


   At step (a) the client directs the UA to the authorizatio=
n server,


   but the authorization server redirects the UA to a web-ho=
sted client


   resource.  Why?  It says so that the web-hosted=
 client resources can


   push javascript (or other) back into the UA so it can ext=
ract the


   access token in the fragment; but some sort of javascript=
 is already


   running in the browser, since it initiated the authorizat=
ion request


   in the first place.  So why this extra step?  W=
hy not treat the


   javascript client running in the UA like a native app and=
 handle the


   redirect uri?____


 


   __ __


 


   I know this was well thought out when the spec was writte=
n, so


   trying to figure out what I’m missing?____


 


   __ __


 


   __ __


 


   __ __


 


   Tx!


   adam____


 


 


   _______________________________________________


   OAuth mailing list


   OAuth@ietf.org <mailto:OAuth@ietf.org><=
/pre>

   h=
ttps://www.ietf.org/mailman/listinfo/oauth


 


 


 


 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth


 




--


Bill Burke


JBoss, a division of Red Hat


http://bill.burkecentral.com=



 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth






-- 


Bill Burke


JBoss, a division of Red Hat


http://bill.burkecentral.com=














_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth


 




_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth








 








--_000_BLUPR04MB6914D0257B18CDBE1A9909395240BLUPR04MB691namprd_--


From nobody Tue Feb 10 08:53:21 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D2C1A90EB for ; Tue, 10 Feb 2015 08:53:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.791
X-Spam-Level: *
X-Spam-Status: No, score=1.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDN9SK8asYTX for ; Tue, 10 Feb 2015 08:53:10 -0800 (PST)
Received: from nm37-vm6.bullet.mail.gq1.yahoo.com (nm37-vm6.bullet.mail.gq1.yahoo.com [98.136.216.253]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B2E1A90AA for ; Tue, 10 Feb 2015 08:50:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1423587005; bh=FxEqPwzVrFhiB3pYJeh0PGv/o6C8+q+/skFIZ7JIAtk=; h=Date:From:Reply-To:To:Subject:From:Subject; b=TIiXIEsEPPAbvRzun1cpUFcAxuVZme/mn01e5l507cTov6+sWHkbYtfq/XA4ZetEY7uSALCdIHkHiTaZBfmKQuvlz1Wi18Iqtws9ELwmkMJ83jsYo8KL1rfKq9fvj07YteWc+qZHHJ5o/aCGR8R4aPVPDDBDDxpKeqzpHKkClpMF8g+fx/uSkwo6uTcXGLqqrPgK+8ZNNLJafr2IowZg64pYVwTXl2p9VKpILFZROflTyPr4CH/e0hzXia3svklfzl6sLy+luwJGBnjnV6uFL77BUV64saAwrOGHLPpcWFadvUK9fLUX1qqP5X0kVjLhbV3DbznDMAf4YdkVdT+cmA==
Received: from [127.0.0.1] by nm37.bullet.mail.gq1.yahoo.com with NNFMP; 10 Feb 2015 16:50:05 -0000
Received: from [98.137.12.63] by nm37.bullet.mail.gq1.yahoo.com with NNFMP; 10 Feb 2015 16:47:06 -0000
Received: from [98.139.212.151] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 10 Feb 2015 16:47:06 -0000
Received: from [98.139.212.221] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2015 16:47:06 -0000
Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 10 Feb 2015 16:47:06 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 413863.26925.bm@omp1030.mail.bf1.yahoo.com
X-YMail-OSG: PScH5.0VM1mn3RrdNymYIIazuxADLC4vzghRoyjXaodFD7ICkY6kwApq3G8FNAC MiNpROwzmBoXdt7fNGW3HHn4T1nnUjiRq1.8EFckLqCgvOLUH1wBs6BVC.fJMRWXzV10o1Zz4Asn RVWvHR7VroaICOa.BwltTkfYLmLUxyRmRR6V5eLueGVJ.m._MhEpgv0JEoR6ExgySHMjR0RGHGYM rc65fELF0mJHryiWi9H8rVxA5.4WyKfRar.wrzVQwiHP.JyzLVzLoL_8yF7.hW1vMxdIzHlLCoYJ pYE80tmIRNShjGT130y5nZnjoK4aGGZktWdFunPIVRQzgFC4Kenf1Hg9gNL9rwSXneaSSTxX0U9D 5J7.bgyUc7bB1_aZLXz2PKFbhkqm1dNV4LTHyLBiR5IWCpyNVaEk7FyYfvuF3DK_gvEmklV4lzKZ G_JISu3I5u_m2GRE1.gEAgUl_B9VFx_Jx5rVO3A.gLDRE6.myfbRcW4yQm6NbPN2mEAysyD0JPBB sCGbDfKdza8NfBFvV.GHyld7NStPr0kwjMYRaGifrYXlr22eTDRItpiWQvciUq2QAn818DfnwePn QA_VPX0MuJ8j6.wNNtOkQkBigFva2t8NPBK3srkgthcd8xfEXm6x4J4XDO7EaJu_hCkGxaY4dXA--
Received: by 76.13.26.71; Tue, 10 Feb 2015 16:47:05 +0000 
Date: Tue, 10 Feb 2015 16:47:05 +0000 (UTC)
From: Bill Mills 
To: OAuth WG 
Message-ID: <1076682052.2648765.1423586825705.JavaMail.yahoo@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_2648764_1924485152.1423586825703"
Archived-At: 
Subject: [OAUTH-WG] code flow for browsers?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Feb 2015 16:53:15 -0000

------=_Part_2648764_1924485152.1423586825703
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Does=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-spop-10=C2=A0provide=
 a way for us to replace the implicit flow with the code+proof key model? =
=C2=A0Yes, Implicit saves a round trip. =C2=A0This does deal nicely with so=
me of the security concerns raised recently around how fragments are handle=
d in the browser.
-bill=C2=A0=C2=A0
------=_Part_2648764_1924485152.1423586825703
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


Does https://tools.ietf.org/html/draft-ietf-oauth-spop-10 provide a way for us to replace the implicit flow with the code+proof key model?  Yes, Implicit saves a round trip.  This does deal nicely with some of the security concerns raised recently around how fragments are handled in the browser.

-bill 
 

------=_Part_2648764_1924485152.1423586825703--


From nobody Tue Feb 10 09:12:55 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8CA1A9148 for ; Tue, 10 Feb 2015 09:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP0iHDA6pNBL for ; Tue, 10 Feb 2015 09:12:10 -0800 (PST)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB251A9123 for ; Tue, 10 Feb 2015 09:10:14 -0800 (PST)
Received: by mail-qc0-f171.google.com with SMTP id l6so11242520qcy.2 for ; Tue, 10 Feb 2015 09:10:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=KTDKji58opzKSdk2bodaqSCt8JoMdli0o0M5YA+sWVM=; b=CEdKZ4TGLKcIGGRrRCm6QoZpOlKYxtDwsBjzAF2fwO6hALLPy120ZaXOqW4Tokq5c+ NKislIUXrGtI/Q7Z/+cRAO2dEAZ78Co6IafS54JnHnkYeDJW7bO2XO3W4WW6+Z4VHuI6 jYU3xc782asCyR2h0vklqY4wf6B78fxX9Q5Pliy+bRJA2or5VvBm8I6wecMrSACV6Ipc PNkV5Pq1ojWF3reDpGp9J6a8Z6wVJ8WN3G8wDYw0S3F4C7p6xp6e3OLOw9mR2VnvqQha zhVJ/zpqFx2yxzNbN2i44v7AAWERmAoJljspeXSG7CinEy60kxxogdWJLKjpcKDqV6kN RuFg==
X-Gm-Message-State: ALoCoQkQFnUqQ4srBDJCA1fVrye3bd9rzBh24JRyt7Ntz1laytLPq0y1OQ/4yVl9yhZNorWhidG+
X-Received: by 10.224.28.70 with SMTP id l6mr23346321qac.77.1423588213497; Tue, 10 Feb 2015 09:10:13 -0800 (PST)
Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id m10sm15863138qat.7.2015.02.10.09.10.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Feb 2015 09:10:12 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_FE78E31C-C0DF-40F6-A1DD-2408EB63A6C7"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: 
Date: Tue, 10 Feb 2015 14:10:07 -0300
Message-Id: <5078C62F-DB84-435E-858E-D72013BE6BBA@ve7jtb.com>
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D924CB.6070504@oracle.com> <3B0DDA4D-F540-4E23-9842-275532F7405F@ve7jtb.com> 
To: Adam Lewis 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Feb 2015 17:12:22 -0000

--Apple-Mail=_FE78E31C-C0DF-40F6-A1DD-2408EB63A6C7
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4C3CE092-EC35-4C90-99D3-F201274253D5"


--Apple-Mail=_4C3CE092-EC35-4C90-99D3-F201274253D5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Inline
> On Feb 10, 2015, at 1:12 PM, Adam Lewis =
 wrote:
>=20
> Hi John,
> =20
> What do you mean by the app that is =E2=80=9Calready loaded and cached =
in the browser?=E2=80=9D  Where did this app come from initially?  Is =
this what comes from the web-hosted client resource in step D/E of =
section 4.2?  So the first time D/E *will* flow over the wire, and in =
all subsequent requests it will be cached?=20

Yes the web hosted client resource is typically the same JS code that is =
creating the Authorization request in A.   Now that you mention it the =
diagram in 4.2 is ambiguous about where that request comes from , the =
fact that it is coming from the browser implies that it is a JS CORS =
type request.

In some cases you might have a webserver invoke it via a 302 redirect =
and load a new JS app from the redirect URI.
=20
The important thing is that the fragment is not sent to the server on =
the call that loads the JS even if it is not cached. =20

The thing people do (facebook and others) that is twisting implicit in =
my opinion is having the callback URI just load a JS snipppet that =
extracts the token and posts it back to =E2=80=9CWeb hosted client =
resource=E2=80=9D
Those applications should be using the code flow.=20


> =20
> And with respect to the web hosted client resource, is this a resource =
deployed by the same domain as the RS to facilitate the deployment of =
user-agent-based apps to access the APIs exposed by that RS?

The hosted client resource is typically a AJAX/AngularJS application =
that doesn=E2=80=99t want to swap out it=E2=80=99s context by doing a =
full 302 redirect to the AS. =20

The AS and RS could be completely separate from the client.

However it is not uncommon for people developing AngularJS apps to =
protect the API that they use with OAuth, in that case they may all be =
from the same domain.

It might be that a sophisticated app may have multiple tokens for =
different API across multiple providers.

John B.
> =20
> =20
> adam
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
> Sent: Monday, February 09, 2015 3:31 PM
> To: Prateek Mishra
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
> =20
> Typically the implicit callback JS is part of the application that is =
already loaded and cached in the browser.
> =20
> The implicit flow doesn=E2=80=99t depend on on the fragment not being =
re-appended to the resource location URI in the 302.  It would =
admittedly be more secure if that didn=E2=80=99t happen. =20
> Re-appending the fragment is the correct browser behaviour according =
to the W3C.
> =20
> I still think you are farther ahead with that than leaking the code in =
the referrer.
> =20
> Implicit if done correctly has the token in one leg.  code on the =
other hand has the code in 4 legs and the token in one.
> =20
> It is having the JS make the exchange of code for the AT without a =
secret that is the problem in my opinion.
> =20
> If the client is a server that is doing the code -> token exchange =
then the answer is different, but the question was for a JS only client.
> =20
> John B.
> =20
> =20
> On Feb 9, 2015, at 6:21 PM, Prateek Mishra > wrote:
> =20
> The implicit flow depends upon a subtle and little known aspect of =
browser behavior - that the URI fragment component isn't propagated =
across redirects.=20
>=20
> I havent checked this recently - but I am aware that several folks =
have found that some browser versions dont comply with this requirement.
> =
http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-=
with-oauth-2 =

>=20
> The additional round-trip issue is also unclear. The implicit flow =
requires an additional redirect (round-trip) to retrieve JS which =
retrieves the access token from the fragment URI.=20
>=20
> How is that different from a HTTPs callback to exchange the access =
code for the access token?
>=20
> - prateek
>=20
>=20
> You are passing code in a query parameter, and without a secret that =
is more likely to be leaked than sending token in the fragment directly =
from the authorization endpoint to the browser JS in a fragment.
> =20
> You have several extra round trips for no security benefit.   In your =
case the code in the query parameter goes from the browser to the =
redirect endpoint then must be sent back to the browser, and then to the =
token endpoint.
> =20
> So yes using code for that is less secure.
> =20
> Both rely solely on the registered redirect URI for security, but =
implicit has fewer hopes and is more friendly to JS.
> =20
> John B.
> On Feb 9, 2015, at 5:50 PM, Bill Burke  =
 wrote:
> =20
> If you don't have a client secret, why is Javascript-based auth code =
grant flow more risky?  We also require SSL and valid redirect URI =
patterns to be registered for the application.  The code can only ever =
be sent to specific URLs and can only be used once.  CORS origin =
validation is also an extra step we do to ensure a rogue javascript app =
isn't making any code-to-token requests.
> =20
> I'm just trying to figure out if we missed anything...
> =20
> On 2/9/2015 3:16 PM, John Bradley wrote:
> If you don't have a client secret, or are storing the the client =
secret in the Javascrypt, then you are probably more at risk using code =
than implicit.
> =20
> Implicit is risky because running a OAuth client in the browser is =
risky.  Using code in that case makes it no better, and arguably worse.
> =20
> Perhaps I don't understand the environment.
> =20
> John B.
> =20
> On Feb 9, 2015, at 5:05 PM, Bill Burke  =
 wrote:
> =20
> Due to the security risks of implicit Grant flow, our Javascript =
adapter only supports  Auth Code Grant flow.  Our IDP has an extra step =
of allowing you to specify a valid CORS origin for an application.  =
Anybody see any problems with this kind of approach?  Implicit Grant =
Flow just seemed really risky to even support as a protocol.
> =20
> =20
> On 2/6/2015 4:40 PM, Josh Mandel wrote:
> Hi Adam,
> =20
> I'm not 100% sure what you're envisioning as an alternative to the
> implicit flow, but if I'm reading between the lines of your question
> correctly, there are two key parts to the answer, because the implicit
> flow is designed to accomplish two key goals (vs. the authorization =
code
> grant):
> =20
> 1. Shave off one round-trip HTTP request (the step of exchanging a =
code
> for a token)
> 2. Avoid unnecessarily leading the token to the client's back-end web =
server
> =20
> Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes
> advantage of the fact that a URL's "#hash" is not sent to the server
> with an HTTP request. By embedding the token in a "#hash", it won't
> inadvertently appear in server logs, for example. So with the implicit
> flow, I can (for example) statically host a browser-based app at =
Amazon
> S3 without having access tokens leak to Amazon. (Of course, if your
> threat model includes a compromised server, then bets are off on this
> point.)
> =20
> Hope this helps,
> =20
>   -Josh
> =20
> =20
> =20
> On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis
> 
>  =
> wrote:
> =20
>    Hi,____
> =20
>    __ __
> =20
>    Having spent most of my time with native apps and web apps, I now =
am
>    looking at use cases where I need to implement a user-agent-based
>    app.  The Implicit flow seems to be optimized for this.____
> =20
>    __ __
> =20
>    To test my understanding, this flow is for a JavaScript client (or
>    similar) executing within a web browser.____
> =20
>    __ __
> =20
>    At step (a) the client directs the UA to the authorization server,
>    but the authorization server redirects the UA to a web-hosted =
client
>    resource.  Why?  It says so that the web-hosted client resources =
can
>    push javascript (or other) back into the UA so it can extract the
>    access token in the fragment; but some sort of javascript is =
already
>    running in the browser, since it initiated the authorization =
request
>    in the first place.  So why this extra step?  Why not treat the
>    javascript client running in the UA like a native app and handle =
the
>    redirect uri?____
> =20
>    __ __
> =20
>    I know this was well thought out when the spec was written, so
>    trying to figure out what I=E2=80=99m missing?____
> =20
>    __ __
> =20
>    __ __
> =20
>    __ __
> =20
>    Tx!
>    adam____
> =20
> =20
>    _______________________________________________
>    OAuth mailing list
>    OAuth@ietf.org   =

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

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

> =20
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com 
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

> --=20
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com 
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_4C3CE092-EC35-4C90-99D3-F201274253D5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Inline
On Feb 10, 2015, at 1:12 PM, Adam Lewis =
<Adam.Lewis@motorolasolutions.com> wrote:

Hi John,
 
What do you mean by the =
app that is =E2=80=9Calready loaded and cached in the browser?=E2=80=9D&nb=
sp; Where did this app come from initially?  Is this what comes =
from the web-hosted client resource in step D/E of section 4.2?  So =
the first time D/E *will* flow over the wire, and in =
all subsequent requests it will be =
cached? 

Yes the web hosted client resource is typically the =
same JS code that is creating the Authorization request in A.   Now =
that you mention it the diagram in 4.2 is ambiguous about where that =
request comes from , the fact that it is coming from the browser implies =
that it is a JS CORS type request.

In =
some cases you might have a webserver invoke it via a 302 redirect and =
load a new JS app from the redirect URI.
 
The =
important thing is that the fragment is not sent to the server on the =
call that loads the JS even if it is not cached.  

The thing people do (facebook and others) that is =
twisting implicit in my opinion is having the callback URI just load a =
JS snipppet that extracts the token and posts it back to =E2=80=9CWeb =
hosted client resource=E2=80=9D
Those applications should be =
using the code flow. 


 
And with respect to the web hosted client =
resource, is this a resource deployed by the same domain as the RS to =
facilitate the deployment of user-agent-based apps to access the APIs =
exposed by that RS?

The hosted client resource is typically a =
AJAX/AngularJS application that doesn=E2=80=99t want to swap out it=E2=80=99=
s context by doing a full 302 redirect to the AS.  

The AS and RS could be completely separate from =
the client.

However it is not =
uncommon for people developing AngularJS apps to protect the API that =
they use with OAuth, in that case they may all be from the same =
domain.

It might be that a =
sophisticated app may have multiple tokens for different API across =
multiple providers.

John B.
 
 
adam
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of John Bradley
Sent: Monday, February 09, 2015 =
3:31 PM
To: Prateek Mishra
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confusion on =
Implicit Grant flow
 
Typically the implicit callback JS is =
part of the application that is already loaded and cached in the =
browser.
 
The implicit flow =
doesn=E2=80=99t depend on on the fragment not being re-appended to the =
resource location URI in the 302.  It would admittedly be more =
secure if that didn=E2=80=99t happen.  
Re-appending the fragment is the correct browser behaviour =
according to the W3C.
 
I still think you are farther ahead with that than =
leaking the code in the referrer.
 
Implicit if done correctly has the token in one leg. =
 code on the other hand has the code in 4 legs and the token in =
one.
 
It is having the JS make the exchange of code for the =
AT without a secret that is the problem in my opinion.
 
If the client is a server that is doing =
the code -> token exchange then the answer is different, but the =
question was for a JS only client.
 
John B.
 
 
On Feb 9, 2015, at 6:21 PM, Prateek Mishra <prateek.mishra@oracle.com> =
wrote:
 
The implicit flow =
depends upon a subtle and little known aspect of browser behavior - that =
the URI fragment component isn't propagated across redirects. 

I havent checked this recently - but I am aware that several =
folks have found that some browser versions dont comply with this =
requirement.
http://weblog.bulknews.net/post/85008516879/covert-redirect-vul=
nerability-with-oauth-2

The additional =
round-trip issue is also unclear. The implicit flow requires an =
additional redirect (round-trip) to retrieve JS which retrieves the =
access token from the fragment URI. 

How is that different from a HTTPs callback to exchange the =
access code for the access token?

- =
prateek


You are passing =
code in a query parameter, and without a secret that is more likely to =
be leaked than sending token in the fragment directly from the =
authorization endpoint to the browser JS in a fragment.
 
You have =
several extra round trips for no security benefit.   In your =
case the code in the query parameter goes from the browser to the =
redirect endpoint then must be sent back to the browser, and then to the =
token endpoint.
 
So yes using =
code for that is less secure.
 
Both rely solely on the registered redirect =
URI for security, but implicit has fewer hopes and is more friendly to =
JS.
 
John B.
On Feb 9, 2015, =
at 5:50 PM, Bill Burke <bburke@redhat.com> wrote:
 
If you don't =
have a client secret, why is Javascript-based auth code grant flow more =
risky?  We also require SSL and valid redirect URI patterns to be =
registered for the application.  The code can only ever be sent to =
specific URLs and can only be used once.  CORS origin validation is =
also an extra step we do to ensure a rogue javascript app isn't making =
any code-to-token requests.
 
I'm just trying to figure out if we missed =
anything...
 
On 2/9/2015 =
3:16 PM, John Bradley wrote:
If you don't have a client secret, or are =
storing the the client secret in the Javascrypt, then you are probably =
more at risk using code than implicit.
 
Implicit is risky because running a OAuth =
client in the browser is risky.  Using code in that case makes it =
no better, and arguably worse.
 
Perhaps I don't understand the =
environment.
 
John B.
 
On Feb 9, 2015, =
at 5:05 PM, Bill Burke <bburke@redhat.com> wrote:
 
Due to the =
security risks of implicit Grant flow, our Javascript adapter only =
supports  Auth Code Grant flow.  Our IDP has an extra step of =
allowing you to specify a valid CORS origin for an application.  =
Anybody see any problems with this kind of approach?  Implicit =
Grant Flow just seemed really risky to even support as a protocol.
 
 
On 2/6/2015 =
4:40 PM, Josh Mandel wrote:
Hi Adam,
 
I'm not 100% sure what you're envisioning as =
an alternative to the
implicit flow, but if I'm reading between the lines of your =
question
correctly, there are two key parts to the answer, because the =
implicit
flow =
is designed to accomplish two key goals (vs. the authorization code
grant):
 
1. Shave off =
one round-trip HTTP request (the step of exchanging a code
for a =
token)
2. =
Avoid unnecessarily leading the token to the client's back-end web =
server
 
Goal 1 is =
straightforward. For goal 2: OAuth2's implicit flow takes
advantage of =
the fact that a URL's "#hash" is not sent to the server
with an HTTP =
request. By embedding the token in a "#hash", it won't
inadvertently =
appear in server logs, for example. So with the implicit
flow, I can =
(for example) statically host a browser-based app at Amazon
S3 without =
having access tokens leak to Amazon. (Of course, if your
threat model =
includes a compromised server, then bets are off on this
point.)
 
Hope this =
helps,
 
  =
-Josh
 
 
 
On Fri, Feb 6, =
2015 at 1:27 PM, Adam Lewis
<Adam.Lewis@motorolasolutions.com
<mailto:Adam.Lewis@motorolasolutions.com>> =
wrote:
 
   =
Hi,____
 
   __ =
__
 
   =
Having spent most of my time with native apps and web apps, I now am
   =
looking at use cases where I need to implement a user-agent-based
   =
app.  The Implicit flow seems to be optimized for this.____
 
   __ =
__
 
   To =
test my understanding, this flow is for a JavaScript client (or
   =
similar) executing within a web browser.____
 
   __ =
__
 
   At =
step (a) the client directs the UA to the authorization server,
   =
but the authorization server redirects the UA to a web-hosted client
   =
resource.  Why?  It says so that the web-hosted client =
resources can
   push javascript (or other) back into the UA so =
it can extract the
   access token in the fragment; but some sort of =
javascript is already
   running in the browser, since it initiated the =
authorization request
   in the first place.  So why this extra =
step?  Why not treat the
   javascript client running in the =
UA like a native app and handle the
   redirect uri?____
 
   __ =
__
 
   I =
know this was well thought out when the spec was written, so
   =
trying to figure out what I=E2=80=99m missing?____
 
   __ =
__
 
   __ =
__
 
   __ =
__
 
   =
Tx!
   =
adam____
 
 
   =
_______________________________________________
   =
OAuth mailing list
   OAuth@ietf.org <mailto:OAuth@ietf.org>
   https://www.ietf.org/mailman/listinfo/oauth
 
 
 
 
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
--
Bill Burke
JBoss, a =
division of Red Hat
http://bill.burkecentral.com
 
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
-- 
Bill =
Burke
JBoss, a =
division of Red Hat
http://bill.burkecentral.com



_______________________________________________
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=_4C3CE092-EC35-4C90-99D3-F201274253D5--

--Apple-Mail=_FE78E31C-C0DF-40F6-A1DD-2408EB63A6C7
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMTAxNzEwMDdaMCMGCSqGSIb3DQEJBDEWBBRaWcH5enGPaN81KWlTNDyD
F/ajwzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCbtukGTCUCP+K8SjYbTv7SVIYO8jNltssYa+/SXdf25+YX/VsCyvuv
Te0UXitznvoyeAmhKkhgGs3u7N46yTRZ+aBY2ZOtYov6bRUu9mrBidMU8wh98JX2TRbYB5hgq8cO
Dw7hKVKp/PWW2Nxi4rabk1fkUfeZm3PhWBL+63YhbBPbXWVrsyC/OCdia8N9n1VPxTNN32MslXjA
7qi+k9j01kdNW9NAz8JH2Q8h7wCULX7/NA9vNeGxte/+eRPxdULkbmKUZ+huIZTVmwf0qw65GRgt
oIKFVl4jJEiRUS49PfCkl3bnM132LPDV+0huaCrmH/5eWFyPzjSHno4iPCuLAAAAAAAA
--Apple-Mail=_FE78E31C-C0DF-40F6-A1DD-2408EB63A6C7--


From nobody Tue Feb 10 10:45:32 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE3F1A1B5A for ; Tue, 10 Feb 2015 10:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level: 
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQChkNlVR2gf for ; Tue, 10 Feb 2015 10:45:16 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6BA1A1B44 for ; Tue, 10 Feb 2015 10:45:15 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1AIjEcO010015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Feb 2015 18:45:14 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t1AIjDqm005239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Feb 2015 18:45:13 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1AIjDQw011633; Tue, 10 Feb 2015 18:45:13 GMT
Received: from [130.35.50.79] (/130.35.50.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Feb 2015 10:45:12 -0800
Message-ID: <54DA51B7.4050000@oracle.com>
Date: Tue, 10 Feb 2015 10:45:11 -0800
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: John Bradley , Adam Lewis 
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D924CB.6070504@oracle.com> <3B0DDA4D-F540-4E23-9842-275532F7405F@ve7jtb.com>  <5078C62F-DB84-435E-858E-D72013BE6BBA@ve7jtb.com>
In-Reply-To: <5078C62F-DB84-435E-858E-D72013BE6BBA@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------000509050805080701090408"
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Feb 2015 18:45:27 -0000

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

We use a simpler flow that isn't as open-ended as the implicit flow.

The JS client uses a XMLHttpRequest call to exchange the browser cookie 
for an access token to the desired resource
(this can be modeled via the Assertion Framework specification, with the 
cookie acting as the authorization grant).

The JS client subsequently uses the access token to interact with the 
resource server.

- prateek
> Inline
>> On Feb 10, 2015, at 1:12 PM, Adam Lewis 
>> > > wrote:
>>
>> Hi John,
>> What do you mean by the app that is “already loaded and cached in the 
>> browser?† Where did this app come from initially?  Is this what 
>> comes from the web-hosted client resource in step D/E of section 
>> 4.2?  So the first time D/E **will** flow over the wire, and in all 
>> subsequent requests it will be cached?
>
> Yes the web hosted client resource is typically the same JS code that 
> is creating the Authorization request in A.   Now that you mention it 
> the diagram in 4.2 is ambiguous about where that request comes from , 
> the fact that it is coming from the browser implies that it is a JS 
> CORS type request.
>
> In some cases you might have a webserver invoke it via a 302 redirect 
> and load a new JS app from the redirect URI.
> The important thing is that the fragment is not sent to the server on 
> the call that loads the JS even if it is not cached.
>
> The thing people do (facebook and others) that is twisting implicit in 
> my opinion is having the callback URI just load a JS snipppet that 
> extracts the token and posts it back to “Web hosted client resourceâ€
> Those applications should be using the code flow.
>
>
>> And with respect to the web hosted client resource, is this a 
>> resource deployed by the same domain as the RS to facilitate the 
>> deployment of user-agent-based apps to access the APIs exposed by 
>> that RS?
>
> The hosted client resource is typically a AJAX/AngularJS application 
> that doesn’t want to swap out it’s context by doing a full 302 
> redirect to the AS.
>
> The AS and RS could be completely separate from the client.
>
> However it is not uncommon for people developing AngularJS apps to 
> protect the API that they use with OAuth, in that case they may all be 
> from the same domain.
>
> It might be that a sophisticated app may have multiple tokens for 
> different API across multiple providers.
>
> John B.
>> adam
>> *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf Of*John Bradley
>> *Sent:*Monday, February 09, 2015 3:31 PM
>> *To:*Prateek Mishra
>> *Cc:*oauth@ietf.org 
>> *Subject:*Re: [OAUTH-WG] Confusion on Implicit Grant flow
>> Typically the implicit callback JS is part of the application that is 
>> already loaded and cached in the browser.
>> The implicit flow doesn’t depend on on the fragment not being 
>> re-appended to the resource location URI in the 302.  It would 
>> admittedly be more secure if that didn’t happen.
>> Re-appending the fragment is the correct browser behaviour according 
>> to the W3C.
>> I still think you are farther ahead with that than leaking the code 
>> in the referrer.
>> Implicit if done correctly has the token in one leg.  code on the 
>> other hand has the code in 4 legs and the token in one.
>> It is having the JS make the exchange of code for the AT without a 
>> secret that is the problem in my opinion.
>> If the client is a server that is doing the code -> token exchange 
>> then the answer is different, but the question was for a JS only client.
>> John B.
>>
>>     On Feb 9, 2015, at 6:21 PM, Prateek Mishra
>>     > wrote:
>>     The implicit flow depends upon a subtle and little known aspect
>>     of browser behavior - that the URI fragment component isn't
>>     propagated across redirects.
>>
>>     I havent checked this recently - but I am aware that several
>>     folks have found that some browser versions dont comply with this
>>     requirement.
>>     http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-with-oauth-2
>>
>>     The additional round-trip issue is also unclear. The implicit
>>     flow requires an additional redirect (round-trip) to retrieve JS
>>     which retrieves the access token from the fragment URI.
>>
>>     How is that different from a HTTPs callback to exchange the
>>     access code for the access token?
>>
>>     - prateek
>>
>>
>>     You are passing code in a query parameter, and without a secret that is more likely to be leaked than sending token in the fragment directly from the authorization endpoint to the browser JS in a fragment.
>>
>>       
>>
>>     You have several extra round trips for no security benefit.   In your case the code in the query parameter goes from the browser to the redirect endpoint then must be sent back to the browser, and then to the token endpoint.
>>
>>       
>>
>>     So yes using code for that is less secure.
>>
>>       
>>
>>     Both rely solely on the registered redirect URI for security, but implicit has fewer hopes and is more friendly to JS.
>>
>>       
>>
>>     John B.
>>
>>         On Feb 9, 2015, at 5:50 PM, Bill Burke    wrote:
>>
>>           
>>
>>         If you don't have a client secret, why is Javascript-based auth code grant flow more risky?  We also require SSL and valid redirect URI patterns to be registered for the application.  The code can only ever be sent to specific URLs and can only be used once.  CORS origin validation is also an extra step we do to ensure a rogue javascript app isn't making any code-to-token requests.
>>
>>           
>>
>>         I'm just trying to figure out if we missed anything...
>>
>>           
>>
>>         On 2/9/2015 3:16 PM, John Bradley wrote:
>>
>>             If you don't have a client secret, or are storing the the client secret in the Javascrypt, then you are probably more at risk using code than implicit.
>>
>>               
>>
>>             Implicit is risky because running a OAuth client in the browser is risky.  Using code in that case makes it no better, and arguably worse.
>>
>>               
>>
>>             Perhaps I don't understand the environment.
>>
>>               
>>
>>             John B.
>>
>>               
>>
>>                 On Feb 9, 2015, at 5:05 PM, Bill Burke    wrote:
>>
>>                   
>>
>>                 Due to the security risks of implicit Grant flow, our Javascript adapter only supports  Auth Code Grant flow.  Our IDP has an extra step of allowing you to specify a valid CORS origin for an application.  Anybody see any problems with this kind of approach?  Implicit Grant Flow just seemed really risky to even support as a protocol.
>>
>>                   
>>
>>                   
>>
>>                 On 2/6/2015 4:40 PM, Josh Mandel wrote:
>>
>>                     Hi Adam,
>>
>>                       
>>
>>                     I'm not 100% sure what you're envisioning as an alternative to the
>>
>>                     implicit flow, but if I'm reading between the lines of your question
>>
>>                     correctly, there are two key parts to the answer, because the implicit
>>
>>                     flow is designed to accomplish two key goals (vs. the authorization code
>>
>>                     grant):
>>
>>                       
>>
>>                     1. Shave off one round-trip HTTP request (the step of exchanging a code
>>
>>                     for a token)
>>
>>                     2. Avoid unnecessarily leading the token to the client's back-end web server
>>
>>                       
>>
>>                     Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes
>>
>>                     advantage of the fact that a URL's "#hash" is not sent to the server
>>
>>                     with an HTTP request. By embedding the token in a "#hash", it won't
>>
>>                     inadvertently appear in server logs, for example. So with the implicit
>>
>>                     flow, I can (for example) statically host a browser-based app at Amazon
>>
>>                     S3 without having access tokens leak to Amazon. (Of course, if your
>>
>>                     threat model includes a compromised server, then bets are off on this
>>
>>                     point.)
>>
>>                       
>>
>>                     Hope this helps,
>>
>>                       
>>
>>                        -Josh
>>
>>                       
>>
>>                       
>>
>>                       
>>
>>                     On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis
>>
>>                     
>>
>>                       > wrote:
>>
>>                       
>>
>>                         Hi,____
>>
>>                       
>>
>>                         __ __
>>
>>                       
>>
>>                         Having spent most of my time with native apps and web apps, I now am
>>
>>                         looking at use cases where I need to implement a user-agent-based
>>
>>                         app.  The Implicit flow seems to be optimized for this.____
>>
>>                       
>>
>>                         __ __
>>
>>                       
>>
>>                         To test my understanding, this flow is for a JavaScript client (or
>>
>>                         similar) executing within a web browser.____
>>
>>                       
>>
>>                         __ __
>>
>>                       
>>
>>                         At step (a) the client directs the UA to the authorization server,
>>
>>                         but the authorization server redirects the UA to a web-hosted client
>>
>>                         resource.  Why?  It says so that the web-hosted client resources can
>>
>>                         push javascript (or other) back into the UA so it can extract the
>>
>>                         access token in the fragment; but some sort of javascript is already
>>
>>                         running in the browser, since it initiated the authorization request
>>
>>                         in the first place.  So why this extra step?  Why not treat the
>>
>>                         javascript client running in the UA like a native app and handle the
>>
>>                         redirect uri?____
>>
>>                       
>>
>>                         __ __
>>
>>                       
>>
>>                         I know this was well thought out when the spec was written, so
>>
>>                         trying to figure out what I’m missing?____
>>
>>                       
>>
>>                         __ __
>>
>>                       
>>
>>                         __ __
>>
>>                       
>>
>>                         __ __
>>
>>                       
>>
>>                         Tx!
>>
>>                         adam____
>>
>>                       
>>
>>                       
>>
>>                         _______________________________________________
>>
>>                         OAuth mailing list
>>
>>                         OAuth@ietf.org      
>>
>>                         https://www.ietf.org/mailman/listinfo/oauth
>>
>>                       
>>
>>                       
>>
>>                       
>>
>>                       
>>
>>                     _______________________________________________
>>
>>                     OAuth mailing list
>>
>>                     OAuth@ietf.org  
>>
>>                     https://www.ietf.org/mailman/listinfo/oauth
>>
>>                       
>>
>>                 --
>>
>>                 Bill Burke
>>
>>                 JBoss, a division of Red Hat
>>
>>                 http://bill.burkecentral.com  
>>
>>                   
>>
>>                 _______________________________________________
>>
>>                 OAuth mailing list
>>
>>                 OAuth@ietf.org  
>>
>>                 https://www.ietf.org/mailman/listinfo/oauth
>>
>>         -- 
>>
>>         Bill Burke
>>
>>         JBoss, a division of Red Hat
>>
>>         http://bill.burkecentral.com  
>>
>>
>>
>>
>>     _______________________________________________
>>
>>     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
>>
>


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


  
    
  
  
    We use a simpler flow that isn't as open-ended as the implicit flow.

    

    The JS client uses a XMLHttpRequest call to exchange the browser
    cookie for an access token to the desired resource 

    (this can be modeled via the Assertion Framework specification, with
    the cookie acting as the authorization grant).

    

    The JS client subsequently uses the access token to interact with
    the resource server. 

    

    - prateek

    

      
      Inline

      

        

          
On Feb 10, 2015, at 1:12 PM, Adam Lewis <Adam.Lewis@motorolasolutions.com>
            wrote:

          

          

            

              
Hi
                  John,

              
 

              
What do
                  you mean by the app that is “already loaded and cached
                  in the browser?â€Â  Where did this app come from
                  initially?  Is this what comes from the web-hosted
                  client resource in step D/E of section 4.2?  So the
                  first time D/E *will* flow over the
                  wire, and in all subsequent requests it will be
                  cached? 

            

          

        

        


        

        Yes the web hosted client resource is typically the same JS code
        that is creating the Authorization request in A.   Now that you
        mention it the diagram in 4.2 is ambiguous about where that
        request comes from , the fact that it is coming from the browser
        implies that it is a JS CORS type request.

      


      

      
In some cases you might have a webserver invoke it via a 302
        redirect and load a new JS app from the redirect URI.

      
 

      
The important thing is that the fragment is not sent to the
        server on the call that loads the JS even if it is not cached.  

      


      

      
The thing people do (facebook and others) that is twisting
        implicit in my opinion is having the callback URI just load a JS
        snipppet that extracts the token and posts it back to “Web
        hosted client resourceâ€

      
Those applications should be using the code flow. 

      


      

      


        

          

            

              

              
 

              
And
                  with respect to the web hosted client resource, is
                  this a resource deployed by the same domain as the RS
                  to facilitate the deployment of user-agent-based apps
                  to access the APIs exposed by that RS?

            

          

        

        


        

        The hosted client resource is typically a AJAX/AngularJS
        application that doesn’t want to swap out it’s context by doing
        a full 302 redirect to the AS.  

      


      

      
The AS and RS could be completely separate from the client.

      


      

      
However it is not uncommon for people developing AngularJS
        apps to protect the API that they use with OAuth, in that case
        they may all be from the same domain.

      


      

      
It might be that a sophisticated app may have multiple tokens
        for different API across multiple providers.

      


      

      
John B.

        

          

            

              

              
 

              
 

              
adam

              
 

              

                

                  
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John
                      Bradley

                      Sent: Monday,
                      February 09, 2015 3:31 PM

                      To: Prateek
                      Mishra

                      Cc: oauth@ietf.org

                      Subject: Re:
                      [OAUTH-WG] Confusion on Implicit Grant flow

                

              

              
 

              
Typically
                the implicit callback JS is part of the application that
                is already loaded and cached in the browser.

              

                
 

              

              

                
The
                  implicit flow doesn’t depend on on the fragment not
                  being re-appended to the resource location URI in the
                  302.  It would admittedly be more secure if that
                  didn’t happen.  

              

              

                
Re-appending
                  the fragment is the correct browser behaviour
                  according to the W3C.

              

              

                
 

              

              

                
I
                  still think you are farther ahead with that than
                  leaking the code in the referrer.

              

              

                
 

              

              

                
Implicit
                  if done correctly has the token in one leg.  code on
                  the other hand has the code in 4 legs and the token in
                  one.

              

              

                
 

              

              

                
It is
                  having the JS make the exchange of code for the AT
                  without a secret that is the problem in my opinion.

              

              

                
 

              

              

                
If
                  the client is a server that is doing the code ->
                  token exchange then the answer is different, but the
                  question was for a JS only client.

              

              

                
 

              

              

                
John
                  B.

              

              

                
 

              

              

                
 

              

              

                

                  

                    

                      
On Feb 9, 2015, at 6:21 PM, Prateek
                        Mishra <prateek.mishra@oracle.com>
                        wrote:

                    

                    
 

                    

                      

                        
The implicit flow depends upon a
                          subtle and little known aspect of browser
                          behavior - that the URI fragment component
                          isn't propagated across redirects. 

                          

                          I havent checked this recently - but I am
                          aware that several folks have found that some
                          browser versions dont comply with this
                          requirement.

                          http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-with-oauth-2

                          

                          The additional round-trip issue is also
                          unclear. The implicit flow requires an
                          additional redirect (round-trip) to retrieve
                          JS which retrieves the access token from the
                          fragment URI. 

                          

                          How is that different from a HTTPs callback to
                          exchange the access code for the access token?

                          

                          - prateek

                          

                          

                          

                        
You are passing code in a query parameter, and without a secret that is more likely to be leaked than sending token in the fragment directly from the authorization endpoint to the browser JS in a fragment.

                        
 

                        
You have several extra round trips for no security benefit.   In your case the code in the query parameter goes from the browser to the redirect endpoint then must be sent back to the browser, and then to the token endpoint.

                        
 

                        
So yes using code for that is less secure.

                        
 

                        
Both rely solely on the registered redirect URI for security, but implicit has fewer hopes and is more friendly to JS.

                        
 

                        
John B.

                        

                          
On Feb 9, 2015, at 5:50 PM, Bill Burke <bburke@redhat.com> wrote:

                          
 

                          
If you don't have a client secret, why is Javascript-based auth code grant flow more risky?  We also require SSL and valid redirect URI patterns to be registered for the application.  The code can only ever be sent to specific URLs and can only be used once.  CORS origin validation is also an extra step we do to ensure a rogue javascript app isn't making any code-to-token requests.

                          
 

                          
I'm just trying to figure out if we missed anything...

                          
 

                          
On 2/9/2015 3:16 PM, John Bradley wrote:

                          

                            
If you don't have a client secret, or are storing the the client secret in the Javascrypt, then you are probably more at risk using code than implicit.

                            
 

                            
Implicit is risky because running a OAuth client in the browser is risky.  Using code in that case makes it no better, and arguably worse.

                            
 

                            
Perhaps I don't understand the environment.

                            
 

                            
John B.

                            
 

                            

                              
On Feb 9, 2015, at 5:05 PM, Bill Burke <bburke@redhat.com> wrote:

                              
 

                              
Due to the security risks of implicit Grant flow, our Javascript adapter only supports  Auth Code Grant flow.  Our IDP has an extra step of allowing you to specify a valid CORS origin for an application.  Anybody see any problems with this kind of approach?  Implicit Grant Flow just seemed really risky to even support as a protocol.

                              
 

                              
 

                              
On 2/6/2015 4:40 PM, Josh Mandel wrote:

                              

                                
Hi Adam,

                                
 

                                
I'm not 100% sure what you're envisioning as an alternative to the

                                
implicit flow, but if I'm reading between the lines of your question

                                
correctly, there are two key parts to the answer, because the implicit

                                
flow is designed to accomplish two key goals (vs. the authorization code

                                
grant):

                                
 

                                
1. Shave off one round-trip HTTP request (the step of exchanging a code

                                
for a token)

                                
2. Avoid unnecessarily leading the token to the client's back-end web server

                                
 

                                
Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes

                                
advantage of the fact that a URL's "#hash" is not sent to the server

                                
with an HTTP request. By embedding the token in a "#hash", it won't

                                
inadvertently appear in server logs, for example. So with the implicit

                                
flow, I can (for example) statically host a browser-based app at Amazon

                                
S3 without having access tokens leak to Amazon. (Of course, if your

                                
threat model includes a compromised server, then bets are off on this

                                
point.)

                                
 

                                
Hope this helps,

                                
 

                                
  -Josh

                                
 

                                
 

                                
 

                                
On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis

                                
<Adam.Lewis@motorolasolutions.com

                                
<mailto:Adam.Lewis@motorolasolutions.com>> wrote:

                                
 

                                
   Hi,____

                                
 

                                
   __ __

                                
 

                                
   Having spent most of my time with native apps and web apps, I now am

                                
   looking at use cases where I need to implement a user-agent-based

                                
   app.  The Implicit flow seems to be optimized for this.____

                                
 

                                
   __ __

                                
 

                                
   To test my understanding, this flow is for a JavaScript client (or

                                
   similar) executing within a web browser.____

                                
 

                                
   __ __

                                
 

                                
   At step (a) the client directs the UA to the authorization server,

                                
   but the authorization server redirects the UA to a web-hosted client

                                
   resource.  Why?  It says so that the web-hosted client resources can

                                
   push javascript (or other) back into the UA so it can extract the

                                
   access token in the fragment; but some sort of javascript is already

                                
   running in the browser, since it initiated the authorization request

                                
   in the first place.  So why this extra step?  Why not treat the

                                
   javascript client running in the UA like a native app and handle the

                                
   redirect uri?____

                                
 

                                
   __ __

                                
 

                                
   I know this was well thought out when the spec was written, so

                                
   trying to figure out what I’m missing?____

                                
 

                                
   __ __

                                
 

                                
   __ __

                                
 

                                
   __ __

                                
 

                                
   Tx!

                                
   adam____

                                
 

                                
 

                                
   _______________________________________________

                                
   OAuth mailing list

                                
   OAuth@ietf.org <mailto:OAuth@ietf.org>

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

                                
 

                                
 

                                
 

                                
 

                                
_______________________________________________

                                
OAuth mailing list

                                
OAuth@ietf.org

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

                                
 

                              

                              
--

                              
Bill Burke

                              
JBoss, a division of Red Hat

                              
http://bill.burkecentral.com

                              
 

                              
_______________________________________________

                              
OAuth mailing list

                              
OAuth@ietf.org

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

                            

                          

                          
-- 

                          
Bill Burke

                          
JBoss, a division of Red Hat

                          
http://bill.burkecentral.com

                        

                        


                          

                          

                          

                        
_______________________________________________

                        
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

                    

                  

                

              

            

          

        

      

      

    

    

  


--------------000509050805080701090408--


From nobody Wed Feb 11 15:07:33 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25A21A873E for ; Wed, 11 Feb 2015 15:07:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROy0D-ibqENk for ; Wed, 11 Feb 2015 15:06:54 -0800 (PST)
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBC61A8734 for ; Wed, 11 Feb 2015 15:06:54 -0800 (PST)
Received: by labgm9 with SMTP id gm9so6647291lab.2 for ; Wed, 11 Feb 2015 15:06:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=BPQwdvuqoQrZ/0qzYF2lYZ2xnqr5aa5mKWDqFSVNl8A=; b=ZDH4RNHB6RoGLRStSk081Bg1eG+Fyf2XBdb7HH+yqaevhPnT5dbBofZB3T49gzrVgv Yp56c1j8O1fcS+xgExPQIN6T0ZDOFFgTfIujjcUCltgx1TYMtQxtwEEyfbowlD4q/uo2 hmC6uBK0guHK9OLmxLCSjY6UeW0fdY3nCLSht39L9Xz7kMC3Lp1DYkR4d3hFvYFBJIGX f7w4cl27rccUKtmbpRfgsz0cpdp9cJSiM4p2XvkmPxKWofZmZTCrzmntzifxSGid8XOD RA/f0ij2W6QkCCYHeal6Y0jpLWent2IL4cVIX2khhtMKl3h3DQnid1VwilEq7qjeXF6P gUdw==
MIME-Version: 1.0
X-Received: by 10.112.9.38 with SMTP id w6mr680819lba.113.1423696012054; Wed, 11 Feb 2015 15:06:52 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Wed, 11 Feb 2015 15:06:51 -0800 (PST)
Date: Wed, 11 Feb 2015 18:06:51 -0500
Message-ID: 
From: Kathleen Moriarty 
To: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1134deb81115bd050ed80f27
Archived-At: 
Subject: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Feb 2015 23:07:08 -0000
X-List-Received-Date: Wed, 11 Feb 2015 23:07:08 -0000

--001a1134deb81115bd050ed80f27
Content-Type: text/plain; charset=UTF-8

Thank you for your work on this draft and sorry for the delay in my
review.  Before we progress to IETF last call, I'd like to see what we can
resolve from the list below.   I am looking at the IPR issues to see if we
can resolve the outstanding questions as well.

The Shepherd report says the following:
   The document shepherd has raised concerns regarding the fuzzy description
   of the actors (deployment organization, software API publisher, client
   developer) and their impact on the protocol execution. The working
   group did not seem to worry about these aspects though.

I can see the point after reading the draft.  The interactions are written
much more clearly in the security considerations section than where the
flows are described.  Can something be done to address these concerns?

Section 1.2
Deployment Organization definition:
I highly recommend replacing the phrase "simple cloud deployment" with a
description that accurately reflects what is intended.  If that's within a
single service provider's network, a single data center, or a single hosted
data center, I think it would be more clear.

Section 1.2 nit:
Add the word "be" into the following term definition after "may":
  Software API Publisher
      The organization that defines a particular web accessible API that
      may deployed in one or more deployment environments.

Section 2:

Why isn't a more secure option offered and set as the default for
authentication types? I know I've asked this before and the answer was just
that you can add something to the registry, but setting HTTP Basic as the
default seems like a really bad choice. HOBA is on it's way to becoming an
RFC from the HTTPAuth working group.  HTTPAuth also has an updated version
of Basic that is in IETF last call, but I know you are pointing to the
OAuth 2.0 document, so it would be that document that gets updated and not
this draft.  The new version of HTTP Basic fixes some internationalization
problems and spells out the security issues much more clearly, so it
probably doesn't matter too much to update the reference, but maybe makes
it more clear that basic is not a secure form of authentication.

Can you provide some justification as to why this is okay to set basic as
the default and add that to the draft?  Section 2.3.1 of OAuth 2.0 just
says this MUST be implemented, but that any HTTP schemes can be used.  Why
not register another method and use that instead as the default?  You could
use digest and there is library support.  It's not a great answer, but
slightly better than passwords with basic.  You could register HOBA and use
that instead, the only downside is limited library support at the moment.

Section 2: Contacts:

I noticed privacy is not dealt with until you get to the security
considerations section.  I'd prefer to see it with the definition, stating
the address should be a general help address at the domain rather than
directly to an identifiable individual.  It may be good to set a default
for what this should be for consistency or give an example (think back to
abuse@domain.com)?

Software_id and software_version:
Are there any guidelines as to how these should be represented?  There are
several specifications on software_id (and platform).  Does consistency
here matter or is this just meant to be human readable?
Section 2.2 specifies some metadata values that are to be human readable,
should the above be in the list?  I would expect this list to be
comprehensive for clarity, rather than just examples since there aren't too
many defined here.

Section 3.2.1 & Privacy section
For client_name and client_id and associated information, how is user
privacy affected and what can be done to mitigate concerns?  The definition
should state that this is a public value and that it is specific to the
software, not a person.  You have to get to the security consideration
section before that is clear.  References are fine too, but some more
information is needed in the privacy section.  I'm left with a bunch of
questions:
  Can the client_name and client_id be tied to a person?
  Can the person be tracked by this?
  Can other information be gathered about a system (and it's user) during
this process?
  The information is used to dynamically register clients, what is logged?
  What data is aggregated?
  What can you tell about a client (time, location, travel, other personal
details that may be considered sensitive)?  I don't think this was covered
in the OAuth 2.0 RFC.
  How is this addressed at the authorization server and other points?
  The Security considerations talks about client_id as being short lived,
so they expire, but are these event logged or is that prohibited?

5. Security considerations
The first paragraph is a repeat of text.  Can this just be in one place and
use a pointer to the full text?  I like the requirement, but reading it
once is enough.

-- 

Best regards,
Kathleen

--001a1134deb81115bd050ed80f27
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thank you for your work on this draft and sorry for t=
he delay in my review.=C2=A0 Before we progress to IETF last call, I'd =
like to see what we can resolve from the list below. =C2=A0 I am looking at=
 the IPR issues to see if we can resolve the outstanding questions as well.=


The Shepherd report says =
the following:
=C2=A0 =C2=A0The document=
 shepherd has raised concerns regarding the fuzzy description
=C2=A0 =C2=A0of the actors (deployment organization, =
software API publisher, client=C2=A0
=C2=
=A0 =C2=A0developer) and their impact on the protocol execution. The workin=
g=C2=A0
=C2=A0 =C2=A0group did not seem =
to worry about these aspects though.
I can see the point after reading the =
draft.=C2=A0 The interactions are written much more clearly in the security=
 considerations section than where the flows are described.=C2=A0 Can somet=
hing be done to address these concerns?
=

Section 1.2
Deployment Organization definition:
I highly recommend replacing the phrase "simple cloud deployme=
nt" with a description that accurately reflects what is intended.=C2=
=A0 If that's within a single service provider's network, a single =
data center, or a single hosted data center, I think it would be more clear=
.

Section 1.2 nit:
Add the word "be=
" into the following term definition after "may":
=C2=A0 Software API Publisher
=C2=A0 =C2=A0 =C2=A0 The organization that defines a particu=
lar web accessible API that
=C2=A0 =C2=
=A0 =C2=A0 may deployed in one or more deployment environments.=C2=A0
=


Secti=
on 2:

Why isn't a more secure option offered and set as the default for=
 authentication types? I know I've asked this before and the answer was=
 just that you can add something to the registry, but setting HTTP Basic as=
 the default seems like a really bad choice. HOBA is on it's way to bec=
oming an RFC from the HTTPAuth working group.=C2=A0 HTTPAuth also has an up=
dated version of Basic that is in IETF last call, but I know you are pointi=
ng to the OAuth 2.0 document, so it would be that document that gets update=
d and not this draft.=C2=A0 The new version of HTTP Basic fixes some intern=
ationalization problems and spells out the security issues much more clearl=
y, so it probably doesn't matter too much to update the reference, but =
maybe makes it more clear that basic is not a secure form of authentication=
. =C2=A0

Can you provide some justification as to why this is okay to set b=
asic as the default and add that to the draft?=C2=A0 Section 2.3.1 of OAuth=
 2.0 just says this MUST be implemented, but that any HTTP schemes can be u=
sed.=C2=A0 Why not register another method and use that instead as the defa=
ult?=C2=A0 You could use digest and there is library support.=C2=A0 It'=
s not a great answer, but slightly better than passwords with basic.=C2=A0 =
You could register HOBA and use that instead, the only downside is limited =
library support at the moment.

Section 2: Contacts:

I noticed privacy is no=
t dealt with until you get to the security considerations section.=C2=A0 I&=
#39;d prefer to see it with the definition, stating the address should be a=
 general help address at the domain rather than directly to an identifiable=
 individual.=C2=A0 It may be good to set a default for what this should be =
for consistency or give an example (think back to abuse@domain.com)?

Software_id and software_version:
Are there any guidelines as to how these should=
 be represented?=C2=A0 There are several specifications on software_id (and=
 platform).=C2=A0 Does consistency here matter or is this just meant to be =
human readable?
Section 2.2 specifies so=
me metadata values that are to be human readable, should the above be in th=
e list?=C2=A0 I would expect this list to be comprehensive for clarity, rat=
her than just examples since there aren't too many defined here.
<=
div style=3D"font-size:13px">
Sectio=
n 3.2.1 & Privacy section
For client=
_name and client_id and associated information, how is user privacy affecte=
d and what can be done to mitigate concerns?=C2=A0 The definition should st=
ate that this is a public value and that it is specific to the software, no=
t a person.=C2=A0 You have to get to the security consideration section bef=
ore that is clear.=C2=A0 References are fine too, but some more information=
 is needed in the privacy section.=C2=A0 I'm left with a bunch of quest=
ions:
=C2=A0 Can the client_name and cli=
ent_id be tied to a person?
=C2=A0 Can t=
he person be tracked by this?
=C2=A0 Can=
 other information be gathered about a system (and it's user) during th=
is process? =C2=A0
=C2=A0 The informatio=
n is used to dynamically register clients, what is logged?
=C2=A0 What data is aggregated?
=C2=A0 What can you tell about a client (time, location, travel=
, other personal details that may be considered sensitive)?=C2=A0 I don'=
;t think this was covered in the OAuth 2.0 RFC.
=C2=A0 How is this addressed at the authorization server and other =
points?
=C2=A0 The Security consideratio=
ns talks about client_id as being short lived, so they expire, but are thes=
e event logged or is that prohibited?=C2=A0

5. Security considerations
The first paragraph is a repeat of text.=C2=
=A0 Can this just be in one place and use a pointer to the full text?=C2=A0=
 I like the requirement, but reading it once is enough.=C2=A0

-- 

Best regards,
<=
div>Kathleen



--001a1134deb81115bd050ed80f27--


From nobody Wed Feb 11 20:31:59 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B851A8AC2 for ; Wed, 11 Feb 2015 20:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF0mnNdyIjm4 for ; Wed, 11 Feb 2015 20:31:51 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789791A8A6A for ; Wed, 11 Feb 2015 20:31:51 -0800 (PST)
X-AuditID: 1209190e-f79bb6d0000030e8-db-54dc2cb5ff39
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B5.BA.12520.5BC2CD45; Wed, 11 Feb 2015 23:31:50 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t1C4Vnjb009965; Wed, 11 Feb 2015 23:31:49 -0500
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1C4VleJ032745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Feb 2015 23:31:48 -0500
Message-ID: <54DC2CB1.8090400@mit.edu>
Date: Wed, 11 Feb 2015 23:31:45 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Kathleen Moriarty , "oauth@ietf.org" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040401060801000606090601"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT192mcyfEYHoPk0XDznyLk29fsTkw eeycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGf0velgK5h1mrHjYtpapgfFxL2MXIyeHhICJ xKMHn6BsMYkL99azgdhCAouZJNoWJnYxcgHZGxklzn05zw7h3GaSeD55FzNIFa+AmsS+BZfB OlgEVCWWfJgPFmcDsqevaWECsUUFoiRmn3/AClEvKHFy5hMWEFtEIEXicu8TsHphAXOJ/w/u ANVzAC0IkNjzTRIkzCkQKLH02BywVmaBMInlPx+zT2Dkn4Vk0iwkKQjbVuLO3N3MELa8xPa3 c6BsXYlF21aww8Sbt85mXsDItopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXWC83s0QvNaV0EyMo sDkl+XYwfj2odIhRgINRiYfXY+utECHWxLLiytxDjJIcTEqivHPl7oQI8SXlp1RmJBZnxBeV 5qQWH2KU4GBWEuFlYgLK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ 8K7WBmoULEpNT61Iy8wpQUgzcXCCDOcBGi6tAzK8uCAxtzgzHSJ/ilFRSpw3G6RZACSRUZoH 1wtLPK8YxYFeEebNBKniASYtuO5XQIOZgAZPnHEbZHBJIkJKqoHRbYehG7frwyfnSxftb+FN cTi3IrdVynZBcdZrr2eSSluOuK76NCfSJZrb7tS9Y8mFjvEKd7YIm2RMvntIcFIOi8ex/EmC HemlXKJWhYeSZuUafj8heeh87TWHmZs2f23QiH7o96b6otcHjuk62t82zPKtv3tlV8+DuO9f 1fQYrt/btJpNdPInJZbijERDLeai4kQA3M+9BxcDAAA=
Archived-At: 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Feb 2015 04:31:57 -0000

This is a multi-part message in MIME format.
--------------040401060801000606090601
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Kathleen, thanks for the review. Responses inline, though I'm going to 
let the other authors talk about their sections (deployment org, 
software version, etc) directly.

On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
> Thank you for your work on this draft and sorry for the delay in my 
> review.  Before we progress to IETF last call, I'd like to see what we 
> can resolve from the list below.   I am looking at the IPR issues to 
> see if we can resolve the outstanding questions as well.
>
> The Shepherd report says the following:
>    The document shepherd has raised concerns regarding the fuzzy 
> description
>    of the actors (deployment organization, software API publisher, client
>    developer) and their impact on the protocol execution. The working
>    group did not seem to worry about these aspects though.
>
> I can see the point after reading the draft.  The interactions are 
> written much more clearly in the security considerations section than 
> where the flows are described.  Can something be done to address these 
> concerns?
>
> Section 1.2
> Deployment Organization definition:
> I highly recommend replacing the phrase "simple cloud deployment" with 
> a description that accurately reflects what is intended.  If that's 
> within a single service provider's network, a single data center, or a 
> single hosted data center, I think it would be more clear.
>
> Section 1.2 nit:
> Add the word "be" into the following term definition after "may":
>   Software API Publisher
>       The organization that defines a particular web accessible API that
>       may deployed in one or more deployment environments.

[deferred to original author of this text Phil et. al for better wording]

>
> Section 2:
>
> Why isn't a more secure option offered and set as the default for 
> authentication types? I know I've asked this before and the answer was 
> just that you can add something to the registry, but setting HTTP 
> Basic as the default seems like a really bad choice. HOBA is on it's 
> way to becoming an RFC from the HTTPAuth working group.  HTTPAuth also 
> has an updated version of Basic that is in IETF last call, but I know 
> you are pointing to the OAuth 2.0 document, so it would be that 
> document that gets updated and not this draft.  The new version of 
> HTTP Basic fixes some internationalization problems and spells out the 
> security issues much more clearly, so it probably doesn't matter too 
> much to update the reference, but maybe makes it more clear that basic 
> is not a secure form of authentication.
>
> Can you provide some justification as to why this is okay to set basic 
> as the default and add that to the draft?  Section 2.3.1 of OAuth 2.0 
> just says this MUST be implemented, but that any HTTP schemes can be 
> used.  Why not register another method and use that instead as the 
> default?  You could use digest and there is library support.  It's not 
> a great answer, but slightly better than passwords with basic.  You 
> could register HOBA and use that instead, the only downside is limited 
> library support at the moment.

It was our intent to document the methods already defined for use with 
OAuth and provide a registration mechanism for distinguishing between 
them, not to create new client authentication mechanisms. Digest and 
HOBA simply aren't defined for use with OAuth clients yet. It would be 
simple to do: put the client id in the "username" field and the client 
secret in the "password" field of both algorithms. However, I don't 
believe it's a good idea to conflate those two goals in a single 
specification. We actually had other, more secure definitions in an 
earlier draft of this document (using a JWT signed with a private key or 
a JWT signed with a shared key, specifically), but those were removed in 
order to focus on solving just the client registration problem. I agree 
with that decision of the WG.

As other methods of client authentication are defined in the OAuth 
ecosystem, they can register as valid values in the registry. I think it 
would be a valuable output of this WG to define other client 
authentication mechanisms as a separate draft or an eventual update to 
RFC6749 (or both?).

>
> Section 2: Contacts:
>
> I noticed privacy is not dealt with until you get to the security 
> considerations section.  I'd prefer to see it with the definition, 
> stating the address should be a general help address at the domain 
> rather than directly to an identifiable individual.  It may be good to 
> set a default for what this should be for consistency or give an 
> example (think back to abuse@domain.com )?

The problem that I see with putting it inside the definition is that it 
makes the definition text very long, as the definition sits in a list of 
other metadata items. We could add a forward pointer and an example 
easily enough, though. Or we could move the privacy considerations 
section up as a subsection here, though I don't know if that runs afoul 
of the RFC style guidelines for this new section.

>
> Software_id and software_version:
> Are there any guidelines as to how these should be represented?  There 
> are several specifications on software_id (and platform).  Does 
> consistency here matter or is this just meant to be human readable?
> Section 2.2 specifies some metadata values that are to be human 
> readable, should the above be in the list?  I would expect this list 
> to be comprehensive for clarity, rather than just examples since there 
> aren't too many defined here.
>

[mostly deferred to Phil et. al, but note that software_id and 
software_version are not intended to be human readable and don't need 
the multi-language support]

> Section 3.2.1 & Privacy section
> For client_name and client_id and associated information, how is user 
> privacy affected and what can be done to mitigate concerns?  The 
> definition should state that this is a public value and that it is 
> specific to the software, not a person.  You have to get to the 
> security consideration section before that is clear.  References are 
> fine too, but some more information is needed in the privacy section.  
> I'm left with a bunch of questions:
>   Can the client_name and client_id be tied to a person?
The client name is common across all copies of the software (usually), 
so no worries there. The ID represents an individual piece of software, 
not a person, though if that person is the sole user of the instance of 
software then I believe you're right that there are some privacy 
considerations that we should point that out. However, dynamic 
registration can actually help mitigate this as well, since in the 
normal case (with no software statements) there's no way to correlate 
instances of clients with each other.
>   Can the person be tracked by this?
>   Can other information be gathered about a system (and it's user) 
> during this process?
Nothing gathered about the user during registration, as this happens in 
the back channel outside the user's purview.
>   The information is used to dynamically register clients, what is logged?
>   What data is aggregated?
>   What can you tell about a client (time, location, travel, other 
> personal details that may be considered sensitive)?  I don't think 
> this was covered in the OAuth 2.0 RFC.
>   How is this addressed at the authorization server and other points?
>   The Security considerations talks about client_id as being short 
> lived, so they expire, but are these event logged or is that prohibited?

Many of these questions seem to be completely dependent on the 
implementation of the authorization server, and I'm not really sure how 
(or if) to address them in this draft. Any suggestions would be welcomed 
here.

The client_id *could* be short lived, but they usually aren't. I don't 
see any particular logging or tracking concerns using a dynamic OAuth 
client above using any other piece of software, ever. As such, I don't 
think it requires special calling out here.

>
> 5. Security considerations
> The first paragraph is a repeat of text.  Can this just be in one 
> place and use a pointer to the full text?  I like the requirement, but 
> reading it once is enough.

I think it was less onerous of a repeat when both simply said "use TLS", 
so some refactoring after the expansion of the text makes sense to me. 
Would it be better to have it upfront in the endpoint definition, or in 
the security considerations?

>
> -- 
>
> Best regards,
> Kathleen

Thanks again for your review!

  -- Justin

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


--------------040401060801000606090601
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Kathleen, thanks for the review.
      Responses inline, though I'm going to let the other authors talk
      about their sections (deployment org, software version, etc)
      directly.

      

      On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:

    

    

      
      

        
Thank you for your work on this draft and sorry for the
          delay in my review.  Before we progress to IETF last call, I'd
          like to see what we can resolve from the list below.   I am
          looking at the IPR issues to see if we can resolve the
          outstanding questions as well.

        


          

            
The Shepherd report says the
              following:

            
   The document shepherd has
              raised concerns regarding the fuzzy description

            
   of the actors (deployment
              organization, software API publisher, client 

            
   developer) and their impact
              on the protocol execution. The working 

            
   group did not seem to worry
              about these aspects though.

            


            

            
I can see the point after
              reading the draft.  The interactions are written much more
              clearly in the security considerations section than where
              the flows are described.  Can something be done to address
              these concerns?

            


            

            
Section 1.2

            
Deployment Organization
              definition:

            
I highly recommend replacing the
              phrase "simple cloud deployment" with a description that
              accurately reflects what is intended.  If that's within a
              single service provider's network, a single data center,
              or a single hosted data center, I think it would be more
              clear.

            


            

            
Section 1.2 nit:

            
Add the word "be" into the
              following term definition after "may":

            
  Software API Publisher

            
      The organization that
              defines a particular web accessible API that

            
      may deployed in one or
              more deployment environments. 

            

          

        

      

    

    

    [deferred to original author of this text Phil et. al for better
    wording]

    

    

      

        

          

            


            

            
Section 2:

            


            

            
Why isn't a more secure option
              offered and set as the default for authentication types? I
              know I've asked this before and the answer was just that
              you can add something to the registry, but setting HTTP
              Basic as the default seems like a really bad choice. HOBA
              is on it's way to becoming an RFC from the HTTPAuth
              working group.  HTTPAuth also has an updated version of
              Basic that is in IETF last call, but I know you are
              pointing to the OAuth 2.0 document, so it would be that
              document that gets updated and not this draft.  The new
              version of HTTP Basic fixes some internationalization
              problems and spells out the security issues much more
              clearly, so it probably doesn't matter too much to update
              the reference, but maybe makes it more clear that basic is
              not a secure form of authentication.  

            


            

            
Can you provide some
              justification as to why this is okay to set basic as the
              default and add that to the draft?  Section 2.3.1 of OAuth
              2.0 just says this MUST be implemented, but that any HTTP
              schemes can be used.  Why not register another method and
              use that instead as the default?  You could use digest and
              there is library support.  It's not a great answer, but
              slightly better than passwords with basic.  You could
              register HOBA and use that instead, the only downside is
              limited library support at the moment.

          

        

      

    

    

    It was our intent to document the methods already defined for use
    with OAuth and provide a registration mechanism for distinguishing
    between them, not to create new client authentication mechanisms.
    Digest and HOBA simply aren't defined for use with OAuth clients
    yet. It would be simple to do: put the client id in the "username"
    field and the client secret in the "password" field of both
    algorithms. However, I don't believe it's a good idea to conflate
    those two goals in a single specification. We actually had other,
    more secure definitions in an earlier draft of this document (using
    a JWT signed with a private key or a JWT signed with a shared key,
    specifically), but those were removed in order to focus on solving
    just the client registration problem. I agree with that decision of
    the WG.

    

    As other methods of client authentication are defined in the OAuth
    ecosystem, they can register as valid values in the registry. I
    think it would be a valuable output of this WG to define other
    client authentication mechanisms as a separate draft or an eventual
    update to RFC6749 (or both?). 

    

    

      

        

          

            


            

            
Section 2: Contacts:

            


            

            
I noticed privacy is not dealt
              with until you get to the security considerations
              section.  I'd prefer to see it with the definition,
              stating the address should be a general help address at
              the domain rather than directly to an identifiable
              individual.  It may be good to set a default for what this
              should be for consistency or give an example (think back
              to abuse@domain.com)?

          

        

      

    

    

    The problem that I see with putting it inside the definition is that
    it makes the definition text very long, as the definition sits in a
    list of other metadata items. We could add a forward pointer and an
    example easily enough, though. Or we could move the privacy
    considerations section up as a subsection here, though I don't know
    if that runs afoul of the RFC style guidelines for this new section.
    

    

    

      

        

          

            


            

            
Software_id and
              software_version:

            
Are there any guidelines as to
              how these should be represented?  There are several
              specifications on software_id (and platform).  Does
              consistency here matter or is this just meant to be human
              readable?

            
Section 2.2 specifies some
              metadata values that are to be human readable, should the
              above be in the list?  I would expect this list to be
              comprehensive for clarity, rather than just examples since
              there aren't too many defined here.

            


            

          

        

      

    

    

    [mostly deferred to Phil et. al, but note that software_id and
    software_version are not intended to be human readable and don't
    need the multi-language support]

    

    

      

        

          

            
Section 3.2.1 & Privacy
              section

            
For client_name and client_id
              and associated information, how is user privacy affected
              and what can be done to mitigate concerns?  The definition
              should state that this is a public value and that it is
              specific to the software, not a person.  You have to get
              to the security consideration section before that is
              clear.  References are fine too, but some more information
              is needed in the privacy section.  I'm left with a bunch
              of questions:

            
  Can the client_name and
              client_id be tied to a person?

          

        

      

    

    The client name is common across all copies of the software
    (usually), so no worries there. The ID represents an individual
    piece of software, not a person, though if that person is the sole
    user of the instance of software then I believe you're right that
    there are some privacy considerations that we should point that out.
    However, dynamic registration can actually help mitigate this as
    well, since in the normal case (with no software statements) there's
    no way to correlate instances of clients with each other.

    

      

        

          

            
  Can the person be tracked by
              this?

            
  Can other information be
              gathered about a system (and it's user) during this
              process?  

            

          

        

      

    

    Nothing gathered about the user during registration, as this happens
    in the back channel outside the user's purview.

    

      

        

          

            
  The information is used to
              dynamically register clients, what is logged?

            
  What data is aggregated?

            
  What can you tell about a
              client (time, location, travel, other personal details
              that may be considered sensitive)?  I don't think this was
              covered in the OAuth 2.0 RFC.

            
  How is this addressed at the
              authorization server and other points?

            
  The Security considerations
              talks about client_id as being short lived, so they
              expire, but are these event logged or is that prohibited?
              

            

          

        

      

    

    

    Many of these questions seem to be completely dependent on the
    implementation of the authorization server, and I'm not really sure
    how (or if) to address them in this draft. Any suggestions would be
    welcomed here.

    

    The client_id *could* be short lived, but they usually aren't. I
    don't see any particular logging or tracking concerns using a
    dynamic OAuth client above using any other piece of software, ever.
    As such, I don't think it requires special calling out here.

    

    

      

        

          

            


            

            
5. Security considerations

            
The first paragraph is a repeat
              of text.  Can this just be in one place and use a pointer
              to the full text?  I like the requirement, but reading it
              once is enough. 

            

          

        

      

    

    

    I think it was less onerous of a repeat when both simply said "use
    TLS", so some refactoring after the expansion of the text makes
    sense to me. Would it be better to have it upfront in the endpoint
    definition, or in the security considerations? 

    

    

      

        


        

        -- 

        

          


            
Best regards,

            
Kathleen

          

        

      

    

    

    Thanks again for your review!

    

     -- Justin

    

    

      

      

      

      

      

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


    

    

  


--------------040401060801000606090601--


From nobody Thu Feb 12 11:47:06 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9ED91A1BC9 for ; Thu, 12 Feb 2015 11:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dx6C4dZVEqyz for ; Thu, 12 Feb 2015 11:46:59 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD161A1B6A for ; Thu, 12 Feb 2015 11:46:59 -0800 (PST)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1CJkvFE010458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Feb 2015 19:46:57 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t1CJkuFT012836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 19:46:56 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t1CJkuWt002019; Thu, 12 Feb 2015 19:46:56 GMT
Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Feb 2015 11:46:51 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_9983728F-4A7E-4DCE-977A-34AC19CF914C"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Phil Hunt 
In-Reply-To: <54DC2CB1.8090400@mit.edu>
Date: Thu, 12 Feb 2015 11:46:50 -0800
Message-Id: 
References:  <54DC2CB1.8090400@mit.edu>
To: Justin Richer 
X-Mailer: Apple Mail (2.2070.6)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Feb 2015 19:47:04 -0000

--Apple-Mail=_9983728F-4A7E-4DCE-977A-34AC19CF914C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


Phil

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

> On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
>=20
> Kathleen, thanks for the review. Responses inline, though I'm going to =
let the other authors talk about their sections (deployment org, =
software version, etc) directly.
>=20
> On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
>> Thank you for your work on this draft and sorry for the delay in my =
review.  Before we progress to IETF last call, I'd like to see what we =
can resolve from the list below.   I am looking at the IPR issues to see =
if we can resolve the outstanding questions as well.
>>=20
>> The Shepherd report says the following:
>>    The document shepherd has raised concerns regarding the fuzzy =
description
>>    of the actors (deployment organization, software API publisher, =
client=20
>>    developer) and their impact on the protocol execution. The working=20=

>>    group did not seem to worry about these aspects though.
>>=20
>> I can see the point after reading the draft.  The interactions are =
written much more clearly in the security considerations section than =
where the flows are described.  Can something be done to address these =
concerns?
>>=20
>> Section 1.2
>> Deployment Organization definition:
>> I highly recommend replacing the phrase "simple cloud deployment" =
with a description that accurately reflects what is intended.  If that's =
within a single service provider's network, a single data center, or a =
single hosted data center, I think it would be more clear.
>>=20
>> Section 1.2 nit:
>> Add the word "be" into the following term definition after "may":
>>   Software API Publisher
>>       The organization that defines a particular web accessible API =
that
>>       may deployed in one or more deployment environments.=20
>=20
> [deferred to original author of this text Phil et. al for better =
wording]

[Phil] Agreed with Kathleen=92s suggestion.
>=20
>>=20
>> Section 2:
>>=20
>> Why isn't a more secure option offered and set as the default for =
authentication types? I know I've asked this before and the answer was =
just that you can add something to the registry, but setting HTTP Basic =
as the default seems like a really bad choice. HOBA is on it's way to =
becoming an RFC from the HTTPAuth working group.  HTTPAuth also has an =
updated version of Basic that is in IETF last call, but I know you are =
pointing to the OAuth 2.0 document, so it would be that document that =
gets updated and not this draft.  The new version of HTTP Basic fixes =
some internationalization problems and spells out the security issues =
much more clearly, so it probably doesn't matter too much to update the =
reference, but maybe makes it more clear that basic is not a secure form =
of authentication. =20
>>=20
>> Can you provide some justification as to why this is okay to set =
basic as the default and add that to the draft?  Section 2.3.1 of OAuth =
2.0 just says this MUST be implemented, but that any HTTP schemes can be =
used.  Why not register another method and use that instead as the =
default?  You could use digest and there is library support.  It's not a =
great answer, but slightly better than passwords with basic.  You could =
register HOBA and use that instead, the only downside is limited library =
support at the moment.
>=20
> It was our intent to document the methods already defined for use with =
OAuth and provide a registration mechanism for distinguishing between =
them, not to create new client authentication mechanisms. Digest and =
HOBA simply aren't defined for use with OAuth clients yet. It would be =
simple to do: put the client id in the "username" field and the client =
secret in the "password" field of both algorithms. However, I don't =
believe it's a good idea to conflate those two goals in a single =
specification. We actually had other, more secure definitions in an =
earlier draft of this document (using a JWT signed with a private key or =
a JWT signed with a shared key, specifically), but those were removed in =
order to focus on solving just the client registration problem. I agree =
with that decision of the WG.
>=20
> As other methods of client authentication are defined in the OAuth =
ecosystem, they can register as valid values in the registry. I think it =
would be a valuable output of this WG to define other client =
authentication mechanisms as a separate draft or an eventual update to =
RFC6749 (or both?).=20
>=20
>>=20
>> Section 2: Contacts:
>>=20
>> I noticed privacy is not dealt with until you get to the security =
considerations section.  I'd prefer to see it with the definition, =
stating the address should be a general help address at the domain =
rather than directly to an identifiable individual.  It may be good to =
set a default for what this should be for consistency or give an example =
(think back to abuse@domain.com )?
>=20
> The problem that I see with putting it inside the definition is that =
it makes the definition text very long, as the definition sits in a list =
of other metadata items. We could add a forward pointer and an example =
easily enough, though. Or we could move the privacy considerations =
section up as a subsection here, though I don't know if that runs afoul =
of the RFC style guidelines for this new section.=20
>=20
>>=20
>> Software_id and software_version:
>> Are there any guidelines as to how these should be represented?  =
There are several specifications on software_id (and platform).  Does =
consistency here matter or is this just meant to be human readable?
>> Section 2.2 specifies some metadata values that are to be human =
readable, should the above be in the list?  I would expect this list to =
be comprehensive for clarity, rather than just examples since there =
aren't too many defined here.
>>=20
>=20
> [mostly deferred to Phil et. al, but note that software_id and =
software_version are not intended to be human readable and don't need =
the multi-language support]

[Phil]
I=92ve added some more explanatory text. Note=85some of this may be =
better put elsewhere. =20

As to whether the values are human readable, I have no opinion. What =
matters most is unique matching.

   software_id
      A unique identifier (e.g. UUID) assigned by the developer or =
software publisher
      used by registration endpoints to identify client software to be =
dynamically registered.=20
      Unlike "client_id", which is issued by the authorization server =
and varies between
      instances of software, the "software_id=94 SHOULD remain the same =
for all client software
      instances. The =93software_id=94 SHOULD remain the same across =
multiple software updates=20
      or versions.

software_version
      A version identifier for the software identified by =93software_id".=
  The
      value of this field is a string that is intended to be compared
      using string equality matching. Unlike =93software_id=94, the =
value of the
      "software_version" SHOULD change on any update to the client
      software. A service provider MAY use =93software_id" and =
=93software_version" to=20
      recognize approved software and version combinations approved for =
dynamic registration.

Let me know if you want more background.

>=20
>> Section 3.2.1 & Privacy section
>> For client_name and client_id and associated information, how is user =
privacy affected and what can be done to mitigate concerns?  The =
definition should state that this is a public value and that it is =
specific to the software, not a person.  You have to get to the security =
consideration section before that is clear.  References are fine too, =
but some more information is needed in the privacy section.  I'm left =
with a bunch of questions:
>>   Can the client_name and client_id be tied to a person?
> The client name is common across all copies of the software (usually), =
so no worries there. The ID represents an individual piece of software, =
not a person, though if that person is the sole user of the instance of =
software then I believe you're right that there are some privacy =
considerations that we should point that out. However, dynamic =
registration can actually help mitigate this as well, since in the =
normal case (with no software statements) there's no way to correlate =
instances of clients with each other.
>>   Can the person be tracked by this?
>>   Can other information be gathered about a system (and it's user) =
during this process? =20
> Nothing gathered about the user during registration, as this happens =
in the back channel outside the user's purview.
>>   The information is used to dynamically register clients, what is =
logged?
>>   What data is aggregated?
>>   What can you tell about a client (time, location, travel, other =
personal details that may be considered sensitive)?  I don't think this =
was covered in the OAuth 2.0 RFC.
>>   How is this addressed at the authorization server and other points?
>>   The Security considerations talks about client_id as being short =
lived, so they expire, but are these event logged or is that prohibited?=20=

>=20
> Many of these questions seem to be completely dependent on the =
implementation of the authorization server, and I'm not really sure how =
(or if) to address them in this draft. Any suggestions would be welcomed =
here.
>=20
> The client_id *could* be short lived, but they usually aren't. I don't =
see any particular logging or tracking concerns using a dynamic OAuth =
client above using any other piece of software, ever. As such, I don't =
think it requires special calling out here.
>=20
>>=20
>> 5. Security considerations
>> The first paragraph is a repeat of text.  Can this just be in one =
place and use a pointer to the full text?  I like the requirement, but =
reading it once is enough.=20
>=20
> I think it was less onerous of a repeat when both simply said "use =
TLS", so some refactoring after the expansion of the text makes sense to =
me. Would it be better to have it upfront in the endpoint definition, or =
in the security considerations?=20
>=20
>>=20
>> --=20
>>=20
>> Best regards,
>> Kathleen
>=20
> Thanks again for your review!
>=20
>  -- Justin
>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_9983728F-4A7E-4DCE-977A-34AC19CF914C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252







On Feb 11, 2015, at 8:31 PM, Justin Richer <jricher@mit.edu> =
wrote:


 =20
    
 =20
  

    
Kathleen, thanks for the review.
      Responses inline, though I'm going to let the other authors talk
      about their sections (deployment org, software version, etc)
      directly.

      

      On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:

    

    

      
      

        
Thank you for your work on this draft and sorry =
for the
          delay in my review.  Before we progress to IETF last =
call, I'd
          like to see what we can resolve from the list below.   I =
am
          looking at the IPR issues to see if we can resolve the
          outstanding questions as well.

        


          

            
The Shepherd report =
says the
              following:

            
   The =
document shepherd has
              raised concerns regarding the fuzzy description

            
   of the =
actors (deployment
              organization, software API publisher, client 

            
  =
 developer) and their impact
              on the protocol execution. The working 

            
   group =
did not seem to worry
              about these aspects though.

            


            

            
I can see the point =
after
              reading the draft.  The interactions are written much =
more
              clearly in the security considerations section than where
              the flows are described.  Can something be done to =
address
              these concerns?

            


            

            
Section 1.2

            
Deployment =
Organization
              definition:

            
I highly recommend =
replacing the
              phrase "simple cloud deployment" with a description that
              accurately reflects what is intended.  If that's =
within a
              single service provider's network, a single data center,
              or a single hosted data center, I think it would be more
              clear.

            


            

            
Section 1.2 =
nit:

            
Add the word "be" =
into the
              following term definition after "may":

            
  Software API =
Publisher

            
    =
  The organization that
              defines a particular web accessible API that

            
    =
  may deployed in one or
              more deployment environments. 

            

          

        

      

    

    

    [deferred to original author of this text Phil et. al for better
    wording]

[Phil] Agreed with Kathleen=92s suggestion.

    

    

      

        

          

            


            

            
Section 2:

            


            

            
Why isn't a more =
secure option
              offered and set as the default for authentication types? I
              know I've asked this before and the answer was just that
              you can add something to the registry, but setting HTTP
              Basic as the default seems like a really bad choice. HOBA
              is on it's way to becoming an RFC from the HTTPAuth
              working group.  HTTPAuth also has an updated version =
of
              Basic that is in IETF last call, but I know you are
              pointing to the OAuth 2.0 document, so it would be that
              document that gets updated and not this draft.  The =
new
              version of HTTP Basic fixes some internationalization
              problems and spells out the security issues much more
              clearly, so it probably doesn't matter too much to update
              the reference, but maybe makes it more clear that basic is
              not a secure form of authentication.  

            


            

            
Can you provide =
some
              justification as to why this is okay to set basic as the
              default and add that to the draft?  Section 2.3.1 of =
OAuth
              2.0 just says this MUST be implemented, but that any HTTP
              schemes can be used.  Why not register another method =
and
              use that instead as the default?  You could use =
digest and
              there is library support.  It's not a great answer, =
but
              slightly better than passwords with basic.  You could
              register HOBA and use that instead, the only downside is
              limited library support at the moment.

          

        

      

    

    

    It was our intent to document the methods already defined for use
    with OAuth and provide a registration mechanism for distinguishing
    between them, not to create new client authentication mechanisms.
    Digest and HOBA simply aren't defined for use with OAuth clients
    yet. It would be simple to do: put the client id in the "username"
    field and the client secret in the "password" field of both
    algorithms. However, I don't believe it's a good idea to conflate
    those two goals in a single specification. We actually had other,
    more secure definitions in an earlier draft of this document (using
    a JWT signed with a private key or a JWT signed with a shared key,
    specifically), but those were removed in order to focus on solving
    just the client registration problem. I agree with that decision of
    the WG.

    

    As other methods of client authentication are defined in the OAuth
    ecosystem, they can register as valid values in the registry. I
    think it would be a valuable output of this WG to define other
    client authentication mechanisms as a separate draft or an eventual
    update to RFC6749 (or both?). 

    

    

      

        

          

            


            

            
Section 2: =
Contacts:

            


            

            
I noticed privacy =
is not dealt
              with until you get to the security considerations
              section.  I'd prefer to see it with the definition,
              stating the address should be a general help address at
              the domain rather than directly to an identifiable
              individual.  It may be good to set a default for what =
this
              should be for consistency or give an example (think back
              to abuse@domain.com)?

          

        

      

    

    

    The problem that I see with putting it inside the definition is that
    it makes the definition text very long, as the definition sits in a
    list of other metadata items. We could add a forward pointer and an
    example easily enough, though. Or we could move the privacy
    considerations section up as a subsection here, though I don't know
    if that runs afoul of the RFC style guidelines for this new section.
    

    

    

      

        

          

            


            

            
Software_id and
              software_version:

            
Are there any =
guidelines as to
              how these should be represented?  There are several
              specifications on software_id (and platform).  Does
              consistency here matter or is this just meant to be human
              readable?

            
Section 2.2 =
specifies some
              metadata values that are to be human readable, should the
              above be in the list?  I would expect this list to be
              comprehensive for clarity, rather than just examples since
              there aren't too many defined here.

            


            

          

        

      

    

    

    [mostly deferred to Phil et. al, but note that software_id and
    software_version are not intended to be human readable and don't
    need the multi-language support]

[Phil]
I=92ve added some more =
explanatory text. Note=85some of this may be better put elsewhere. =
 

As to whether the values are =
human readable, I have no opinion. What matters most is unique =
matching.

   software_id
      A unique identifier (e.g. UUID) assigned by the developer or =
software publisher
      =
used by registration endpoints to identify client software to be =
dynamically registered. 
      Unlike "client_id", which is issued by =
the authorization server and varies between
      instances of software, the =
"software_id=94 SHOULD remain the same for all client software
  =
    instances. The =93software_id=94 SHOULD remain the same across multiple software =
updates 
      or versions.

software_version
      A version identifier for the software identified by =93software_id".=
  The
      value of this field is a string that is intended to be compared
      using string equality matching. Unlike =93software_id=94, the =
value of the
      "software_version" SHOULD change on any update to the client
      software. A service provider MAY use =93software_id" and =
=93software_version" to 
      recognize approved software and =
version combinations approved for dynamic registration.

Let me know if you =
want more background.


    

    

      

        

          

            
Section 3.2.1 & =
Privacy
              section

            
For client_name and =
client_id
              and associated information, how is user privacy affected
              and what can be done to mitigate concerns?  The =
definition
              should state that this is a public value and that it is
              specific to the software, not a person.  You have to =
get
              to the security consideration section before that is
              clear.  References are fine too, but some more =
information
              is needed in the privacy section.  I'm left with a =
bunch
              of questions:

            
  Can the =
client_name and
              client_id be tied to a person?

          

        

      

    

    The client name is common across all copies of the software
    (usually), so no worries there. The ID represents an individual
    piece of software, not a person, though if that person is the sole
    user of the instance of software then I believe you're right that
    there are some privacy considerations that we should point that out.
    However, dynamic registration can actually help mitigate this as
    well, since in the normal case (with no software statements) there's
    no way to correlate instances of clients with each other.

    

      

        

          

            
  Can the =
person be tracked by
              this?

            
  Can other =
information be
              gathered about a system (and it's user) during this
              process?  

            

          

        

      

    

    Nothing gathered about the user during registration, as this happens
    in the back channel outside the user's purview.

    

      

        

          

            
  The =
information is used to
              dynamically register clients, what is logged?

            
  What data is =
aggregated?

            
  What can you =
tell about a
              client (time, location, travel, other personal details
              that may be considered sensitive)?  I don't think =
this was
              covered in the OAuth 2.0 RFC.

            
  How is this =
addressed at the
              authorization server and other points?

            
  The Security =
considerations
              talks about client_id as being short lived, so they
              expire, but are these event logged or is that prohibited?
              

            

          

        

      

    

    

    Many of these questions seem to be completely dependent on the
    implementation of the authorization server, and I'm not really sure
    how (or if) to address them in this draft. Any suggestions would be
    welcomed here.

    

    The client_id *could* be short lived, but they usually aren't. I
    don't see any particular logging or tracking concerns using a
    dynamic OAuth client above using any other piece of software, ever.
    As such, I don't think it requires special calling out here.

    

    

      

        

          

            


            

            
5. Security =
considerations

            
The first paragraph =
is a repeat
              of text.  Can this just be in one place and use a =
pointer
              to the full text?  I like the requirement, but =
reading it
              once is enough. 

            

          

        

      

    

    

    I think it was less onerous of a repeat when both simply said "use
    TLS", so some refactoring after the expansion of the text makes
    sense to me. Would it be better to have it upfront in the endpoint
    definition, or in the security considerations? 

    

    

      

        


        

        -- 

        

          


            
Best regards,

            
Kathleen

          

        

      

    

    

    Thanks again for your review!

    

     -- Justin

    

    

      

      

      

      

      

      
_______________________________________________
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=_9983728F-4A7E-4DCE-977A-34AC19CF914C--


From nobody Sat Feb 14 03:40:23 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA611A1BDD for ; Sat, 14 Feb 2015 03:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrXj8r8ObgdS for ; Sat, 14 Feb 2015 03:40:18 -0800 (PST)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27B81A1B6A for ; Sat, 14 Feb 2015 03:40:17 -0800 (PST)
Received: by mail-ob0-f181.google.com with SMTP id vb8so28686144obc.12 for ; Sat, 14 Feb 2015 03:40:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=E8ozAhzzh0Rrz+QUvTqoeLHnJGq52q+4XYjriL39r40=; b=m9OwOtJH4lNNBu3A3xcvsbnXMB8FRmGOZn1Sw9YZk0Ri1aXNY9+Xn0XVYAkVuFUnyG b0cP+zDhcnxp9FkHZvQqpE1MBOzBf527RV1VUhOw6e8fr+9pzc8aFdyKGuVaWQcUkgpD 1p1vWmmnpP3zMM/tC9O6gD3hD/8KA0ridUqvvnCVYlW+UBO7L2auGBy9+d3fNF08qh6j 7yN3mw+FXeim6zuCLlit6xiN1izCX0T8JQsnXAGyour84aAmpF5KpGG9t769O+EHFwAS y1RiFmMudbKl/YzMP4pPWhaIUpnU5nDo8TGIbsaOE1M8mP/cSUN7PzaBIGB7PxSOIsFW ML2A==
MIME-Version: 1.0
X-Received: by 10.60.133.20 with SMTP id oy20mr9286852oeb.55.1423914016970; Sat, 14 Feb 2015 03:40:16 -0800 (PST)
Received: by 10.202.168.143 with HTTP; Sat, 14 Feb 2015 03:40:16 -0800 (PST)
Date: Sat, 14 Feb 2015 16:40:16 +0500
Message-ID: 
From: Security Developer 
To: oauth@ietf.org, ve7jtb@ve7jtb.com
Content-Type: multipart/alternative; boundary=047d7b47204e2c1ec1050f0ad19e
Archived-At: 
Subject: [OAUTH-WG] OAuth POP query
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Feb 2015 11:40:19 -0000

--047d7b47204e2c1ec1050f0ad19e
Content-Type: text/plain; charset=UTF-8

Hi,

I have a couple of questions.

1- What is the status of these documents as I am interested in implementing
POP

draft-ietf-oauth-pop-architecture-00.pdf
draft-ietf-oauth-pop-key-distribution-00.pdf
draft-ietf-oauth-proof-of-possession-00.pdf
draft-ietf-oauth-signed-http-request-00.pdf

2- Should Authorization server restrict the number of authorization codes
issued to a single user after successful authentication and authorization
in OAuth? also What is the good practice in this case?

Thanks for your time.

--047d7b47204e2c1ec1050f0ad19e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I have a couple of questions.

1- What is=
 the status of these documents as I am interested in implementing POP 
<=
br>draft-ietf-oauth-pop-architecture-00.pdf
draft-ietf-oauth-pop-key-dis=
tribution-00.pdf
draft-ietf-oauth-proof-of-possession-00.pdf
draft-ie=
tf-oauth-signed-http-request-00.pdf

2- Should Authorization server r=
estrict the number of authorization codes issued to a single user after suc=
cessful authentication and authorization in OAuth? also What is the good pr=
actice in this case?

Thanks for your time.


--047d7b47204e2c1ec1050f0ad19e--


From nobody Sun Feb 15 19:55:27 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633F51A8739 for ; Sun, 15 Feb 2015 19:55:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.212
X-Spam-Level: 
X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLTgh2s5_PTV for ; Sun, 15 Feb 2015 19:55:21 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D061A8734 for ; Sun, 15 Feb 2015 19:55:21 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1G3tKnD013443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sun, 15 Feb 2015 22:55:21 -0500
Received: from [10.10.48.231] (vpn-48-231.rdu2.redhat.com [10.10.48.231]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1G3tKiC025908 for ; Sun, 15 Feb 2015 22:55:20 -0500
Message-ID: <54E16A28.4050508@redhat.com>
Date: Sun, 15 Feb 2015 22:55:20 -0500
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: oauth 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: 
Subject: [OAUTH-WG] user impersonation protocol?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Feb 2015 03:55:24 -0000

We have a case where we want to allow a logged in admin user to 
impersonate another user so that they can visit differents browser apps 
as that user (So they can see everything that the user sees through 
their browser).

Anybody know of any protocol work being done here in the OAuth group or 
some other IETF or even Connect effort that would support something like 
this?

Thanks,

Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Sun Feb 15 20:34:38 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DE81A8734 for ; Sun, 15 Feb 2015 20:34:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUNvp8HOfEvX for ; Sun, 15 Feb 2015 20:34:35 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D431A8732 for ; Sun, 15 Feb 2015 20:34:33 -0800 (PST)
X-AuditID: 12074423-f79066d0000058b8-00-54e173580125
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 00.68.22712.85371E45; Sun, 15 Feb 2015 23:34:32 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t1G4YV7m004473; Sun, 15 Feb 2015 23:34:32 -0500
Received: from [IPv6:2607:fb90:2900:4e6f:0:3f:cc3e:f201] ([172.56.22.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1G4YTk0002528 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 15 Feb 2015 23:34:30 -0500
Date: Sun, 15 Feb 2015 23:34:28 -0500
Message-ID: <45p14og69nr08nthyis1k9x1.1424061268466@email.android.com>
Importance: normal
From: Justin Richer 
To: Bill Burke , oauth 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.android.email_236089447748900"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nrhtR/DDEoHO1mkXv1p2MFiffvmJz YPJYsuQnk8f7fVfZApiiuGxSUnMyy1KL9O0SuDLeLj7MWrBSqeJB/wymBsa5il2MnBwSAiYS yw/PZYKwxSQu3FvP1sXIxSEksJhJ4sHd+cwQzkZGietrLjNBOHuYJDZtXc7axcjBwSKgKjH5 eTpItzDQpJOf57CA2LwCbhKTZ6xkAinhFBCS6NolARJmA6qevqYFbJmIgJXEt43PoMoFJU7O fAJmMwuESJxp3cQ2gZF3FpLULCQpCFtd4s+8S8wQtqLElO6H7LOAtjELqEksa1VCFl7AyLaK UTYlt0o3NzEzpzg1Wbc4OTEvL7VI10wvN7NELzWldBMjOEhdlHcw/jmodIhRgINRiYf3hezD ECHWxLLiytxDjJIcTEqivFUuQCG+pPyUyozE4oz4otKc1OJDjBIczEoivMfCgHK8KYmVValF +TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8bwqBGgWLUtNTK9Iyc0oQ0kwcnCDD eYCGTwap4S0uSMwtzkyHyJ9iVJQS530MkhAASWSU5sH1wpLIK0ZxoFeEef+DVPEAExBc9yug wUxAgzOZ74MMLklESEk1MJ6NLr6p6hR9x9XzhPWaS8o5vPu4CnWsFlx/ZMfwW7I39dMzcxvv JSY7k592ht5yZvvc9O5SyddbCvMbPCRXces29ax5Yze7J9F/etvsM6cfO57NP9jz4q2/ZHiW 2onNT/sPF21YfFatX37fnQlfU7dNWSCp8jJqjlXRj0ofHf9FuhksIiyKckosxRmJhlrMRcWJ AB2TScX9AgAA
Archived-At: 
Subject: Re: [OAUTH-WG] user impersonation protocol?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Feb 2015 04:34:37 -0000

----_com.android.email_236089447748900
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

Rm9yIHRoaXMgY2FzZSB5b3UnZCB3YW50IHRvIGJlIHZlcnkgY2FyZWZ1bCBhYm91dCB3aG8gd2Fz
IGFibGUgdG8gZG8gc3VjaCBpbXBlcnNvbmF0aW9uLCBvYnZpb3VzbHksIGJ1dCBpdCdzIGRvYWJs
ZSB0b2RheSB3aXRoIGN1c3RvbSBJZFAgYmVoYXZpb3IuwqBZb3UgY2FuIHNpbXBseSB1c2UgT3Bl
bklEIENvbm5lY3QgYW5kIGhhdmUgdGhlIElkUCBpc3N1ZSBhbiBpZCB0b2tlbiBmb3IgdGhlIHRh
cmdldCB1c2VyIGluc3RlYWQgb2YgdGhlICJhY3R1YWwiIGN1cnJlbnQgdXNlciBhY2NvdW50LsKg
CgpJIHdvdWxkIGFsc28gc3VnZ2VzdCBjb25zaWRlcmluZyBhZGRpbmcgYSBjdXN0b20gY2xhaW0g
dG8gdGhlIGlkIHRva2VuIHRvIGluZGljYXRlIHRoaXMgaXMgdGFraW5nIHBsYWNlLiBUaGF0IHdh
eSB5b3UgY2FuIGRpZmZlcmVudGlhdGUgd2hlcmUgbmVlZGVkLCBpbmNsdWRpbmcgaW4gbG9ncy4K
Ci0tIEp1c3RpbgoKLyBTZW50IGZyb20gbXkgcGhvbmUgLwoKCi0tLS0tLS0tIE9yaWdpbmFsIG1l
c3NhZ2UgLS0tLS0tLS0KRnJvbTogQmlsbCBCdXJrZSA8YmJ1cmtlQHJlZGhhdC5jb20+IApEYXRl
OjAyLzE1LzIwMTUgIDEwOjU1IFBNICAoR01ULTA1OjAwKSAKVG86IG9hdXRoIDxvYXV0aEBpZXRm
Lm9yZz4gCkNjOiAgClN1YmplY3Q6IFtPQVVUSC1XR10gdXNlciBpbXBlcnNvbmF0aW9uIHByb3Rv
Y29sPyAKCldlIGhhdmUgYSBjYXNlIHdoZXJlIHdlIHdhbnQgdG8gYWxsb3cgYSBsb2dnZWQgaW4g
YWRtaW4gdXNlciB0byAKaW1wZXJzb25hdGUgYW5vdGhlciB1c2VyIHNvIHRoYXQgdGhleSBjYW4g
dmlzaXQgZGlmZmVyZW50cyBicm93c2VyIGFwcHMgCmFzIHRoYXQgdXNlciAoU28gdGhleSBjYW4g
c2VlIGV2ZXJ5dGhpbmcgdGhhdCB0aGUgdXNlciBzZWVzIHRocm91Z2ggCnRoZWlyIGJyb3dzZXIp
LgoKQW55Ym9keSBrbm93IG9mIGFueSBwcm90b2NvbCB3b3JrIGJlaW5nIGRvbmUgaGVyZSBpbiB0
aGUgT0F1dGggZ3JvdXAgb3IgCnNvbWUgb3RoZXIgSUVURiBvciBldmVuIENvbm5lY3QgZWZmb3J0
IHRoYXQgd291bGQgc3VwcG9ydCBzb21ldGhpbmcgbGlrZSAKdGhpcz8KClRoYW5rcywKCkJpbGwK
Ci0tIApCaWxsIEJ1cmtlCkpCb3NzLCBhIGRpdmlzaW9uIG9mIFJlZCBIYXQKaHR0cDovL2JpbGwu
YnVya2VjZW50cmFsLmNvbQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KT0F1dGggbWFpbGluZyBsaXN0Ck9BdXRoQGlldGYub3JnCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgK

----_com.android.email_236089447748900
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5Gb3IgdGhpcyBjYXNlIHlv
dSdkIHdhbnQgdG8gYmUgdmVyeSBjYXJlZnVsIGFib3V0IHdobyB3YXMgYWJsZSB0byBkbyBzdWNo
IGltcGVyc29uYXRpb24sIG9idmlvdXNseSwgYnV0IGl0J3MgZG9hYmxlIHRvZGF5IHdpdGggY3Vz
dG9tIElkUCBiZWhhdmlvci4mbmJzcDtZb3UgY2FuIHNpbXBseSB1c2UgT3BlbklEIENvbm5lY3Qg
YW5kIGhhdmUgdGhlIElkUCBpc3N1ZSBhbiBpZCB0b2tlbiBmb3IgdGhlIHRhcmdldCB1c2VyIGlu
c3RlYWQgb2YgdGhlICJhY3R1YWwiIGN1cnJlbnQgdXNlciBhY2NvdW50LiZuYnNwOzwvZGl2Pjxk
aXY+PGJyPjwvZGl2PjxkaXY+SSB3b3VsZCBhbHNvIHN1Z2dlc3QgY29uc2lkZXJpbmcgYWRkaW5n
IGEgY3VzdG9tIGNsYWltIHRvIHRoZSBpZCB0b2tlbiB0byBpbmRpY2F0ZSB0aGlzIGlzIHRha2lu
ZyBwbGFjZS4gVGhhdCB3YXkgeW91IGNhbiBkaWZmZXJlbnRpYXRlIHdoZXJlIG5lZWRlZCwgaW5j
bHVkaW5nIGluIGxvZ3MuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXpl
OjlweCI+PGRpdiBzdHlsZT0iZm9udC1zaXplOiA5cHg7ICI+LS0gSnVzdGluPC9kaXY+PGRpdiBz
dHlsZT0iZm9udC1zaXplOiA5cHg7ICI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTog
OXB4OyAiPi8gU2VudCBmcm9tIG15IHBob25lIC88L2Rpdj48L2Rpdj48ZGl2PjwvZGl2PjxkaXY+
PC9kaXY+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPkZyb206
IEJpbGwgQnVya2UgJmx0O2JidXJrZUByZWRoYXQuY29tJmd0OyA8YnI+RGF0ZTowMi8xNS8yMDE1
ICAxMDo1NSBQTSAgKEdNVC0wNTowMCkgPGJyPlRvOiBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcm
Z3Q7IDxicj5DYzogIDxicj5TdWJqZWN0OiBbT0FVVEgtV0ddIHVzZXIgaW1wZXJzb25hdGlvbiBw
cm90b2NvbD8gPGJyPjxicj5XZSBoYXZlIGEgY2FzZSB3aGVyZSB3ZSB3YW50IHRvIGFsbG93IGEg
bG9nZ2VkIGluIGFkbWluIHVzZXIgdG8gPGJyPmltcGVyc29uYXRlIGFub3RoZXIgdXNlciBzbyB0
aGF0IHRoZXkgY2FuIHZpc2l0IGRpZmZlcmVudHMgYnJvd3NlciBhcHBzIDxicj5hcyB0aGF0IHVz
ZXIgKFNvIHRoZXkgY2FuIHNlZSBldmVyeXRoaW5nIHRoYXQgdGhlIHVzZXIgc2VlcyB0aHJvdWdo
IDxicj50aGVpciBicm93c2VyKS48YnI+PGJyPkFueWJvZHkga25vdyBvZiBhbnkgcHJvdG9jb2wg
d29yayBiZWluZyBkb25lIGhlcmUgaW4gdGhlIE9BdXRoIGdyb3VwIG9yIDxicj5zb21lIG90aGVy
IElFVEYgb3IgZXZlbiBDb25uZWN0IGVmZm9ydCB0aGF0IHdvdWxkIHN1cHBvcnQgc29tZXRoaW5n
IGxpa2UgPGJyPnRoaXM/PGJyPjxicj5UaGFua3MsPGJyPjxicj5CaWxsPGJyPjxicj4tLSA8YnI+
QmlsbCBCdXJrZTxicj5KQm9zcywgYSBkaXZpc2lvbiBvZiBSZWQgSGF0PGJyPmh0dHA6Ly9iaWxs
LmJ1cmtlY2VudHJhbC5jb208YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPk9BdXRoIG1haWxpbmcgbGlzdDxicj5PQXV0aEBpZXRmLm9yZzxi
cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPjwvYm9keT48
L2h0bWw+

----_com.android.email_236089447748900--



From nobody Sun Feb 15 21:37:46 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92631A8739 for ; Sun, 15 Feb 2015 21:37:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.509
X-Spam-Level: 
X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqOW9AJXS1qX for ; Sun, 15 Feb 2015 21:37:42 -0800 (PST)
Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330591A8734 for ; Sun, 15 Feb 2015 21:37:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1424065061; bh=8/tFraacyNhiBHIuySDsCSC9oqduSJ7knTcbXgBDqlo=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=N17fbgASU9xC1qJQ2fdoLnY352ex++523WcwXDZqCxWBiG7rPzCMTms0u9h5CStlZ0PbanpTVGE7tlJmyyWnH1tZM0F7Rl6PTB6wjyLW941OtjD5x1HX+Jz+uSCxFMZIV0t33CGD/4cD+RUz0pydsLpUsbhAMHVdL9DHNkD0ZanNJF5oJHzm5YBdyVe4r1uZq+EuGXXJh/sdtY/tYLRa/KeCRlNkeNdfLhuBK6a32/LGfy4WVLW8shy9YTVbnt92YQQhhMX9MOx57PCkzVZFQsOWgRE+NK48PW0zprzsHV7MP8c9pZpXvwmZLPhnAyovrp+JKlK4aSIZor2AL8qFuw==
Received: from [66.196.81.172] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2015 05:37:41 -0000
Received: from [98.139.212.229] by tm18.bullet.mail.bf1.yahoo.com with NNFMP;  16 Feb 2015 05:37:41 -0000
Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP; 16 Feb 2015 05:37:41 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 274141.18224.bm@omp1038.mail.bf1.yahoo.com
X-YMail-OSG: reAsBGMVM1lUi.18xmP7DLTyddm6Lo4CFqu_IoCDV4Uqy5ZiVJmo3Z8gSebGLCN nWVv4N_iKXx7XS2PCE6WfFaDEfnt_mOrEzSA0kQsgGQo.a4csqeVCTv4xTSGWlNxaz1DK83oPgGX uJ9im6UsQM0.d29_Wp1CdGlMwxB6DOQpLpfWXbMu2W4Ke4LStTRrirzoffTqgNaxOa33O04WP_X4 VRKNVmru2zvrr_ABraBWFBO9kYewnWRp8yUwH3BEd3QBtOlSHE4XjdE2rRKwcByGckBYbingAYgm 0gNb0R8CfxpNbykEotAg7w8YP378gSLyVMFFirCjNZQz_s4l4YfZU6iy0XM3VtTHHltmH_8z5hlm 2SrM_1B0CQ4TVM8XvMRexYq0z72j3OsK7mvdH.iefnArZqiHfCkf5q5zUae35E2hjt0NAf5F7pmp 6SbJzWyk7rRwWPOqrprTxT1yOwcz6Rg7RBB7azgjcAwkbKQPLKAjkXFKfHEiN90eYqFB1zySaSMl SpbjN2C2rMTSHB2hHlO_LqnX0Ck1u_9cJXyOAC.M6LX15EorFfutJPxKUcsUGiRUgg96hEajrBhj _FBho7C6hkc0m3UQmhnuBcR.71pASVxJKYTBG3.BD
Received: by 66.196.80.147; Mon, 16 Feb 2015 05:37:40 +0000 
Date: Mon, 16 Feb 2015 05:37:40 +0000 (UTC)
From: Bill Mills 
To: Justin Richer , Bill Burke ,  oauth 
Message-ID: <790334746.6689293.1424065060482.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <45p14og69nr08nthyis1k9x1.1424061268466@email.android.com>
References: <45p14og69nr08nthyis1k9x1.1424061268466@email.android.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_6689292_731674102.1424065060476"
Archived-At: 
Subject: Re: [OAUTH-WG] user impersonation protocol?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Feb 2015 05:37:44 -0000

------=_Part_6689292_731674102.1424065060476
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

User impersonation is very very risky. =C2=A0The legal aspects of it must b=
e considered. =C2=A0There's a lot of work to do to make it safe/effective.
Issuing a scoped token that allows ready only access can work with the abov=
e caveats. =C2=A0Then properties/componenets have to explicitly support the=
 new scope and do the right thing.=20

     On Sunday, February 15, 2015 8:34 PM, Justin Richer  =
wrote:
  =20

 For this case you'd want to be very careful about who was able to do such =
impersonation, obviously, but it's doable today with custom IdP behavior.=
=C2=A0You can simply use OpenID Connect and have the IdP issue an id token =
for the target user instead of the "actual" current user account.=C2=A0
I would also suggest considering adding a custom claim to the id token to i=
ndicate this is taking place. That way you can differentiate where needed, =
including in logs.
-- Justin
/ Sent from my phone /

-------- Original message --------
From: Bill Burke =20
Date:02/15/2015 10:55 PM (GMT-05:00)=20
To: oauth =20
Cc:=20
Subject: [OAUTH-WG] user impersonation protocol?=20

We have a case where we want to allow a logged in admin user to=20
impersonate another user so that they can visit differents browser apps=20
as that user (So they can see everything that the user sees through=20
their browser).

Anybody know of any protocol work being done here in the OAuth group or=20
some other IETF or even Connect effort that would support something like=20
this?

Thanks,

Bill

--=20
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

_______________________________________________
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


   
------=_Part_6689292_731674102.1424065060476
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


User impersonation is very very=
 risky.  The legal aspects of it must be considered.  There's a l=
ot of work to do to make it safe/effective.

Issuing a scoped token that allows ready only access can w=
ork with the above caveats.  Then properties/componenets have to expli=
citly support the new scope and do the right thing.
 


 
 
 
  On Sunday, February 15, 2015 8:34 PM, Justin Richer <jricher@mit=
.edu> wrote:
  
  

 
For this case you'd want to be very ca=
reful about who was able to do such impersonation, obviously, but it's doab=
le today with custom IdP behavior. You can simply use OpenID Connect a=
nd have the IdP issue an id token for the target user instead of the "actua=
l" current user account. 

I would also sugges=
t considering adding a custom claim to the id token to indicate this is tak=
ing place. That way you can differentiate where needed, including in logs.<=
/div>

-- Justin

/ Sent from my phone /

=

-------- Original message --------
From: Bill Burke <bburke@redha=
t.com> 
Date:02/15/2015  10:55 PM  (GMT-05:00) 
To: oauth <oaut=
h@ietf.org> 
Cc:  
Subject: [OAUTH-WG] user impersonation protocol=
? 

We have a case where we want to allow a logged in admin user to <=
br>impersonate another user so that they can visit differents browser apps =

as that user (So they can see everything that the user sees through their browser).

Anybody know of any protocol work being done here i=
n the OAuth group or 
some other IETF or even Connect effort that would =
support something like 
this?

Thanks,

Bill

-- 
B=
ill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
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

  
 
  
 

------=_Part_6689292_731674102.1424065060476--


From nobody Mon Feb 16 07:20:34 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EFB1A1BBB for ; Mon, 16 Feb 2015 07:20:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQzFMvwkkExo for ; Mon, 16 Feb 2015 07:20:19 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2411A1BFB for ; Mon, 16 Feb 2015 07:20:19 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1GFKJu6006067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 16 Feb 2015 10:20:19 -0500
Received: from [10.10.48.231] (vpn-48-231.rdu2.redhat.com [10.10.48.231]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1GFKItN016044; Mon, 16 Feb 2015 10:20:18 -0500
Message-ID: <54E20AB2.6070300@redhat.com>
Date: Mon, 16 Feb 2015 10:20:18 -0500
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Bill Mills , Justin Richer , oauth 
References: <45p14og69nr08nthyis1k9x1.1424061268466@email.android.com> <790334746.6689293.1424065060482.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <790334746.6689293.1424065060482.JavaMail.yahoo@mail.yahoo.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: 
Subject: Re: [OAUTH-WG] user impersonation protocol?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Feb 2015 15:20:26 -0000

Yeah, I know its risky, but that's the requirement.  Was just wondering 
if there was any protocol work being done around it, so that we could 
avoid doing a lot of the legwork to make it safe/effective.  Currently 
for us, we need to do this between two separate IDPs, which is where the 
protocol work comes in...If it was just a single IDP managing 
everything, then it would just be an internal custom IDP feature.

Thanks all.



On 2/16/2015 12:37 AM, Bill Mills wrote:
> User impersonation is very very risky.  The legal aspects of it must be
> considered.  There's a lot of work to do to make it safe/effective.
>
> Issuing a scoped token that allows ready only access can work with the
> above caveats.  Then properties/componenets have to explicitly support
> the new scope and do the right thing.
>
>
> On Sunday, February 15, 2015 8:34 PM, Justin Richer  wrote:
>
>
> For this case you'd want to be very careful about who was able to do
> such impersonation, obviously, but it's doable today with custom IdP
> behavior. You can simply use OpenID Connect and have the IdP issue an id
> token for the target user instead of the "actual" current user account.
>
> I would also suggest considering adding a custom claim to the id token
> to indicate this is taking place. That way you can differentiate where
> needed, including in logs.
>
> -- Justin
>
> / Sent from my phone /
>
>
> -------- Original message --------
> From: Bill Burke 
> Date:02/15/2015 10:55 PM (GMT-05:00)
> To: oauth 
> Cc:
> Subject: [OAUTH-WG] user impersonation protocol?
>
> We have a case where we want to allow a logged in admin user to
> impersonate another user so that they can visit differents browser apps
> as that user (So they can see everything that the user sees through
> their browser).
>
> Anybody know of any protocol work being done here in the OAuth group or
> some other IETF or even Connect effort that would support something like
> this?
>
> Thanks,
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> 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
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Mon Feb 16 07:36:24 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9451A88BD for ; Mon, 16 Feb 2015 07:36:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGiOAFpS_XUG for ; Mon, 16 Feb 2015 07:36:08 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E74E1A1BF6 for ; Mon, 16 Feb 2015 07:35:58 -0800 (PST)
X-AuditID: 12074423-f79066d0000058b8-08-54e20e5d8d6e
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 12.DC.22712.D5E02E45; Mon, 16 Feb 2015 10:35:57 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t1GFZuZw020214; Mon, 16 Feb 2015 10:35:57 -0500
Received: from [IPv6:2607:fb90:e13:ba92:0:1d:88d0:f001] ([172.56.23.249]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1GFZrGZ015180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 16 Feb 2015 10:35:55 -0500
Date: Mon, 16 Feb 2015 10:35:53 -0500
Message-ID: 
Importance: normal
From: Justin Richer 
To: Bill Burke , Bill Mills , oauth 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.android.email_337188575429600"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixG6nohvL9yjE4GaLskXv1p2MFiffvmKz +NZ1ndmB2WPJkp9MHu/3XWXzmDXrMFMAcxSXTUpqTmZZapG+XQJXxumtP9gLPnpVzJv9hLWB 8aFHFyMnh4SAicTzFf3sELaYxIV769m6GLk4hAQWM0n8fPWAGcLZyCjRtnYXE4Szm0li79TV LCAtLAKqEodffmUCsYWBRp2d+YUNxOYVcJP48e0AYxcjBwengJBE1y4JkDAbUPn0NS1g5SIC GRJNX44wQ5QLSpyc+QRsJLNAiMSceafYJzDyzkKSmoUkBWGrS/yZd4kZwlaUmNL9ECjOAWSr SSxrVUIWXsDItopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXTC83s0QvNaV0EyM4dF2UdzD+Oah0 iFGAg1GJh/eF7MMQIdbEsuLK3EOMkhxMSqK8c7kehQjxJeWnVGYkFmfEF5XmpBYfYpTgYFYS 4V32HqicNyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCdwUP0FDBotT0 1Iq0zJwShDQTByfIcB6g4adBaniLCxJzizPTIfKnGBWlxHmvgCQEQBIZpXlwvbDU8opRHOgV Yd5fIFU8wLQE1/0KaDAT0OBM5vsgg0sSEVJSDYxiX1yMNxrNWC8060XgrnXpXNnc5r5+sYru 0v9XNjQ4CS45kJOpnym6qV/jl7tH7n9GKcVv210f2xhJ7lN6dvfhcZETvA0MazvaGjzL5K4s n8z+gutCjPhZ/0/P7e/JWMye4GGRM23J0eVbQu2nvtinekM74tHLn4tF/G4fTCueqX7o256n C3cqsRRnJBpqMRcVJwIA35uI7AgDAAA=
Archived-At: 
Subject: Re: [OAUTH-WG] user impersonation protocol?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Feb 2015 15:36:11 -0000

----_com.android.email_337188575429600
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

QW5vdGhlciBxdWVzdGlvbiBpcyB3aGV0aGVyIG9yIG5vdCB5b3UgY2FuIHVzZXIgcmlnaHRzIGRl
bGVnYXRpb24gKGllIHZhbmlsbGEgT0F1dGgpIG9yIGlmIHlvdSByZWFsbHkgZG8gbmVlZCBpbXBl
cnNvbmF0aW9uLiBZb3UgbWF5IGJlIGFibGUgdG8gZ2V0IHRoZSBkZXNpcmVkIHJlc3VsdHMgd2l0
aCBsZXNzIGNvbXBsZXhpdHkgdGhhdCB3YXkuCgoKLS0gSnVzdGluCgovIFNlbnQgZnJvbSBteSBw
aG9uZSAvCgoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tOiBCaWxsIEJ1
cmtlIDxiYnVya2VAcmVkaGF0LmNvbT4gCkRhdGU6MDIvMTYvMjAxNSAgMTA6MjAgQU0gIChHTVQt
MDU6MDApIApUbzogQmlsbCBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4sIEp1c3RpbiBS
aWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4gCkNjOiAgClN1
YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHVzZXIgaW1wZXJzb25hdGlvbiBwcm90b2NvbD8gCgpZZWFo
LCBJIGtub3cgaXRzIHJpc2t5LCBidXQgdGhhdCdzIHRoZSByZXF1aXJlbWVudC4gIFdhcyBqdXN0
IHdvbmRlcmluZyAKaWYgdGhlcmUgd2FzIGFueSBwcm90b2NvbCB3b3JrIGJlaW5nIGRvbmUgYXJv
dW5kIGl0LCBzbyB0aGF0IHdlIGNvdWxkIAphdm9pZCBkb2luZyBhIGxvdCBvZiB0aGUgbGVnd29y
ayB0byBtYWtlIGl0IHNhZmUvZWZmZWN0aXZlLiAgQ3VycmVudGx5IApmb3IgdXMsIHdlIG5lZWQg
dG8gZG8gdGhpcyBiZXR3ZWVuIHR3byBzZXBhcmF0ZSBJRFBzLCB3aGljaCBpcyB3aGVyZSB0aGUg
CnByb3RvY29sIHdvcmsgY29tZXMgaW4uLi5JZiBpdCB3YXMganVzdCBhIHNpbmdsZSBJRFAgbWFu
YWdpbmcgCmV2ZXJ5dGhpbmcsIHRoZW4gaXQgd291bGQganVzdCBiZSBhbiBpbnRlcm5hbCBjdXN0
b20gSURQIGZlYXR1cmUuCgpUaGFua3MgYWxsLgoKCgpPbiAyLzE2LzIwMTUgMTI6MzcgQU0sIEJp
bGwgTWlsbHMgd3JvdGU6Cj4gVXNlciBpbXBlcnNvbmF0aW9uIGlzIHZlcnkgdmVyeSByaXNreS4g
IFRoZSBsZWdhbCBhc3BlY3RzIG9mIGl0IG11c3QgYmUKPiBjb25zaWRlcmVkLiAgVGhlcmUncyBh
IGxvdCBvZiB3b3JrIHRvIGRvIHRvIG1ha2UgaXQgc2FmZS9lZmZlY3RpdmUuCj4KPiBJc3N1aW5n
IGEgc2NvcGVkIHRva2VuIHRoYXQgYWxsb3dzIHJlYWR5IG9ubHkgYWNjZXNzIGNhbiB3b3JrIHdp
dGggdGhlCj4gYWJvdmUgY2F2ZWF0cy4gIFRoZW4gcHJvcGVydGllcy9jb21wb25lbmV0cyBoYXZl
IHRvIGV4cGxpY2l0bHkgc3VwcG9ydAo+IHRoZSBuZXcgc2NvcGUgYW5kIGRvIHRoZSByaWdodCB0
aGluZy4KPgo+Cj4gT24gU3VuZGF5LCBGZWJydWFyeSAxNSwgMjAxNSA4OjM0IFBNLCBKdXN0aW4g
UmljaGVyIDxqcmljaGVyQG1pdC5lZHU+IHdyb3RlOgo+Cj4KPiBGb3IgdGhpcyBjYXNlIHlvdSdk
IHdhbnQgdG8gYmUgdmVyeSBjYXJlZnVsIGFib3V0IHdobyB3YXMgYWJsZSB0byBkbwo+IHN1Y2gg
aW1wZXJzb25hdGlvbiwgb2J2aW91c2x5LCBidXQgaXQncyBkb2FibGUgdG9kYXkgd2l0aCBjdXN0
b20gSWRQCj4gYmVoYXZpb3IuIFlvdSBjYW4gc2ltcGx5IHVzZSBPcGVuSUQgQ29ubmVjdCBhbmQg
aGF2ZSB0aGUgSWRQIGlzc3VlIGFuIGlkCj4gdG9rZW4gZm9yIHRoZSB0YXJnZXQgdXNlciBpbnN0
ZWFkIG9mIHRoZSAiYWN0dWFsIiBjdXJyZW50IHVzZXIgYWNjb3VudC4KPgo+IEkgd291bGQgYWxz
byBzdWdnZXN0IGNvbnNpZGVyaW5nIGFkZGluZyBhIGN1c3RvbSBjbGFpbSB0byB0aGUgaWQgdG9r
ZW4KPiB0byBpbmRpY2F0ZSB0aGlzIGlzIHRha2luZyBwbGFjZS4gVGhhdCB3YXkgeW91IGNhbiBk
aWZmZXJlbnRpYXRlIHdoZXJlCj4gbmVlZGVkLCBpbmNsdWRpbmcgaW4gbG9ncy4KPgo+IC0tIEp1
c3Rpbgo+Cj4gLyBTZW50IGZyb20gbXkgcGhvbmUgLwo+Cj4KPiAtLS0tLS0tLSBPcmlnaW5hbCBt
ZXNzYWdlIC0tLS0tLS0tCj4gRnJvbTogQmlsbCBCdXJrZSA8YmJ1cmtlQHJlZGhhdC5jb20+Cj4g
RGF0ZTowMi8xNS8yMDE1IDEwOjU1IFBNIChHTVQtMDU6MDApCj4gVG86IG9hdXRoIDxvYXV0aEBp
ZXRmLm9yZz4KPiBDYzoKPiBTdWJqZWN0OiBbT0FVVEgtV0ddIHVzZXIgaW1wZXJzb25hdGlvbiBw
cm90b2NvbD8KPgo+IFdlIGhhdmUgYSBjYXNlIHdoZXJlIHdlIHdhbnQgdG8gYWxsb3cgYSBsb2dn
ZWQgaW4gYWRtaW4gdXNlciB0bwo+IGltcGVyc29uYXRlIGFub3RoZXIgdXNlciBzbyB0aGF0IHRo
ZXkgY2FuIHZpc2l0IGRpZmZlcmVudHMgYnJvd3NlciBhcHBzCj4gYXMgdGhhdCB1c2VyIChTbyB0
aGV5IGNhbiBzZWUgZXZlcnl0aGluZyB0aGF0IHRoZSB1c2VyIHNlZXMgdGhyb3VnaAo+IHRoZWly
IGJyb3dzZXIpLgo+Cj4gQW55Ym9keSBrbm93IG9mIGFueSBwcm90b2NvbCB3b3JrIGJlaW5nIGRv
bmUgaGVyZSBpbiB0aGUgT0F1dGggZ3JvdXAgb3IKPiBzb21lIG90aGVyIElFVEYgb3IgZXZlbiBD
b25uZWN0IGVmZm9ydCB0aGF0IHdvdWxkIHN1cHBvcnQgc29tZXRoaW5nIGxpa2UKPiB0aGlzPwo+
Cj4gVGhhbmtzLAo+Cj4gQmlsbAo+Cj4gLS0KPiBCaWxsIEJ1cmtlCj4gSkJvc3MsIGEgZGl2aXNp
b24gb2YgUmVkIEhhdAo+IGh0dHA6Ly9iaWxsLmJ1cmtlY2VudHJhbC5jb20KPgo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gT0F1dGggbWFpbGluZyBs
aXN0Cj4gT0F1dGhAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwo+IE9BdXRoIG1haWxpbmcgbGlzdAo+IE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhA
aWV0Zi5vcmc+Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+
Cj4KCi0tIApCaWxsIEJ1cmtlCkpCb3NzLCBhIGRpdmlzaW9uIG9mIFJlZCBIYXQKaHR0cDovL2Jp
bGwuYnVya2VjZW50cmFsLmNvbQo=

----_com.android.email_337188575429600
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5Bbm90aGVyIHF1ZXN0aW9u
IGlzIHdoZXRoZXIgb3Igbm90IHlvdSBjYW4gdXNlciByaWdodHMgZGVsZWdhdGlvbiAoaWUgdmFu
aWxsYSBPQXV0aCkgb3IgaWYgeW91IHJlYWxseSBkbyBuZWVkIGltcGVyc29uYXRpb24uIFlvdSBt
YXkgYmUgYWJsZSB0byBnZXQgdGhlIGRlc2lyZWQgcmVzdWx0cyB3aXRoIGxlc3MgY29tcGxleGl0
eSB0aGF0IHdheS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxl
PSJmb250LXNpemU6OXB4Ij48ZGl2IHN0eWxlPSJmb250LXNpemU6IDlweDsgIj4tLSBKdXN0aW48
L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6IDlweDsgIj48YnI+PC9kaXY+PGRpdiBzdHlsZT0i
Zm9udC1zaXplOiA5cHg7ICI+LyBTZW50IGZyb20gbXkgcGhvbmUgLzwvZGl2PjwvZGl2PjxkaXY+
PC9kaXY+PGRpdj48L2Rpdj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0t
LS08YnI+RnJvbTogQmlsbCBCdXJrZSAmbHQ7YmJ1cmtlQHJlZGhhdC5jb20mZ3Q7IDxicj5EYXRl
OjAyLzE2LzIwMTUgIDEwOjIwIEFNICAoR01ULTA1OjAwKSA8YnI+VG86IEJpbGwgTWlsbHMgJmx0
O3dtaWxsc185MjEwNUB5YWhvby5jb20mZ3Q7LCBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1p
dC5lZHUmZ3Q7LCBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7IDxicj5DYzogIDxicj5TdWJq
ZWN0OiBSZTogW09BVVRILVdHXSB1c2VyIGltcGVyc29uYXRpb24gcHJvdG9jb2w/IDxicj48YnI+
WWVhaCwgSSBrbm93IGl0cyByaXNreSwgYnV0IHRoYXQncyB0aGUgcmVxdWlyZW1lbnQuJm5ic3A7
IFdhcyBqdXN0IHdvbmRlcmluZyA8YnI+aWYgdGhlcmUgd2FzIGFueSBwcm90b2NvbCB3b3JrIGJl
aW5nIGRvbmUgYXJvdW5kIGl0LCBzbyB0aGF0IHdlIGNvdWxkIDxicj5hdm9pZCBkb2luZyBhIGxv
dCBvZiB0aGUgbGVnd29yayB0byBtYWtlIGl0IHNhZmUvZWZmZWN0aXZlLiZuYnNwOyBDdXJyZW50
bHkgPGJyPmZvciB1cywgd2UgbmVlZCB0byBkbyB0aGlzIGJldHdlZW4gdHdvIHNlcGFyYXRlIElE
UHMsIHdoaWNoIGlzIHdoZXJlIHRoZSA8YnI+cHJvdG9jb2wgd29yayBjb21lcyBpbi4uLklmIGl0
IHdhcyBqdXN0IGEgc2luZ2xlIElEUCBtYW5hZ2luZyA8YnI+ZXZlcnl0aGluZywgdGhlbiBpdCB3
b3VsZCBqdXN0IGJlIGFuIGludGVybmFsIGN1c3RvbSBJRFAgZmVhdHVyZS48YnI+PGJyPlRoYW5r
cyBhbGwuPGJyPjxicj48YnI+PGJyPk9uIDIvMTYvMjAxNSAxMjozNyBBTSwgQmlsbCBNaWxscyB3
cm90ZTo8YnI+Jmd0OyBVc2VyIGltcGVyc29uYXRpb24gaXMgdmVyeSB2ZXJ5IHJpc2t5LiZuYnNw
OyBUaGUgbGVnYWwgYXNwZWN0cyBvZiBpdCBtdXN0IGJlPGJyPiZndDsgY29uc2lkZXJlZC4mbmJz
cDsgVGhlcmUncyBhIGxvdCBvZiB3b3JrIHRvIGRvIHRvIG1ha2UgaXQgc2FmZS9lZmZlY3RpdmUu
PGJyPiZndDs8YnI+Jmd0OyBJc3N1aW5nIGEgc2NvcGVkIHRva2VuIHRoYXQgYWxsb3dzIHJlYWR5
IG9ubHkgYWNjZXNzIGNhbiB3b3JrIHdpdGggdGhlPGJyPiZndDsgYWJvdmUgY2F2ZWF0cy4mbmJz
cDsgVGhlbiBwcm9wZXJ0aWVzL2NvbXBvbmVuZXRzIGhhdmUgdG8gZXhwbGljaXRseSBzdXBwb3J0
PGJyPiZndDsgdGhlIG5ldyBzY29wZSBhbmQgZG8gdGhlIHJpZ2h0IHRoaW5nLjxicj4mZ3Q7PGJy
PiZndDs8YnI+Jmd0OyBPbiBTdW5kYXksIEZlYnJ1YXJ5IDE1LCAyMDE1IDg6MzQgUE0sIEp1c3Rp
biBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDsgd3JvdGU6PGJyPiZndDs8YnI+Jmd0Ozxi
cj4mZ3Q7IEZvciB0aGlzIGNhc2UgeW91J2Qgd2FudCB0byBiZSB2ZXJ5IGNhcmVmdWwgYWJvdXQg
d2hvIHdhcyBhYmxlIHRvIGRvPGJyPiZndDsgc3VjaCBpbXBlcnNvbmF0aW9uLCBvYnZpb3VzbHks
IGJ1dCBpdCdzIGRvYWJsZSB0b2RheSB3aXRoIGN1c3RvbSBJZFA8YnI+Jmd0OyBiZWhhdmlvci4g
WW91IGNhbiBzaW1wbHkgdXNlIE9wZW5JRCBDb25uZWN0IGFuZCBoYXZlIHRoZSBJZFAgaXNzdWUg
YW4gaWQ8YnI+Jmd0OyB0b2tlbiBmb3IgdGhlIHRhcmdldCB1c2VyIGluc3RlYWQgb2YgdGhlICJh
Y3R1YWwiIGN1cnJlbnQgdXNlciBhY2NvdW50Ljxicj4mZ3Q7PGJyPiZndDsgSSB3b3VsZCBhbHNv
IHN1Z2dlc3QgY29uc2lkZXJpbmcgYWRkaW5nIGEgY3VzdG9tIGNsYWltIHRvIHRoZSBpZCB0b2tl
bjxicj4mZ3Q7IHRvIGluZGljYXRlIHRoaXMgaXMgdGFraW5nIHBsYWNlLiBUaGF0IHdheSB5b3Ug
Y2FuIGRpZmZlcmVudGlhdGUgd2hlcmU8YnI+Jmd0OyBuZWVkZWQsIGluY2x1ZGluZyBpbiBsb2dz
Ljxicj4mZ3Q7PGJyPiZndDsgLS0gSnVzdGluPGJyPiZndDs8YnI+Jmd0OyAvIFNlbnQgZnJvbSBt
eSBwaG9uZSAvPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IC0tLS0tLS0tIE9yaWdpbmFsIG1lc3Nh
Z2UgLS0tLS0tLS08YnI+Jmd0OyBGcm9tOiBCaWxsIEJ1cmtlICZsdDtiYnVya2VAcmVkaGF0LmNv
bSZndDs8YnI+Jmd0OyBEYXRlOjAyLzE1LzIwMTUgMTA6NTUgUE0gKEdNVC0wNTowMCk8YnI+Jmd0
OyBUbzogb2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4mZ3Q7IENjOjxicj4mZ3Q7IFN1
YmplY3Q6IFtPQVVUSC1XR10gdXNlciBpbXBlcnNvbmF0aW9uIHByb3RvY29sPzxicj4mZ3Q7PGJy
PiZndDsgV2UgaGF2ZSBhIGNhc2Ugd2hlcmUgd2Ugd2FudCB0byBhbGxvdyBhIGxvZ2dlZCBpbiBh
ZG1pbiB1c2VyIHRvPGJyPiZndDsgaW1wZXJzb25hdGUgYW5vdGhlciB1c2VyIHNvIHRoYXQgdGhl
eSBjYW4gdmlzaXQgZGlmZmVyZW50cyBicm93c2VyIGFwcHM8YnI+Jmd0OyBhcyB0aGF0IHVzZXIg
KFNvIHRoZXkgY2FuIHNlZSBldmVyeXRoaW5nIHRoYXQgdGhlIHVzZXIgc2VlcyB0aHJvdWdoPGJy
PiZndDsgdGhlaXIgYnJvd3NlcikuPGJyPiZndDs8YnI+Jmd0OyBBbnlib2R5IGtub3cgb2YgYW55
IHByb3RvY29sIHdvcmsgYmVpbmcgZG9uZSBoZXJlIGluIHRoZSBPQXV0aCBncm91cCBvcjxicj4m
Z3Q7IHNvbWUgb3RoZXIgSUVURiBvciBldmVuIENvbm5lY3QgZWZmb3J0IHRoYXQgd291bGQgc3Vw
cG9ydCBzb21ldGhpbmcgbGlrZTxicj4mZ3Q7IHRoaXM/PGJyPiZndDs8YnI+Jmd0OyBUaGFua3Ms
PGJyPiZndDs8YnI+Jmd0OyBCaWxsPGJyPiZndDs8YnI+Jmd0OyAtLTxicj4mZ3Q7IEJpbGwgQnVy
a2U8YnI+Jmd0OyBKQm9zcywgYSBkaXZpc2lvbiBvZiBSZWQgSGF0PGJyPiZndDsgaHR0cDovL2Jp
bGwuYnVya2VjZW50cmFsLmNvbTxicj4mZ3Q7PGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+
Jmd0OyBPQXV0aEBpZXRmLm9yZzxicj4mZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGg8YnI+Jmd0Ozxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsg
T0F1dGhAaWV0Zi5vcmcgJmx0O21haWx0bzpPQXV0aEBpZXRmLm9yZyZndDs8YnI+Jmd0OyBodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPiZndDs8YnI+Jmd0Ozxi
cj48YnI+LS0gPGJyPkJpbGwgQnVya2U8YnI+SkJvc3MsIGEgZGl2aXNpb24gb2YgUmVkIEhhdDxi
cj5odHRwOi8vYmlsbC5idXJrZWNlbnRyYWwuY29tPGJyPjwvYm9keT48L2h0bWw+

----_com.android.email_337188575429600--



From nobody Mon Feb 16 09:14:34 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BD81A1BAF for ; Mon, 16 Feb 2015 09:14:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.509
X-Spam-Level: 
X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBoMwQp76AZK for ; Mon, 16 Feb 2015 09:14:29 -0800 (PST)
Received: from nm38-vm5.bullet.mail.bf1.yahoo.com (nm38-vm5.bullet.mail.bf1.yahoo.com [72.30.239.21]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F09B1A1B84 for ; Mon, 16 Feb 2015 09:14:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1424106868; bh=tvTJn+vFkHuyfXKndHbPMW1/FlOeTARt6UPq4tj/wZw=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=oNxVaH7V4kbnTVdKpdZIOO9lU5PfbNd7On6At8rw6/qlFARAvcZNIU+QXXdO1QKBCnArmgfxzuP7vx9CjaXZ/uqNa8FFBHl36qSPgfafmO54EG/lUn662tVeXbhPv79VXnVz5eJBxLuc3dzAYUd1kGk6WsiKgy1ad8bJu8azOZ+WhJhvbfa+cdAgt3XYcKDEWpcIlUKhYLxmTzqJq4CYzdKBKD1mbHAAwNJfVzMvPXTFFZd8QonLqM0CayxPrr7ChPR18qq0ZhPkjS3u0sPrOkO7FOrtk4ZhTmWbJvb8s/elq2bmHMAj/JPvl5xhfVc3F9DPPbO8ki+Ewe8eLA093g==
Received: from [66.196.81.173] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2015 17:14:28 -0000
Received: from [98.139.212.230] by tm19.bullet.mail.bf1.yahoo.com with NNFMP;  16 Feb 2015 17:14:28 -0000
Received: from [127.0.0.1] by omp1039.mail.bf1.yahoo.com with NNFMP; 16 Feb 2015 17:14:28 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 718096.54443.bm@omp1039.mail.bf1.yahoo.com
X-YMail-OSG: C9Cb_5QVM1lY8gsX5uJ8doknb7MtCpx6qyIZ8UPrIGmKfrzSNt1RnKZSuC91szi nF1OHEsPkvz0gvPT6uNViy7fgSJRfG7Sb4Ml7pQ48l0aVyVE4vIy0K5bdPSkWsYtZPoFOolqOaaK TJ6MLlKR9dHYpRBQXg8FQt9eOce7XKBPWwivGSVLVnMgiklysLIovKsJPPKm.lVP938BQzEIZcDI ovdX03VX8Aa49Nclscm07hIblzoda2ZcXmTe2.3vZT0xjMoSQxZ46mmAWwXrWO3naVzdDINkcNbV qEunD.dljLH9Dw.qLnNBcJ9DPPaUCvoPd0wcu9jpbZ_fTivTZAHUg79yb0B112UMVPdYaYHtmOuJ 9Jf9unKKbJ7J2U3mXV0g.mcRm94coGrW0t0_sXFo1IL1rJp7X34L5oZniXwC8k7vBbIoHDW7gEkK jLVwcr1NsKebaUF_.IH2MqI6CTCNfuJDjzmTsrnLNxSIB5PTBsS3McrKH2zijwIyuLWVoyjX9ZjH .FsHH_OADyKBnyPD1pvdf4o.SHEETNKRddR2tUstkHMubpoATPXEKhejp2pxcIWbNFkp5WtYQ6_g 1NcgA2qaeN18CrIdxiOon1i4MoLq.5zIcwtinf2Gg
Received: by 76.13.27.196; Mon, 16 Feb 2015 17:14:28 +0000 
Date: Mon, 16 Feb 2015 17:14:27 +0000 (UTC)
From: Bill Mills 
To: Justin Richer , Bill Burke ,  oauth 
Message-ID: <1903996086.7456583.1424106867491.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_7456582_934897397.1424106867486"
Archived-At: 
Subject: Re: [OAUTH-WG] user impersonation protocol?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Feb 2015 17:14:31 -0000

------=_Part_7456582_934897397.1424106867486
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don't think there is protocol work required. =C2=A0IMO you can best suppo=
rt this with limited cookies or tokens that are not otherwise valid and the=
 server then needs to support with the right behavior. =C2=A0Might be a BCP=
 doc I suppose, but I don't know if it's worth the effort.=20

     On Monday, February 16, 2015 7:35 AM, Justin Richer  =
wrote:
  =20

 Another question is whether or not you can user rights delegation (ie vani=
lla OAuth) or if you really do need impersonation. You may be able to get t=
he desired results with less complexity that way.

-- Justin
/ Sent from my phone /

-------- Original message --------
From: Bill Burke =20
Date:02/16/2015 10:20 AM (GMT-05:00)=20
To: Bill Mills , Justin Richer , o=
auth =20
Cc:=20
Subject: Re: [OAUTH-WG] user impersonation protocol?=20

Yeah, I know its risky, but that's the requirement.=C2=A0 Was just wonderin=
g=20
if there was any protocol work being done around it, so that we could=20
avoid doing a lot of the legwork to make it safe/effective.=C2=A0 Currently=
=20
for us, we need to do this between two separate IDPs, which is where the=20
protocol work comes in...If it was just a single IDP managing=20
everything, then it would just be an internal custom IDP feature.

Thanks all.



On 2/16/2015 12:37 AM, Bill Mills wrote:
> User impersonation is very very risky.=C2=A0 The legal aspects of it must=
 be
> considered.=C2=A0 There's a lot of work to do to make it safe/effective.
>
> Issuing a scoped token that allows ready only access can work with the
> above caveats.=C2=A0 Then properties/componenets have to explicitly suppo=
rt
> the new scope and do the right thing.
>
>
> On Sunday, February 15, 2015 8:34 PM, Justin Richer  wro=
te:
>
>
> For this case you'd want to be very careful about who was able to do
> such impersonation, obviously, but it's doable today with custom IdP
> behavior. You can simply use OpenID Connect and have the IdP issue an id
> token for the target user instead of the "actual" current user account.
>
> I would also suggest considering adding a custom claim to the id token
> to indicate this is taking place. That way you can differentiate where
> needed, including in logs.
>
> -- Justin
>
> / Sent from my phone /
>
>
> -------- Original message --------
> From: Bill Burke 
> Date:02/15/2015 10:55 PM (GMT-05:00)
> To: oauth 
> Cc:
> Subject: [OAUTH-WG] user impersonation protocol?
>
> We have a case where we want to allow a logged in admin user to
> impersonate another user so that they can visit differents browser apps
> as that user (So they can see everything that the user sees through
> their browser).
>
> Anybody know of any protocol work being done here in the OAuth group or
> some other IETF or even Connect effort that would support something like
> this?
>
> Thanks,
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> 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
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


   
------=_Part_7456582_934897397.1424106867486
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I don't think there is protocol=
 work required.  IMO you can best support this with limited cookies or=
 tokens that are not otherwise valid and the server then needs to support w=
ith the right behavior.  Might be a BCP doc I suppose, but I don't kno=
w if it's worth the effort.
 

<=
br>
 
 
 
  On Monday, Febr=
uary 16, 2015 7:35 AM, Justin Richer <jricher@mit.edu> wrote:
  
  

 
Another question is whether or not you can user rights delega=
tion (ie vanilla OAuth) or if you really do need impersonation. You may be =
able to get the desired results with less complexity that way.

-- Justin

/ Sent from my phone /


-------- Original message --------
From: Bill Burke <bburke@=
redhat.com> 
Date:02/16/2015  10:20 AM  (GMT-05:00) 
To: Bill Mill=
s <wmills_92105@yahoo.com>, Justin Richer <jricher@mit.edu>, oa=
uth <oauth@ietf.org> 
Cc:  
Subject: Re: [OAUTH-WG] user impers=
onation protocol? 

Yeah, I know its risky, but that's the requiremen=
t.  Was just wondering 
if there was any protocol work being done a=
round it, so that we could 
avoid doing a lot of the legwork to make it =
safe/effective.  Currently 
for us, we need to do this between two =
separate IDPs, which is where the 
protocol work comes in...If it was ju=
st a single IDP managing 
everything, then it would just be an internal =
custom IDP feature.

Thanks all.



On 2/16/2015 12:37 AM=
, Bill Mills wrote:
> User impersonation is very very risky.  Th=
e legal aspects of it must be
> considered.  There's a lot of wo=
rk to do to make it safe/effective.
>
> Issuing a scoped token =
that allows ready only access can work with the
> above caveats. =
; Then properties/componenets have to explicitly support
> the new sc=
ope and do the right thing.
>
>
> On Sunday, February 15,=
 2015 8:34 PM, Justin Richer <jricher@mit.edu> wrote:
>
>=

> For this case you'd want to be very careful about who was able to =
do
> such impersonation, obviously, but it's doable today with custom=
 IdP
> behavior. You can simply use OpenID Connect and have the IdP i=
ssue an id
> token for the target user instead of the "actual" curren=
t user account.
>
> I would also suggest considering adding a c=
ustom claim to the id token
> to indicate this is taking place. That =
way you can differentiate where
> needed, including in logs.
><=
br>> -- Justin
>
> / Sent from my phone /
>
>> -------- Original message --------
> From: Bill Burke <bburk=
e@redhat.com>
> Date:02/15/2015 10:55 PM (GMT-05:00)
> To: o=
auth <oauth@ietf.org>
> Cc:
> Subject: [OAUTH-WG] user im=
personation protocol?
>
> We have a case where we want to allow=
 a logged in admin user to
> impersonate another user so that they ca=
n visit differents browser apps
> as that user (So they can see every=
thing that the user sees through
> their browser).
>
> An=
ybody know of any protocol work being done here in the OAuth group or
&g=
t; some other IETF or even Connect effort that would support something like=

> this?
>
> Thanks,
>
> Bill
>
>=
 --
> Bill Burke
> JBoss, a division of Red Hat
> http://=
bill.burkecentral.com
>
> _____________________________________=
__________
> OAuth mailing list
> OAuth@ietf.org
> https:=
//www.ietf.org/mailman/listinfo/oauth
>
> _____________________=
__________________________
> OAuth mailing list
> OAuth@ietf.or=
g <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listin=
fo/oauth
>
>

-- 
Bill Burke
JBoss, a division of R=
ed Hat
http://bill.burkecentral.com


   
  
 

------=_Part_7456582_934897397.1424106867486--


From nobody Mon Feb 16 13:21:37 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788BD1A1BA9 for ; Mon, 16 Feb 2015 13:21:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUJ6cQvG2qen for ; Mon, 16 Feb 2015 13:21:32 -0800 (PST)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBC71A6FE6 for ; Mon, 16 Feb 2015 13:21:32 -0800 (PST)
Received: by mail-ob0-f171.google.com with SMTP id gq1so46484430obb.2 for ; Mon, 16 Feb 2015 13:21:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=tZj6d7DeXVwxO9vHvSFOqnUeCnhSrm6hhJewHk1h2Ys=; b=DbTxOzwp4xDM6wxa3DxlKM17jLxBFuPJykxVD/y+OFNNuzqEwzin2XyX2nhkF9tNs6 2MOL6y7S5dpg3Vh4WjIT65ysA4IfKzTkzWRYycX9tWU9yU/KI16MsOEzaqVTNq6BaiAG HiGPzzNguRXBQA8yl4rPu5i68RXsZLtMYFdae6tgFvKoGEhN8Z4SswzOXzSQywUN9lcw 2bZjkb/+qiyjlKrsSWE5JEv5Wl9FtMy1UlaPP5ei3KMgUK4CbUHQmodRtLs0RpaJmeCC L3fkTt7pr+s5YQWdqsfPShl6cZTUgYzLT/hpDohd385rc1IdEaX86tMpB4NbOAiDhuX5 rwxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=tZj6d7DeXVwxO9vHvSFOqnUeCnhSrm6hhJewHk1h2Ys=; b=MJyCa282782PZBSM8KsnUvsZUsxZOBE2iwnoeTB1UUaAOd3E/b4MTQBxdU9niOyc/x GB8MELsibTP6N8iUI8Oqh2zrA58US4EfJBDewL7VMCK3Q2CaliE5t758GYBUoTrucScP SPLVH314l7YkK6+nevDkosOEdEM35736f9buQmP6QHTtVCMR7o7fgEEricA2+bgEwiE+ XCOT9G2u3wT2z1CPOsuYNAQhnso4FOtQUoTpYnFIMO23ArUkWIf6IhGgcfw1+XuPmr4z eUlK/o70dO8G+LhD+OnpHKwKTqsGge7HPsz+bLjyTbQYJZbeOLuDoqVu6Xqio0jAFHu2 YHTA==
X-Gm-Message-State: ALoCoQle9s+vkUFn3hb2T9rcK8XuLRhSDtcDg036m8gByGciVJvEpeg8JOpbWAKjefOqVCjI5S66
X-Received: by 10.60.92.66 with SMTP id ck2mr16734766oeb.30.1424121209057; Mon, 16 Feb 2015 13:13:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.202.104.144 with HTTP; Mon, 16 Feb 2015 13:13:08 -0800 (PST)
In-Reply-To: 
References: 
From: William Denniss 
Date: Mon, 16 Feb 2015 13:13:08 -0800
Message-ID: 
To: Justin Richer , Bill Burke ,  Bill Mills , oauth 
Content-Type: multipart/alternative; boundary=047d7b33ca00c89468050f3b0e1c
Archived-At: 
Subject: Re: [OAUTH-WG] user impersonation protocol?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Feb 2015 21:21:35 -0000

--047d7b33ca00c89468050f3b0e1c
Content-Type: text/plain; charset=UTF-8

I led a discussion on a related topic at a recent IIW (specifically
exploring the "account sharing" use case), the notes are here:
http://iiw.idcommons.net/Account_Sharing_at_the_IDP_(Identity_Provider).
It was an interesting discussion, the whole topic of impersonation
certainly raises a lot of policy questions.

As for the technical implementation, our conclusion was that the simplest
approach for impersonation would be to continue to supply an ID Token for
the target user (i.e. 'sub' represents the user being impersonated), and
add an additional JWT claim for the user doing the impersonation (e.g.
'ipb' meaning "impersonated by").

Thus, any relying party who doesn't understand this claim continues to work
as before (oblivious to the fact the user is being impersonated), and those
who understand the claim and care about impersonation can take action (e.g.
log a better audit trail, limit some functionality or outright block the
behavior).

If this approach sounds interesting to you, perhaps we could formally
register & standardise the 'ipb' claim.  Of course, anyone can use this
technique today via a private claim
.


On Mon Feb 16 2015 at 7:36:23 AM Justin Richer  wrote:

> Another question is whether or not you can user rights delegation (ie
> vanilla OAuth) or if you really do need impersonation. You may be able to
> get the desired results with less complexity that way.
>
>
> -- Justin
>
> / Sent from my phone /
>
>
> -------- Original message --------
> From: Bill Burke 
> Date:02/16/2015 10:20 AM (GMT-05:00)
> To: Bill Mills , Justin Richer ,
> oauth 
> Cc:
> Subject: Re: [OAUTH-WG] user impersonation protocol?
>
> Yeah, I know its risky, but that's the requirement.  Was just wondering
> if there was any protocol work being done around it, so that we could
> avoid doing a lot of the legwork to make it safe/effective.  Currently
> for us, we need to do this between two separate IDPs, which is where the
> protocol work comes in...If it was just a single IDP managing
> everything, then it would just be an internal custom IDP feature.
>
> Thanks all.
>
>
>
> On 2/16/2015 12:37 AM, Bill Mills wrote:
> > User impersonation is very very risky.  The legal aspects of it must be
> > considered.  There's a lot of work to do to make it safe/effective.
> >
> > Issuing a scoped token that allows ready only access can work with the
> > above caveats.  Then properties/componenets have to explicitly support
> > the new scope and do the right thing.
> >
> >
> > On Sunday, February 15, 2015 8:34 PM, Justin Richer 
> wrote:
> >
> >
> > For this case you'd want to be very careful about who was able to do
> > such impersonation, obviously, but it's doable today with custom IdP
> > behavior. You can simply use OpenID Connect and have the IdP issue an id
> > token for the target user instead of the "actual" current user account.
> >
> > I would also suggest considering adding a custom claim to the id token
> > to indicate this is taking place. That way you can differentiate where
> > needed, including in logs.
> >
> > -- Justin
> >
> > / Sent from my phone /
> >
> >
> > -------- Original message --------
> > From: Bill Burke 
> > Date:02/15/2015 10:55 PM (GMT-05:00)
> > To: oauth 
> > Cc:
> > Subject: [OAUTH-WG] user impersonation protocol?
> >
> > We have a case where we want to allow a logged in admin user to
> > impersonate another user so that they can visit differents browser apps
> > as that user (So they can see everything that the user sees through
> > their browser).
> >
> > Anybody know of any protocol work being done here in the OAuth group or
> > some other IETF or even Connect effort that would support something like
> > this?
> >
> > Thanks,
> >
> > Bill
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> >
> > _______________________________________________
> > 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
> >
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--047d7b33ca00c89468050f3b0e1c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I led a discussion on a related topic at a recent IIW=
 (specifically exploring the "account sharing" use case), the not=
es are here:=C2=A0http://iiw.idcommons.net/Accou=
nt_Sharing_at_the_IDP_(Identity_Provider).=C2=A0 It was an interesting =
discussion, the whole topic of impersonation certainly raises a lot of poli=
cy questions.

As for the technical imple=
mentation, our conclusion was that the simplest approach for impersonation =
would be to continue to supply an ID Token for the target user (i.e. 's=
ub' represents the user being impersonated), and add an additional JWT =
claim for the user doing the impersonation (e.g. 'ipb' meaning &quo=
t;impersonated by").

Thus, any relying party who do=
esn't understand this claim continues to work as before (oblivious to t=
he fact the user is being impersonated), and those who understand the claim=
 and care about impersonation can take action (e.g. log a better audit trai=
l, limit some functionality or outright block the behavior).

=

If this approach sounds interesting to you, perhaps we could formally =
register & standardise the 'ipb' claim.=C2=A0 Of course, anyone=
 can use this technique today via a=C2=A0private claim.


On Mon Feb 16 2015 at 7:36:2=
3 AM Justin Richer <jricher@mit.edu> wrote:
Another ques=
tion is whether or not you can user rights delegation (ie vanilla OAuth) or=
 if you really do need impersonation. You may be able to get the desired re=
sults with less complexity that way.

-- Justin=


/=
 Sent from my phone /


-------- Ori=
ginal message --------
From: Bill Burke <bburke@redhat.com> 
Date:02=
/16/2015  10:20 AM  (GMT-05:00) 
To: Bill Mills <wmills_92105@yahoo.com>, Jus=
tin Richer <jricher=
@mit.edu>, oauth <oauth@ietf.org> 
Cc:  
Subject: Re: [OAUTH-WG] user imper=
sonation protocol? 

Yeah, I know its risky, but that's the requi=
rement.=C2=A0 Was just wondering 
if there was any protocol work being d=
one around it, so that we could 
avoid doing a lot of the legwork to mak=
e it safe/effective.=C2=A0 Currently 
for us, we need to do this between=
 two separate IDPs, which is where the 
protocol work comes in...If it w=
as just a single IDP managing 
everything, then it would just be an inte=
rnal custom IDP feature.

Thanks all.



On 2/16/2015 12:=
37 AM, Bill Mills wrote:
> User impersonation is very very risky.=C2=
=A0 The legal aspects of it must be
> considered.=C2=A0 There's a=
 lot of work to do to make it safe/effective.
>
> Issuing a sco=
ped token that allows ready only access can work with the
> above cav=
eats.=C2=A0 Then properties/componenets have to explicitly support
> =
the new scope and do the right thing.
>
>
> On Sunday, Fe=
bruary 15, 2015 8:34 PM, Justin Richer <jricher@mit.edu> wrote:
>
>
>=
 For this case you'd want to be very careful about who was able to do> such impersonation, obviously, but it's doable today with custom=
 IdP
> behavior. You can simply use OpenID Connect and have the IdP i=
ssue an id
> token for the target user instead of the "actual&qu=
ot; current user account.
>
> I would also suggest considering =
adding a custom claim to the id token
> to indicate this is taking pl=
ace. That way you can differentiate where
> needed, including in logs=
.
>
> -- Justin
>
> / Sent from my phone /
><=
br>>
> -------- Original message --------
> From: Bill Burke=
 <bburke@redhat.c=
om>
> Date:02/15/2015 10:55 PM (GMT-05:00)
> To: oauth &=
lt;oauth@ietf.org&g=
t;
> Cc:
> Subject: [OAUTH-WG] user impersonation protocol?
=
>
> We have a case where we want to allow a logged in admin user t=
o
> impersonate another user so that they can visit differents browse=
r apps
> as that user (So they can see everything that the user sees =
through
> their browser).
>
> Anybody know of any protoco=
l work being done here in the OAuth group or
> some other IETF or eve=
n Connect effort that would support something like
> this?
>> Thanks,
>
> Bill
>
> --
> Bill Burke> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>=
 _______________________________________________
> OAuth maili=
ng list
> OAuth@i=
etf.org
> https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
&g=
t; OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Bill Burke
JBoss, =
a division of Red Hat
http://bill.burkecentral.com
________________________=
_______________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth




--047d7b33ca00c89468050f3b0e1c--


From nobody Mon Feb 16 13:51:42 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7434F1A6F10 for ; Mon, 16 Feb 2015 13:51:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.509
X-Spam-Level: 
X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvH4---N4zzo for ; Mon, 16 Feb 2015 13:51:38 -0800 (PST)
Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383201A0154 for ; Mon, 16 Feb 2015 13:51:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1424121635; bh=4TSabegPr2g2mwvufgoE3+3cg+ChHrAfZ99PqAWD8Jw=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=XbURST9QgKI3ECE49kDfxD/rftYj1iNgjnojtSur1lArX4dL3qGLbYym6hxB/oNbDvZubqYU9HqRfVha9rDel57rEJEa5pqQEZ1ycYFsNO4s4zaQVz9fheaWw251NlUJfkZCs5Lq75T5l2Pan6igg2PVMS2tjXSpgrOmQLe30S7pNrgbBAvg2NuCSjyq4J1fACyMlDNpK2+ANJaw7MkASlkbBz33VZUbLfF27icyuFVjbrnlWUNyHxJsUtMK4JoRb5A0GTJ8fQ9QMkVkvrfEgqrNe5P4YbjUXctb/0oOszPcXUPDh5Yu8F+/rIEWUmd8hXZQpWDdsIW+zVxiArkrVw==
Received: from [98.139.214.32] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2015 21:20:35 -0000
Received: from [98.139.212.196] by tm15.bullet.mail.bf1.yahoo.com with NNFMP;  16 Feb 2015 21:20:35 -0000
Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 16 Feb 2015 21:20:35 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 585290.77465.bm@omp1005.mail.bf1.yahoo.com
X-YMail-OSG: iRwGSwIVM1l5jj1UXV7LZTRYPkr97Md9bJOHCg2blz0IT3u2n440xKdUrT_xrPf airdTsWSNfSTfhpcaZpXXC9RhOsa4rE5TZGLysPtSy8ryXTG.zQD4woJj1iCreeeyuZd1tR1tvOl V07Sr.p3izI_o9bXKro2VEHYv7LV.eK3B4f508HClQGJtlCj.ba8R2eA.5qNUZXoRNb5LsZeklOe YGtLyXDmCzro6e54c1yVh50Oe0Z5ZqI7WbKrz4SCrSzQAW5eXLEePVBWoHGcbV9dqhrrmMFeDgqU y07TReKlAmB01OCm8.rC9NUX66GjDWJeFdGXTDDYhd6KtLIy3f0xp0m_MsqHiHT0IEyJGSR1wP56 a3qrm8NTeT83St3L7HPvJDSHPoA_1eLsJpuNyYedPudLhOT6JzCfKGIuhQr3qmZ5gR_0wQJ2uP7K m0NITWU6_.hPJbfAVHmfmFDzHpvZlnPpNViadjCZbSAXDMqyOx0u2ryow3h3uP6PUyeGePQ8.Z2z yqjNvaMxh5rm89l6UKjpMZ6BUK5lD9SNtop.KqLUSg6W1ssl1x7SMQxxzgP4XW8YhfPHVtDXIOJG kIAWRb.qmc8zKvypPX4n6fTGWBqbC1pljU3yfg.SXyjtj5fh0dgOPDTVuG7ZEpEyjAQ9k5wmlEpb xU3eFVRWRsVVREQbKMGO9V0WP8IxvMi4zeYGCnb5sZ89fndbbww--
Received: by 66.196.81.118; Mon, 16 Feb 2015 21:20:35 +0000 
Date: Mon, 16 Feb 2015 21:20:34 +0000 (UTC)
From: Bill Mills 
To: William Denniss , Justin Richer ,  Bill Burke , oauth 
Message-ID: <1363965451.7820862.1424121634785.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_7820861_909648758.1424121634776"
Archived-At: 
Subject: Re: [OAUTH-WG] user impersonation protocol?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Feb 2015 21:51:40 -0000

------=_Part_7820861_909648758.1424121634776
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Straight impersonation with no limitations isn't a good solution in the lon=
g run.=20

     On Monday, February 16, 2015 1:13 PM, William Denniss  wrote:
  =20

 I led a discussion on a related topic at a recent IIW (specifically explor=
ing the "account sharing" use case), the notes are here:=C2=A0http://iiw.id=
commons.net/Account_Sharing_at_the_IDP_(Identity_Provider).=C2=A0 It was an=
 interesting discussion, the whole topic of impersonation certainly raises =
a lot of policy questions.
As for the technical implementation, our conclusion was that the simplest a=
pproach for impersonation would be to continue to supply an ID Token for th=
e target user (i.e. 'sub' represents the user being impersonated), and add =
an additional JWT claim for the user doing the impersonation (e.g. 'ipb' me=
aning "impersonated by").
Thus, any relying party who doesn't understand this claim continues to work=
 as before (oblivious to the fact the user is being impersonated), and thos=
e who understand the claim and care about impersonation can take action (e.=
g. log a better audit trail, limit some functionality or outright block the=
 behavior).
If this approach sounds interesting to you, perhaps we could formally regis=
ter & standardise the 'ipb' claim.=C2=A0 Of course, anyone can use this tec=
hnique today via a=C2=A0private claim.

On Mon Feb 16 2015 at 7:36:23 AM Justin Richer  wrote:

Another question is whether or not you can user rights delegation (ie vanil=
la OAuth) or if you really do need impersonation. You may be able to get th=
e desired results with less complexity that way.

-- Justin
/ Sent from my phone /

-------- Original message --------
From: Bill Burke =20
Date:02/16/2015 10:20 AM (GMT-05:00)=20
To: Bill Mills , Justin Richer , o=
auth =20
Cc:=20
Subject: Re: [OAUTH-WG] user impersonation protocol?=20

Yeah, I know its risky, but that's the requirement.=C2=A0 Was just wonderin=
g=20
if there was any protocol work being done around it, so that we could=20
avoid doing a lot of the legwork to make it safe/effective.=C2=A0 Currently=
=20
for us, we need to do this between two separate IDPs, which is where the=20
protocol work comes in...If it was just a single IDP managing=20
everything, then it would just be an internal custom IDP feature.

Thanks all.



On 2/16/2015 12:37 AM, Bill Mills wrote:
> User impersonation is very very risky.=C2=A0 The legal aspects of it must=
 be
> considered.=C2=A0 There's a lot of work to do to make it safe/effective.
>
> Issuing a scoped token that allows ready only access can work with the
> above caveats.=C2=A0 Then properties/componenets have to explicitly suppo=
rt
> the new scope and do the right thing.
>
>
> On Sunday, February 15, 2015 8:34 PM, Justin Richer  wro=
te:
>
>
> For this case you'd want to be very careful about who was able to do
> such impersonation, obviously, but it's doable today with custom IdP
> behavior. You can simply use OpenID Connect and have the IdP issue an id
> token for the target user instead of the "actual" current user account.
>
> I would also suggest considering adding a custom claim to the id token
> to indicate this is taking place. That way you can differentiate where
> needed, including in logs.
>
> -- Justin
>
> / Sent from my phone /
>
>
> -------- Original message --------
> From: Bill Burke 
> Date:02/15/2015 10:55 PM (GMT-05:00)
> To: oauth 
> Cc:
> Subject: [OAUTH-WG] user impersonation protocol?
>
> We have a case where we want to allow a logged in admin user to
> impersonate another user so that they can visit differents browser apps
> as that user (So they can see everything that the user sees through
> their browser).
>
> Anybody know of any protocol work being done here in the OAuth group or
> some other IETF or even Connect effort that would support something like
> this?
>
> Thanks,
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> 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
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



   
------=_Part_7820861_909648758.1424121634776
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Straight impersonation with no =
limitations isn't a good solution in the long run.
 


 
 
 
  On Monday, February 16, 2015 1:13 PM, William Denniss <wdenniss@=
google.com> wrote:
  
  

 
I led a discuss=
ion on a related topic at a recent IIW (specifically exploring the "account=
 sharing" use case), the notes are here: http://iiw.idcommons.net/Account_Sharing_at_t=
he_IDP_(Identity_Provider).  It was an interesting discussion, the=
 whole topic of impersonation certainly raises a lot of policy questions.

As for the technical imple=
mentation, our conclusion was that the simplest approach for impersonation =
would be to continue to supply an ID Token for the target user (i.e. 'sub' =
represents the user being impersonated), and add an additional JWT claim fo=
r the user doing the impersonation (e.g. 'ipb' meaning "impersonated by").<=
/div>

Thus, any relying party who doesn't unde=
rstand this claim continues to work as before (oblivious to the fact the us=
er is being impersonated), and those who understand the claim and care abou=
t impersonation can take action (e.g. log a better audit trail, limit some =
functionality or outright block the behavior).

If this approach sounds interesting to you, perhaps we could formally=
 register & standardise the 'ipb' claim.  Of course, anyone can us=
e this technique today via a private claim.

<=
br clear=3D"none">
On Mon Feb 16 201=
5 at 7:36:23 AM Justin Richer <jricher@mit.edu> wrote:
Another question is whether or not you can user rights d=
elegation (ie vanilla OAuth) or if you really do need impersonation. You ma=
y be able to get the desired results with less complexity that way.


-- Justin

/ Sent from my phone /


-------- Original message --------
From: Bill Burke <bbur=
ke@redhat.com> 
Date:02/16/2015  10:20 =
AM  (GMT-05:00) 
To: Bill Mills <wmills_92105@yahoo.com>, Justi=
n Richer <jricher@mit.edu>, oauth <oauth@ietf.org=
> 
Cc:  
Subject: Re: [OAUTH-WG]=
 user impersonation protocol? 

Yeah, I=
 know its risky, but that's the requirement.  Was just wondering 
if there was any protocol work being done around it, so that =
we could 
avoid doing a lot of the legwork to make it saf=
e/effective.  Currently 
for us, we need to do this =
between two separate IDPs, which is where the 
protocol w=
ork comes in...If it was just a single IDP managing 
ever=
ything, then it would just be an internal custom IDP feature.

Thanks all.


On 2/16/2015 12:37 AM, Bill Mills wrote=
:
> User impersonation is very very risky.  The l=
egal aspects of it must be
> considered.  There's=
 a lot of work to do to make it safe/effective.
>
> Issuing a scoped token that allows ready only access can=
 work with the
> above caveats.  Then properties/=
componenets have to explicitly support
> the new scope=
 and do the right thing.
>
>
> On Sunday, February 15, 2015 8:34 PM, Justin Richer <=
jricher@mit.edu> wrote:=

>
>
> For t=
his case you'd want to be very careful about who was able to do
> such impersonation, obviously, but it's doable today with custo=
m IdP
> behavior. You can simply use OpenID Connect an=
d have the IdP issue an id
> token for the target user=
 instead of the "actual" current user account.
>
> I would also suggest considering adding a custom claim to=
 the id token
> to indicate this is taking place. That=
 way you can differentiate where
> needed, including i=
n logs.
>
> -- Justin
>
> / Sent from my phone /
>
>
> -------- Original messa=
ge --------
> From: Bill Burke <bburke@redhat.com>
&=
gt; Date:02/15/2015 10:55 PM (GMT-05:00)
> To: oauth &=
lt;oauth@ietf.org>
> Cc:
> Subject: [OAUTH-WG] user impers=
onation protocol?
>
> We have a c=
ase where we want to allow a logged in admin user to
>=
 impersonate another user so that they can visit differents browser apps> as that user (So they can see everything that the user=
 sees through
> their browser).
>=

> Anybody know of any protocol work being done here i=
n the OAuth group or
> some other IETF or even Connect=
 effort that would support something like
> this?
>
> Thanks,
>> Bill
>
> --<=
br clear=3D"none">> Bill Burke
> JBoss, a division =
of Red Hat
> http://bill.burkecentral=
.com
>
> ____________________=
___________________________
> OAuth mailing lis=
t
> OAuth@i=
etf.org
> https://w=
ww.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> <=
a rel=3D"nofollow" shape=3D"rect" target=3D"_blank" href=3D"https://www.iet=
f.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/=
oauth

>
>
-- 
Bill Burke
JBoss, a=
 division of Red Hat
http://bill.burkece=
ntral.com
______________________________=
_________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/l=
istinfo/oauth




  
   
 

------=_Part_7820861_909648758.1424121634776--


From nobody Mon Feb 16 14:26:34 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32F41A88B2 for ; Mon, 16 Feb 2015 14:26:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd3WGy7vdIso for ; Mon, 16 Feb 2015 14:26:30 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601731A6ED9 for ; Mon, 16 Feb 2015 14:26:30 -0800 (PST)
Received: from CH1PR03CA005.namprd03.prod.outlook.com (10.255.156.150) by BLUPR03MB603.namprd03.prod.outlook.com (10.255.124.40) with Microsoft SMTP Server (TLS) id 15.1.87.18; Mon, 16 Feb 2015 22:26:29 +0000
Received: from BY2FFO11FD049.protection.gbl (10.255.156.132) by CH1PR03CA005.outlook.office365.com (10.255.156.150) with Microsoft SMTP Server (TLS) id 15.1.87.18 via Frontend Transport; Mon, 16 Feb 2015 22:26:28 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD049.mail.protection.outlook.com (10.1.15.186) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Mon, 16 Feb 2015 22:26:28 +0000
Received: from TK5EX14MBXC290.redmond.corp.microsoft.com ([169.254.1.33]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0224.003; Mon, 16 Feb 2015 22:25:56 +0000
From: Mike Jones 
To: Bill Burke , oauth 
Thread-Topic: [OAUTH-WG] user impersonation protocol?
Thread-Index: AQHQSf4/iGZiBeogw0O/wAb+y9wR0pzzxrwAgAACFACAABGs0A==
Date: Mon, 16 Feb 2015 22:25:55 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943A222C54D@TK5EX14MBXC290.redmond.corp.microsoft.com>
References:  <1363965451.7820862.1424121634785.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <1363965451.7820862.1424121634785.JavaMail.yahoo@mail.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.79]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943A222C54DTK5EX14MBXC290r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com;  client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; redhat.com; dkim=none (message not signed) header.d=none;
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(51704005)(164054003)(24454002)(479174004)(377454003)(16236675004)(2950100001)(62966003)(15975445007)(102836002)(104016003)(19580395003)(19580405001)(2656002)(87936001)(6806004)(85806002)(86612001)(2900100001)(46102003)(2920100001)(77156002)(1720100001)(512874002)(50986999)(66066001)(76176999)(19617315012)(587094005)(86362001)(54356999)(106466001)(106116001)(92566002)(107886001)(16601075003)(84326002)(55846006)(19625305001)(19300405004)(33656002)(19625215002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB603; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; LANG:en; 
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB603;
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR03MB603; 
X-Forefront-PRVS: 0489CFBAC9
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB603;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2015 22:26:28.6317 (UTC)
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB603
Archived-At: 
Subject: Re: [OAUTH-WG] user impersonation protocol?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Feb 2015 22:26:33 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943A222C54DTK5EX14MBXC290r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIHNwZWNpZmljYXRpb24gaXMgZGVzaWduZWQg
Zm9yIHVzZSBjYXNlcyBzdWNoIGFzIHlvdXJzLiAgUXVvdGluZyBmcm9tIHRoZSBhYnN0cmFjdDoN
CiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGhvdyB0byByZXF1ZXN0IGFuZCBvYnRhaW4g
U2VjdXJpdHkgVG9rZW5zDQogICBmcm9tIE9BdXRoIEF1dGhvcml6YXRpb24gU2VydmVycywgaW5j
bHVkaW5nIGVuYWJsaW5nIG9uZSBwYXJ0eSB0byBhY3QNCiAgIG9uIGJlaGFsZiBvZiBhbm90aGVy
IG9yIGVuYWJsaW5nIG9uZSBwYXJ0eSB0byBkZWxlZ2F0ZSBhdXRob3JpdHkgdG8NCiAgIGFub3Ro
ZXIuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJpbGwgTWlsbHMNClNlbnQ6IE1vbmRheSwgRmVicnVh
cnkgMTYsIDIwMTUgMToyMSBQTQ0KVG86IFdpbGxpYW0gRGVubmlzczsgSnVzdGluIFJpY2hlcjsg
QmlsbCBCdXJrZTsgb2F1dGgNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHVzZXIgaW1wZXJzb25h
dGlvbiBwcm90b2NvbD8NCg0KU3RyYWlnaHQgaW1wZXJzb25hdGlvbiB3aXRoIG5vIGxpbWl0YXRp
b25zIGlzbid0IGEgZ29vZCBzb2x1dGlvbiBpbiB0aGUgbG9uZyBydW4uDQoNCk9uIE1vbmRheSwg
RmVicnVhcnkgMTYsIDIwMTUgMToxMyBQTSwgV2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzc0Bnb29n
bGUuY29tPG1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tPj4gd3JvdGU6DQoNCkkgbGVkIGEgZGlz
Y3Vzc2lvbiBvbiBhIHJlbGF0ZWQgdG9waWMgYXQgYSByZWNlbnQgSUlXIChzcGVjaWZpY2FsbHkg
ZXhwbG9yaW5nIHRoZSAiYWNjb3VudCBzaGFyaW5nIiB1c2UgY2FzZSksIHRoZSBub3RlcyBhcmUg
aGVyZTogaHR0cDovL2lpdy5pZGNvbW1vbnMubmV0L0FjY291bnRfU2hhcmluZ19hdF90aGVfSURQ
XyhJZGVudGl0eV9Qcm92aWRlcikuICBJdCB3YXMgYW4gaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiwg
dGhlIHdob2xlIHRvcGljIG9mIGltcGVyc29uYXRpb24gY2VydGFpbmx5IHJhaXNlcyBhIGxvdCBv
ZiBwb2xpY3kgcXVlc3Rpb25zLg0KDQpBcyBmb3IgdGhlIHRlY2huaWNhbCBpbXBsZW1lbnRhdGlv
biwgb3VyIGNvbmNsdXNpb24gd2FzIHRoYXQgdGhlIHNpbXBsZXN0IGFwcHJvYWNoIGZvciBpbXBl
cnNvbmF0aW9uIHdvdWxkIGJlIHRvIGNvbnRpbnVlIHRvIHN1cHBseSBhbiBJRCBUb2tlbiBmb3Ig
dGhlIHRhcmdldCB1c2VyIChpLmUuICdzdWInIHJlcHJlc2VudHMgdGhlIHVzZXIgYmVpbmcgaW1w
ZXJzb25hdGVkKSwgYW5kIGFkZCBhbiBhZGRpdGlvbmFsIEpXVCBjbGFpbSBmb3IgdGhlIHVzZXIg
ZG9pbmcgdGhlIGltcGVyc29uYXRpb24gKGUuZy4gJ2lwYicgbWVhbmluZyAiaW1wZXJzb25hdGVk
IGJ5IikuDQoNClRodXMsIGFueSByZWx5aW5nIHBhcnR5IHdobyBkb2Vzbid0IHVuZGVyc3RhbmQg
dGhpcyBjbGFpbSBjb250aW51ZXMgdG8gd29yayBhcyBiZWZvcmUgKG9ibGl2aW91cyB0byB0aGUg
ZmFjdCB0aGUgdXNlciBpcyBiZWluZyBpbXBlcnNvbmF0ZWQpLCBhbmQgdGhvc2Ugd2hvIHVuZGVy
c3RhbmQgdGhlIGNsYWltIGFuZCBjYXJlIGFib3V0IGltcGVyc29uYXRpb24gY2FuIHRha2UgYWN0
aW9uIChlLmcuIGxvZyBhIGJldHRlciBhdWRpdCB0cmFpbCwgbGltaXQgc29tZSBmdW5jdGlvbmFs
aXR5IG9yIG91dHJpZ2h0IGJsb2NrIHRoZSBiZWhhdmlvcikuDQoNCklmIHRoaXMgYXBwcm9hY2gg
c291bmRzIGludGVyZXN0aW5nIHRvIHlvdSwgcGVyaGFwcyB3ZSBjb3VsZCBmb3JtYWxseSByZWdp
c3RlciAmIHN0YW5kYXJkaXNlIHRoZSAnaXBiJyBjbGFpbS4gIE9mIGNvdXJzZSwgYW55b25lIGNh
biB1c2UgdGhpcyB0ZWNobmlxdWUgdG9kYXkgdmlhIGEgcHJpdmF0ZSBjbGFpbTxodHRwOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTMyI3NlY3Rp
b24tNC4zPi4NCg0KDQpPbiBNb24gRmViIDE2IDIwMTUgYXQgNzozNjoyMyBBTSBKdXN0aW4gUmlj
aGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KQW5v
dGhlciBxdWVzdGlvbiBpcyB3aGV0aGVyIG9yIG5vdCB5b3UgY2FuIHVzZXIgcmlnaHRzIGRlbGVn
YXRpb24gKGllIHZhbmlsbGEgT0F1dGgpIG9yIGlmIHlvdSByZWFsbHkgZG8gbmVlZCBpbXBlcnNv
bmF0aW9uLiBZb3UgbWF5IGJlIGFibGUgdG8gZ2V0IHRoZSBkZXNpcmVkIHJlc3VsdHMgd2l0aCBs
ZXNzIGNvbXBsZXhpdHkgdGhhdCB3YXkuDQoNCg0KLS0gSnVzdGluDQoNCi8gU2VudCBmcm9tIG15
IHBob25lIC8NCg0KDQotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tDQpGcm9tOiBC
aWxsIEJ1cmtlIDxiYnVya2VAcmVkaGF0LmNvbTxtYWlsdG86YmJ1cmtlQHJlZGhhdC5jb20+Pg0K
RGF0ZTowMi8xNi8yMDE1IDEwOjIwIEFNIChHTVQtMDU6MDApDQpUbzogQmlsbCBNaWxscyA8d21p
bGxzXzkyMTA1QHlhaG9vLmNvbTxtYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4+LCBKdXN0
aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+LCBvYXV0
aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NCkNjOg0KU3ViamVjdDog
UmU6IFtPQVVUSC1XR10gdXNlciBpbXBlcnNvbmF0aW9uIHByb3RvY29sPw0KDQpZZWFoLCBJIGtu
b3cgaXRzIHJpc2t5LCBidXQgdGhhdCdzIHRoZSByZXF1aXJlbWVudC4gIFdhcyBqdXN0IHdvbmRl
cmluZw0KaWYgdGhlcmUgd2FzIGFueSBwcm90b2NvbCB3b3JrIGJlaW5nIGRvbmUgYXJvdW5kIGl0
LCBzbyB0aGF0IHdlIGNvdWxkDQphdm9pZCBkb2luZyBhIGxvdCBvZiB0aGUgbGVnd29yayB0byBt
YWtlIGl0IHNhZmUvZWZmZWN0aXZlLiAgQ3VycmVudGx5DQpmb3IgdXMsIHdlIG5lZWQgdG8gZG8g
dGhpcyBiZXR3ZWVuIHR3byBzZXBhcmF0ZSBJRFBzLCB3aGljaCBpcyB3aGVyZSB0aGUNCnByb3Rv
Y29sIHdvcmsgY29tZXMgaW4uLi5JZiBpdCB3YXMganVzdCBhIHNpbmdsZSBJRFAgbWFuYWdpbmcN
CmV2ZXJ5dGhpbmcsIHRoZW4gaXQgd291bGQganVzdCBiZSBhbiBpbnRlcm5hbCBjdXN0b20gSURQ
IGZlYXR1cmUuDQoNClRoYW5rcyBhbGwuDQoNCg0KDQpPbiAyLzE2LzIwMTUgMTI6MzcgQU0sIEJp
bGwgTWlsbHMgd3JvdGU6DQo+IFVzZXIgaW1wZXJzb25hdGlvbiBpcyB2ZXJ5IHZlcnkgcmlza3ku
ICBUaGUgbGVnYWwgYXNwZWN0cyBvZiBpdCBtdXN0IGJlDQo+IGNvbnNpZGVyZWQuICBUaGVyZSdz
IGEgbG90IG9mIHdvcmsgdG8gZG8gdG8gbWFrZSBpdCBzYWZlL2VmZmVjdGl2ZS4NCj4NCj4gSXNz
dWluZyBhIHNjb3BlZCB0b2tlbiB0aGF0IGFsbG93cyByZWFkeSBvbmx5IGFjY2VzcyBjYW4gd29y
ayB3aXRoIHRoZQ0KPiBhYm92ZSBjYXZlYXRzLiAgVGhlbiBwcm9wZXJ0aWVzL2NvbXBvbmVuZXRz
IGhhdmUgdG8gZXhwbGljaXRseSBzdXBwb3J0DQo+IHRoZSBuZXcgc2NvcGUgYW5kIGRvIHRoZSBy
aWdodCB0aGluZy4NCj4NCj4NCj4gT24gU3VuZGF5LCBGZWJydWFyeSAxNSwgMjAxNSA4OjM0IFBN
LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+
IHdyb3RlOg0KPg0KPg0KPiBGb3IgdGhpcyBjYXNlIHlvdSdkIHdhbnQgdG8gYmUgdmVyeSBjYXJl
ZnVsIGFib3V0IHdobyB3YXMgYWJsZSB0byBkbw0KPiBzdWNoIGltcGVyc29uYXRpb24sIG9idmlv
dXNseSwgYnV0IGl0J3MgZG9hYmxlIHRvZGF5IHdpdGggY3VzdG9tIElkUA0KPiBiZWhhdmlvci4g
WW91IGNhbiBzaW1wbHkgdXNlIE9wZW5JRCBDb25uZWN0IGFuZCBoYXZlIHRoZSBJZFAgaXNzdWUg
YW4gaWQNCj4gdG9rZW4gZm9yIHRoZSB0YXJnZXQgdXNlciBpbnN0ZWFkIG9mIHRoZSAiYWN0dWFs
IiBjdXJyZW50IHVzZXIgYWNjb3VudC4NCj4NCj4gSSB3b3VsZCBhbHNvIHN1Z2dlc3QgY29uc2lk
ZXJpbmcgYWRkaW5nIGEgY3VzdG9tIGNsYWltIHRvIHRoZSBpZCB0b2tlbg0KPiB0byBpbmRpY2F0
ZSB0aGlzIGlzIHRha2luZyBwbGFjZS4gVGhhdCB3YXkgeW91IGNhbiBkaWZmZXJlbnRpYXRlIHdo
ZXJlDQo+IG5lZWRlZCwgaW5jbHVkaW5nIGluIGxvZ3MuDQo+DQo+IC0tIEp1c3Rpbg0KPg0KPiAv
IFNlbnQgZnJvbSBteSBwaG9uZSAvDQo+DQo+DQo+IC0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2Ug
LS0tLS0tLS0NCj4gRnJvbTogQmlsbCBCdXJrZSA8YmJ1cmtlQHJlZGhhdC5jb208bWFpbHRvOmJi
dXJrZUByZWRoYXQuY29tPj4NCj4gRGF0ZTowMi8xNS8yMDE1IDEwOjU1IFBNIChHTVQtMDU6MDAp
DQo+IFRvOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NCj4g
Q2M6DQo+IFN1YmplY3Q6IFtPQVVUSC1XR10gdXNlciBpbXBlcnNvbmF0aW9uIHByb3RvY29sPw0K
Pg0KPiBXZSBoYXZlIGEgY2FzZSB3aGVyZSB3ZSB3YW50IHRvIGFsbG93IGEgbG9nZ2VkIGluIGFk
bWluIHVzZXIgdG8NCj4gaW1wZXJzb25hdGUgYW5vdGhlciB1c2VyIHNvIHRoYXQgdGhleSBjYW4g
dmlzaXQgZGlmZmVyZW50cyBicm93c2VyIGFwcHMNCj4gYXMgdGhhdCB1c2VyIChTbyB0aGV5IGNh
biBzZWUgZXZlcnl0aGluZyB0aGF0IHRoZSB1c2VyIHNlZXMgdGhyb3VnaA0KPiB0aGVpciBicm93
c2VyKS4NCj4NCj4gQW55Ym9keSBrbm93IG9mIGFueSBwcm90b2NvbCB3b3JrIGJlaW5nIGRvbmUg
aGVyZSBpbiB0aGUgT0F1dGggZ3JvdXAgb3INCj4gc29tZSBvdGhlciBJRVRGIG9yIGV2ZW4gQ29u
bmVjdCBlZmZvcnQgdGhhdCB3b3VsZCBzdXBwb3J0IHNvbWV0aGluZyBsaWtlDQo+IHRoaXM/DQo+
DQo+IFRoYW5rcywNCj4NCj4gQmlsbA0KPg0KPiAtLQ0KPiBCaWxsIEJ1cmtlDQo+IEpCb3NzLCBh
IGRpdmlzaW9uIG9mIFJlZCBIYXQNCj4gaHR0cDovL2JpbGwuYnVya2VjZW50cmFsLmNvbTxodHRw
Oi8vYmlsbC5idXJrZWNlbnRyYWwuY29tLz4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGll
dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aA0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmc8
bWFpbHRvOk9BdXRoQGlldGYub3JnPiA8bWFpbHRvOk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0
aEBpZXRmLm9yZz4+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgNCg0KPg0KPg0KDQotLQ0KQmlsbCBCdXJrZQ0KSkJvc3MsIGEgZGl2aXNpb24gb2YgUmVkIEhh
dA0KaHR0cDovL2JpbGwuYnVya2VjZW50cmFsLmNvbTxodHRwOi8vYmlsbC5idXJrZWNlbnRyYWwu
Y29tLz4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP
QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K

--_000_4E1F6AAD24975D4BA5B1680429673943A222C54DTK5EX14MBXC290r_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v
c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N
c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU
aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN
TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu
TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu
OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0
eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
bXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh
bnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6
IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l
dyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u
dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47
DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7
cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48
IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0
PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5
b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9
ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5UaGUgT0F1dGggMi4wIFRva2VuIEV4Y2hhbmdlDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIj5odHRwOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlPC9hPiBzcGVjaWZp
Y2F0aW9uIGlzIGRlc2lnbmVkIGZvciB1c2UgY2FzZXMgc3VjaCBhcyB5b3Vycy4mbmJzcDsgUXVv
dGluZyBmcm9tIHRoZSBhYnN0cmFjdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgaG93
IHRvIHJlcXVlc3QgYW5kIG9idGFpbiBTZWN1cml0eSBUb2tlbnM8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZnJvbSBPQXV0aCBBdXRo
b3JpemF0aW9uIFNlcnZlcnMsIGluY2x1ZGluZyBlbmFibGluZyBvbmUgcGFydHkgdG8gYWN0PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4i
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7
IG9uIGJlaGFsZiBvZiBhbm90aGVyIG9yIGVuYWJsaW5nIG9uZSBwYXJ0eSB0byBkZWxlZ2F0ZSBh
dXRob3JpdHkgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij4mbmJzcDsmbmJzcDsgYW5vdGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzpv
YXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CaWxsIE1pbGxzPGJy
Pg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMTYsIDIwMTUgMToyMSBQTTxicj4NCjxi
PlRvOjwvYj4gV2lsbGlhbSBEZW5uaXNzOyBKdXN0aW4gUmljaGVyOyBCaWxsIEJ1cmtlOyBvYXV0
aDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSB1c2VyIGltcGVyc29uYXRpb24g
cHJvdG9jb2w/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgaWQ9Inl1aV8z
XzE2XzBfMV8xNDIzNzk5NDQzMzY2XzcyNDAyNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi
bGFjayI+U3RyYWlnaHQgaW1wZXJzb25hdGlvbiB3aXRoIG5vIGxpbWl0YXRpb25zIGlzbid0IGEg
Z29vZCBzb2x1dGlvbiBpbiB0aGUgbG9uZyBydW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu
MHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5PbiBNb25kYXksIEZl
YnJ1YXJ5IDE2LCAyMDE1IDE6MTMgUE0sIFdpbGxpYW0gRGVubmlzcyAmbHQ7PGEgaHJlZj0ibWFp
bHRvOndkZW5uaXNzQGdvb2dsZS5jb20iPndkZW5uaXNzQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90
ZTo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGlkPSJ5aXYxNjg2MDI3MTU4Ij4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgbGVkIGEgZGlzY3Vzc2lvbiBvbiBhIHJl
bGF0ZWQgdG9waWMgYXQgYSByZWNlbnQgSUlXIChzcGVjaWZpY2FsbHkgZXhwbG9yaW5nIHRoZSAm
cXVvdDthY2NvdW50IHNoYXJpbmcmcXVvdDsgdXNlIGNhc2UpLCB0aGUgbm90ZXMgYXJlIGhlcmU6
Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2lpdy5pZGNvbW1vbnMubmV0L0FjY291bnRfU2hhcmluZ19h
dF90aGVfSURQXyhJZGVudGl0eV9Qcm92aWRlcikiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vaWl3
LmlkY29tbW9ucy5uZXQvQWNjb3VudF9TaGFyaW5nX2F0X3RoZV9JRFBfKElkZW50aXR5X1Byb3Zp
ZGVyKTwvYT4uJm5ic3A7DQogSXQgd2FzIGFuIGludGVyZXN0aW5nIGRpc2N1c3Npb24sIHRoZSB3
aG9sZSB0b3BpYyBvZiBpbXBlcnNvbmF0aW9uIGNlcnRhaW5seSByYWlzZXMgYSBsb3Qgb2YgcG9s
aWN5IHF1ZXN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFzIGZvciB0aGUgdGVjaG5pY2FsIGltcGxlbWVu
dGF0aW9uLCBvdXIgY29uY2x1c2lvbiB3YXMgdGhhdCB0aGUgc2ltcGxlc3QgYXBwcm9hY2ggZm9y
IGltcGVyc29uYXRpb24gd291bGQgYmUgdG8gY29udGludWUgdG8gc3VwcGx5IGFuIElEIFRva2Vu
IGZvcg0KIHRoZSB0YXJnZXQgdXNlciAoaS5lLiAnc3ViJyByZXByZXNlbnRzIHRoZSB1c2VyIGJl
aW5nIGltcGVyc29uYXRlZCksIGFuZCBhZGQgYW4gYWRkaXRpb25hbCBKV1QgY2xhaW0gZm9yIHRo
ZSB1c2VyIGRvaW5nIHRoZSBpbXBlcnNvbmF0aW9uIChlLmcuICdpcGInIG1lYW5pbmcgJnF1b3Q7
aW1wZXJzb25hdGVkIGJ5JnF1b3Q7KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGh1cywgYW55IHJlbHlpbmcgcGFydHkgd2hvIGRvZXNu
J3QgdW5kZXJzdGFuZCB0aGlzIGNsYWltIGNvbnRpbnVlcyB0byB3b3JrIGFzIGJlZm9yZSAob2Js
aXZpb3VzIHRvIHRoZSBmYWN0IHRoZSB1c2VyIGlzIGJlaW5nIGltcGVyc29uYXRlZCksIGFuZCB0
aG9zZQ0KIHdobyB1bmRlcnN0YW5kIHRoZSBjbGFpbSBhbmQgY2FyZSBhYm91dCBpbXBlcnNvbmF0
aW9uIGNhbiB0YWtlIGFjdGlvbiAoZS5nLiBsb2cgYSBiZXR0ZXIgYXVkaXQgdHJhaWwsIGxpbWl0
IHNvbWUgZnVuY3Rpb25hbGl0eSBvciBvdXRyaWdodCBibG9jayB0aGUgYmVoYXZpb3IpLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiB0aGlzIGFwcHJv
YWNoIHNvdW5kcyBpbnRlcmVzdGluZyB0byB5b3UsIHBlcmhhcHMgd2UgY291bGQgZm9ybWFsbHkg
cmVnaXN0ZXIgJmFtcDsgc3RhbmRhcmRpc2UgdGhlICdpcGInIGNsYWltLiZuYnNwOyBPZiBjb3Vy
c2UsIGFueW9uZSBjYW4gdXNlIHRoaXMgdGVjaG5pcXVlDQogdG9kYXkgdmlhIGEmbmJzcDs8YSBo
cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2Vi
LXRva2VuLTMyI3NlY3Rpb24tNC4zIiB0YXJnZXQ9Il9ibGFuayI+cHJpdmF0ZSBjbGFpbTwvYT4u
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+T24gTW9uIEZlYiAx
NiAyMDE1IGF0IDc6MzY6MjMgQU0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy
aWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+
QW5vdGhlciBxdWVzdGlvbiBpcyB3aGV0aGVyIG9yIG5vdCB5b3UgY2FuIHVzZXIgcmlnaHRzIGRl
bGVnYXRpb24gKGllIHZhbmlsbGEgT0F1dGgpIG9yIGlmIHlvdSByZWFsbHkgZG8gbmVlZCBpbXBl
cnNvbmF0aW9uLiBZb3UgbWF5IGJlIGFibGUgdG8gZ2V0DQogdGhlIGRlc2lyZWQgcmVzdWx0cyB3
aXRoIGxlc3MgY29tcGxleGl0eSB0aGF0IHdheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj
a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6YmxhY2siPi0tIEp1c3RpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LyBT
ZW50IGZyb20gbXkgcGhvbmUgLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0t
LS0tLS0tPGJyPg0KRnJvbTogQmlsbCBCdXJrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJidXJrZUBy
ZWRoYXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmJ1cmtlQHJlZGhhdC5jb208L2E+Jmd0Ow0KPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGF0ZTow
Mi8xNi8yMDE1IDEwOjIwIEFNIChHTVQtMDU6MDApDQo8YnI+DQpUbzogQmlsbCBNaWxscyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj53
bWlsbHNfOTIxMDVAeWFob28uY29tPC9hPiZndDssIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9
Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8
L2E+Jmd0Oywgb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDsNCjxicj4NCkNjOiA8YnI+DQpTdWJqZWN0
OiBSZTogW09BVVRILVdHXSB1c2VyIGltcGVyc29uYXRpb24gcHJvdG9jb2w/IDxicj4NCjxicj4N
ClllYWgsIEkga25vdyBpdHMgcmlza3ksIGJ1dCB0aGF0J3MgdGhlIHJlcXVpcmVtZW50LiZuYnNw
OyBXYXMganVzdCB3b25kZXJpbmcgPGJyPg0KaWYgdGhlcmUgd2FzIGFueSBwcm90b2NvbCB3b3Jr
IGJlaW5nIGRvbmUgYXJvdW5kIGl0LCBzbyB0aGF0IHdlIGNvdWxkIDxicj4NCmF2b2lkIGRvaW5n
IGEgbG90IG9mIHRoZSBsZWd3b3JrIHRvIG1ha2UgaXQgc2FmZS9lZmZlY3RpdmUuJm5ic3A7IEN1
cnJlbnRseSA8YnI+DQpmb3IgdXMsIHdlIG5lZWQgdG8gZG8gdGhpcyBiZXR3ZWVuIHR3byBzZXBh
cmF0ZSBJRFBzLCB3aGljaCBpcyB3aGVyZSB0aGUgPGJyPg0KcHJvdG9jb2wgd29yayBjb21lcyBp
bi4uLklmIGl0IHdhcyBqdXN0IGEgc2luZ2xlIElEUCBtYW5hZ2luZyA8YnI+DQpldmVyeXRoaW5n
LCB0aGVuIGl0IHdvdWxkIGp1c3QgYmUgYW4gaW50ZXJuYWwgY3VzdG9tIElEUCBmZWF0dXJlLjxi
cj4NCjxicj4NClRoYW5rcyBhbGwuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gMi8xNi8yMDE1
IDEyOjM3IEFNLCBCaWxsIE1pbGxzIHdyb3RlOjxicj4NCiZndDsgVXNlciBpbXBlcnNvbmF0aW9u
IGlzIHZlcnkgdmVyeSByaXNreS4mbmJzcDsgVGhlIGxlZ2FsIGFzcGVjdHMgb2YgaXQgbXVzdCBi
ZTxicj4NCiZndDsgY29uc2lkZXJlZC4mbmJzcDsgVGhlcmUncyBhIGxvdCBvZiB3b3JrIHRvIGRv
IHRvIG1ha2UgaXQgc2FmZS9lZmZlY3RpdmUuPGJyPg0KJmd0Ozxicj4NCiZndDsgSXNzdWluZyBh
IHNjb3BlZCB0b2tlbiB0aGF0IGFsbG93cyByZWFkeSBvbmx5IGFjY2VzcyBjYW4gd29yayB3aXRo
IHRoZTxicj4NCiZndDsgYWJvdmUgY2F2ZWF0cy4mbmJzcDsgVGhlbiBwcm9wZXJ0aWVzL2NvbXBv
bmVuZXRzIGhhdmUgdG8gZXhwbGljaXRseSBzdXBwb3J0PGJyPg0KJmd0OyB0aGUgbmV3IHNjb3Bl
IGFuZCBkbyB0aGUgcmlnaHQgdGhpbmcuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9u
IFN1bmRheSwgRmVicnVhcnkgMTUsIDIwMTUgODozNCBQTSwgSnVzdGluIFJpY2hlciAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0
LmVkdTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBGb3IgdGhp
cyBjYXNlIHlvdSdkIHdhbnQgdG8gYmUgdmVyeSBjYXJlZnVsIGFib3V0IHdobyB3YXMgYWJsZSB0
byBkbzxicj4NCiZndDsgc3VjaCBpbXBlcnNvbmF0aW9uLCBvYnZpb3VzbHksIGJ1dCBpdCdzIGRv
YWJsZSB0b2RheSB3aXRoIGN1c3RvbSBJZFA8YnI+DQomZ3Q7IGJlaGF2aW9yLiBZb3UgY2FuIHNp
bXBseSB1c2UgT3BlbklEIENvbm5lY3QgYW5kIGhhdmUgdGhlIElkUCBpc3N1ZSBhbiBpZDxicj4N
CiZndDsgdG9rZW4gZm9yIHRoZSB0YXJnZXQgdXNlciBpbnN0ZWFkIG9mIHRoZSAmcXVvdDthY3R1
YWwmcXVvdDsgY3VycmVudCB1c2VyIGFjY291bnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB3b3Vs
ZCBhbHNvIHN1Z2dlc3QgY29uc2lkZXJpbmcgYWRkaW5nIGEgY3VzdG9tIGNsYWltIHRvIHRoZSBp
ZCB0b2tlbjxicj4NCiZndDsgdG8gaW5kaWNhdGUgdGhpcyBpcyB0YWtpbmcgcGxhY2UuIFRoYXQg
d2F5IHlvdSBjYW4gZGlmZmVyZW50aWF0ZSB3aGVyZTxicj4NCiZndDsgbmVlZGVkLCBpbmNsdWRp
bmcgaW4gbG9ncy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLSBKdXN0aW48YnI+DQomZ3Q7PGJyPg0K
Jmd0OyAvIFNlbnQgZnJvbSBteSBwaG9uZSAvPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7
IC0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+DQomZ3Q7IEZyb206IEJpbGwg
QnVya2UgJmx0OzxhIGhyZWY9Im1haWx0bzpiYnVya2VAcmVkaGF0LmNvbSIgdGFyZ2V0PSJfYmxh
bmsiPmJidXJrZUByZWRoYXQuY29tPC9hPiZndDs8YnI+DQomZ3Q7IERhdGU6MDIvMTUvMjAxNSAx
MDo1NSBQTSAoR01ULTA1OjAwKTxicj4NCiZndDsgVG86IG9hdXRoICZsdDs8YSBocmVmPSJtYWls
dG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7
PGJyPg0KJmd0OyBDYzo8YnI+DQomZ3Q7IFN1YmplY3Q6IFtPQVVUSC1XR10gdXNlciBpbXBlcnNv
bmF0aW9uIHByb3RvY29sPzxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGhhdmUgYSBjYXNlIHdoZXJl
IHdlIHdhbnQgdG8gYWxsb3cgYSBsb2dnZWQgaW4gYWRtaW4gdXNlciB0bzxicj4NCiZndDsgaW1w
ZXJzb25hdGUgYW5vdGhlciB1c2VyIHNvIHRoYXQgdGhleSBjYW4gdmlzaXQgZGlmZmVyZW50cyBi
cm93c2VyIGFwcHM8YnI+DQomZ3Q7IGFzIHRoYXQgdXNlciAoU28gdGhleSBjYW4gc2VlIGV2ZXJ5
dGhpbmcgdGhhdCB0aGUgdXNlciBzZWVzIHRocm91Z2g8YnI+DQomZ3Q7IHRoZWlyIGJyb3dzZXIp
Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEFueWJvZHkga25vdyBvZiBhbnkgcHJvdG9jb2wgd29yayBi
ZWluZyBkb25lIGhlcmUgaW4gdGhlIE9BdXRoIGdyb3VwIG9yPGJyPg0KJmd0OyBzb21lIG90aGVy
IElFVEYgb3IgZXZlbiBDb25uZWN0IGVmZm9ydCB0aGF0IHdvdWxkIHN1cHBvcnQgc29tZXRoaW5n
IGxpa2U8YnI+DQomZ3Q7IHRoaXM/PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZn
dDs8YnI+DQomZ3Q7IEJpbGw8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZndDsgQmlsbCBC
dXJrZTxicj4NCiZndDsgSkJvc3MsIGEgZGl2aXNpb24gb2YgUmVkIEhhdDxicj4NCiZndDsgPGEg
aHJlZj0iaHR0cDovL2JpbGwuYnVya2VjZW50cmFsLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRw
Oi8vYmlsbC5idXJrZWNlbnRyYWwuY29tPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBt
YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxi
cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9B
dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ICZsdDttYWls
dG86PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhA
aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp
diBpZD0ieWl2MTY4NjAyNzE1OHlxdGZkNTU5NjciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KJmd0
Ozxicj4NCiZndDs8YnI+DQo8YnI+DQotLSA8YnI+DQpCaWxsIEJ1cmtlPGJyPg0KSkJvc3MsIGEg
ZGl2aXNpb24gb2YgUmVkIEhhdDxicj4NCjxhIGhyZWY9Imh0dHA6Ly9iaWxsLmJ1cmtlY2VudHJh
bC5jb20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2JpbGwuYnVya2VjZW50cmFsLmNvbTwvYT48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ieWl2MTY4NjAy
NzE1OHlxdGZkNjA4NDgiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo
cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9y
ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_4E1F6AAD24975D4BA5B1680429673943A222C54DTK5EX14MBXC290r_--


From nobody Mon Feb 16 15:43:15 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03041A88F5 for ; Mon, 16 Feb 2015 15:43:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdcdQVDAEs1a for ; Mon, 16 Feb 2015 15:43:11 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92381A88EA for ; Mon, 16 Feb 2015 15:43:10 -0800 (PST)
Received: from DM2PR03CA0030.namprd03.prod.outlook.com (10.141.96.29) by BY2PR03MB393.namprd03.prod.outlook.com (10.141.141.12) with Microsoft SMTP Server (TLS) id 15.1.81.12; Mon, 16 Feb 2015 23:43:08 +0000
Received: from BN1AFFO11FD005.protection.gbl (2a01:111:f400:7c10::101) by DM2PR03CA0030.outlook.office365.com (2a01:111:e400:2428::29) with Microsoft SMTP Server (TLS) id 15.1.87.13 via Frontend Transport; Mon, 16 Feb 2015 23:43:07 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD005.mail.protection.outlook.com (10.58.52.65) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Mon, 16 Feb 2015 23:43:07 +0000
Received: from TK5EX14MBXC290.redmond.corp.microsoft.com ([169.254.1.33]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0224.003; Mon, 16 Feb 2015 23:42:31 +0000
From: Mike Jones 
To: Phil Hunt , Justin Richer 
Thread-Topic: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
Thread-Index: AQHQRk+KdTW6focrw0+qa3R3HLsnGpzsbP6AgAD/rACABoKlgA==
Date: Mon, 16 Feb 2015 23:42:30 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>
References:  <54DC2CB1.8090400@mit.edu> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.79]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com;  client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; oracle.com; dkim=none (message not signed) header.d=none;
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51914003)(24454002)(51704005)(479174004)(377454003)(43784003)(2950100001)(50986999)(92566002)(15975445007)(102836002)(15974865002)(46406003)(54356999)(86362001)(50466002)(104016003)(76176999)(33656002)(2900100001)(2920100001)(23726002)(55846006)(87936001)(6806004)(15395725005)(551544002)(19580405001)(19580395003)(2171001)(230783001)(62966003)(77156002)(86612001)(106466001)(2656002)(47776003)(46102003)(85806002)(106116001)(97756001)(66066001)(2690400003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB393; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; LANG:en; 
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB393;
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BY2PR03MB393; 
X-Forefront-PRVS: 0489CFBAC9
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB393;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2015 23:43:07.1473 (UTC)
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB393
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Feb 2015 23:43:14 -0000

A few responses and comments are inline below...

> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
> Sent: Thursday, February 12, 2015 11:47 AM
> To: Justin Richer
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
> On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
>
> Kathleen, thanks for the review. Responses inline, though I'm going to le=
t the other authors talk about their sections (deployment org, software ver=
sion, etc) directly.
>
> On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
> Thank you for your work on this draft and sorry for the delay in my revie=
w.  Before we progress to IETF last call, I'd like to see what we can resol=
ve from the list below.   I am looking at the IPR issues to see if we can r=
esolve the outstanding questions as well.
>
> The Shepherd report says the following:
>    The document shepherd has raised concerns regarding the fuzzy descript=
ion
>    of the actors (deployment organization, software API publisher, client
>    developer) and their impact on the protocol execution. The working
>    group did not seem to worry about these aspects though.
>
> I can see the point after reading the draft.  The interactions are writte=
n much more clearly in the security considerations section than where the f=
lows are described.  Can something be done to address these concerns?
>
> Section 1.2
> Deployment Organization definition:
> I highly recommend replacing the phrase "simple cloud deployment" with a =
description that accurately reflects what is intended.  If that's within a =
single service provider's network, a single data center, or a single hosted=
 data center, I think it would be more clear.
>
> Section 1.2 nit:
> Add the word "be" into the following term definition after "may":
>   Software API Publisher
>       The organization that defines a particular web accessible API that
>       may deployed in one or more deployment environments.
>
> [deferred to original author of this text Phil et. al for better wording]
>
> [Phil] Agreed with Kathleen's suggestion.

I also agree that the wording of the definitions could be clarified.  Justi=
n, do you want to take a first pass at this or would you like to take lead =
on this, Phil?

> Section 2:
>
> Why isn't a more secure option offered and set as the default for authent=
ication types? I know I've asked this before and the answer was just that y=
ou can add something to the registry, but setting HTTP Basic as the default=
 seems like a really bad choice. HOBA is on it's way to becoming an RFC fro=
m the HTTPAuth working group.  HTTPAuth also has an updated version of Basi=
c that is in IETF last call, but I know you are pointing to the OAuth 2.0 d=
ocument, so it would be that document that gets updated and not this draft.=
  The new version of HTTP Basic fixes some internationalization problems an=
d spells out the security issues much more clearly, so it probably doesn't =
matter too much to update the reference, but maybe makes it more clear that=
 basic is not a secure form of authentication.
>
> Can you provide some justification as to why this is okay to set basic as=
 the default and add that to the draft?  Section 2.3.1 of OAuth 2.0 just sa=
ys this MUST be implemented, but that any HTTP schemes can be used.  Why no=
t register another method and use that instead as the default?  You could u=
se digest and there is library support.  It's not a great answer, but sligh=
tly better than passwords with basic.  You could register HOBA and use that=
 instead, the only downside is limited library support at the moment.
>
> It was our intent to document the methods already defined for use with OA=
uth and provide a registration mechanism for distinguishing between them, n=
ot to create new client authentication mechanisms. Digest and HOBA simply a=
ren't defined for use with OAuth clients yet. It would be simple to do: put=
 the client id in the "username" field and the client secret in the "passwo=
rd" field of both algorithms. However, I don't believe it's a good idea to =
conflate those two goals in a single specification. We actually had other, =
more secure definitions in an earlier draft of this document (using a JWT s=
igned with a private key or a JWT signed with a shared key, specifically), =
but those were removed in order to focus on solving just the client registr=
ation problem. I agree with that decision of the WG.
>
> As other methods of client authentication are defined in the OAuth ecosys=
tem, they can register as valid values in the registry. I think it would be=
 a valuable output of this WG to define other client authentication mechani=
sms as a separate draft or an eventual update to RFC6749 (or both?).

HTTP Basic is set to the default because that's the default in RFC 6749 and=
 this specification is about registering clients for use with RFC 6749.  Tr=
ying to change the RFC 6749 default really isn't within the scope of this w=
ork.  (If that's done, it should probably be done in an http6749-bis spec.)=
  However, the spec does define a registry that new methods like HOBA can b=
e registered in when people want to use them.  (And if HOBA finishes before=
 Dynamic Registration, I'm fine adding a registry entry for it in this spec=
.)

If you're interested in the client_secret_jwt and private_key_jwt client au=
thentication methods that Justin alluded to, these are defined in Section 9=
 of OpenID Connect Core http://openid.net/specs/openid-connect-core-1_0.htm=
l#ClientAuthentication.

In relation to your internationalization comments Kathleen, note that Secti=
on 2.3.1 of RFC 6749 explicitly provides a mechanism for encoding internati=
onal strings for use with HTTP Basic.  This was added under the supervision=
 of Julian Reschke, I believe as a result of his WGLC comments.  So whether=
 this is the same as what the new version of HTTP Basic does or not, OAuth =
2.0 already does provide a standard way to use internationalized strings wi=
th HTTP Basic for OAuth client authentication.

> Section 2: Contacts:
>
> I noticed privacy is not dealt with until you get to the security conside=
rations section.  I'd prefer to see it with the definition, stating the add=
ress should be a general help address at the domain rather than directly to=
 an identifiable individual.  It may be good to set a default for what this=
 should be for consistency or give an example (think back to abuse@domain.c=
om)?
>
> The problem that I see with putting it inside the definition is that it m=
akes the definition text very long, as the definition sits in a list of oth=
er metadata items. We could add a forward pointer and an example easily eno=
ugh, though. Or we could move the privacy considerations section up as a su=
bsection here, though I don't know if that runs afoul of the RFC style guid=
elines for this new section.
>
>
>
> Software_id and software_version:
> Are there any guidelines as to how these should be represented?  There ar=
e several specifications on software_id (and platform).  Does consistency h=
ere matter or is this just meant to be human readable?
> Section 2.2 specifies some metadata values that are to be human readable,=
 should the above be in the list?  I would expect this list to be comprehen=
sive for clarity, rather than just examples since there aren't too many def=
ined here.
>
>
> [mostly deferred to Phil et. al, but note that software_id and software_v=
ersion are not intended to be human readable and don't need the multi-langu=
age support]

We should probably say that in the draft then.

> [Phil]
> I've added some more explanatory text. Note...some of this may be better =
put elsewhere.
>
> As to whether the values are human readable, I have no opinion. What matt=
ers most is unique matching.
>
>    software_id
>       A unique identifier (e.g. UUID) assigned by the developer or softwa=
re publisher
>       used by registration endpoints to identify client software to be dy=
namically registered.
>       Unlike "client_id", which is issued by the authorization server and=
 varies between
>       instances of software, the "software_id" SHOULD remain the same for=
 all client software
>       instances. The "software_id" SHOULD remain the same across multiple=
 software updates
>       or versions.

I'd revise the last two sentences of this as follows:

      Unlike "client_id", which is issued by the authorization server and m=
ay vary between
      instances of a piece of software, the "software_id" SHOULD remain the=
 same for all instances
      of a piece of software. The "software_id" SHOULD remain the same acro=
ss multiple software updates
      or versions of the same piece of software.

> software_version
>       A version identifier for the software identified by "software_id". =
 The
>       value of this field is a string that is intended to be compared
>       using string equality matching. Unlike "software_id", the value of =
the
>       "software_version" SHOULD change on any update to the client
>       software. A service provider MAY use "software_id" and "software_ve=
rsion" to
>       recognize approved software and version combinations approved for d=
ynamic registration.
>
> Let me know if you want more background.
>
>
> Section 3.2.1 & Privacy section
> For client_name and client_id and associated information, how is user pri=
vacy affected and what can be done to mitigate concerns?  The definition sh=
ould state that this is a public value and that it is specific to the softw=
are, not a person.  You have to get to the security consideration section b=
efore that is clear.  References are fine too, but some more information is=
 needed in the privacy section.  I'm left with a bunch of questions:
>   Can the client_name and client_id be tied to a person?
> The client name is common across all copies of the software (usually), so=
 no worries there. The ID represents an individual piece of software, not a=
 person, though if that person is the sole user of the instance of software=
 then I believe you're right that there are some privacy considerations tha=
t we should point that out. However, dynamic registration can actually help=
 mitigate this as well, since in the normal case (with no software statemen=
ts) there's no way to correlate instances of clients with each other.
>
>   Can the person be tracked by this?
>   Can other information be gathered about a system (and it's user) during=
 this process?
> Nothing gathered about the user during registration, as this happens in t=
he back channel outside the user's purview.
>
>   The information is used to dynamically register clients, what is logged=
?
>   What data is aggregated?
>   What can you tell about a client (time, location, travel, other persona=
l details that may be considered sensitive)?  I don't think this was covere=
d in the OAuth 2.0 RFC.
>   How is this addressed at the authorization server and other points?
>   The Security considerations talks about client_id as being short lived,=
 so they expire, but are these event logged or is that prohibited?
>
> Many of these questions seem to be completely dependent on the implementa=
tion of the authorization server, and I'm not really sure how (or if) to ad=
dress them in this draft. Any suggestions would be welcomed here.
>
> The client_id *could* be short lived, but they usually aren't. I don't se=
e any particular logging or tracking concerns using a dynamic OAuth client =
above using any other piece of software, ever. As such, I don't think it re=
quires special calling out here.
>
>
>
> 5. Security considerations
> The first paragraph is a repeat of text.  Can this just be in one place a=
nd use a pointer to the full text?  I like the requirement, but reading it =
once is enough.
>
> I think it was less onerous of a repeat when both simply said "use TLS", =
so some refactoring after the expansion of the text makes sense to me. Woul=
d it be better to have it upfront in the endpoint definition, or in the sec=
urity considerations?

Justin, do you want to make specific rewording proposals for this and the o=
ther editorial issues that were identified?

> --
>
> Best regards,
> Kathleen
>
> Thanks again for your review!
>
>  -- Justin

				Thanks all,
				-- Mike


From nobody Mon Feb 16 16:43:40 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839D81A8928 for ; Mon, 16 Feb 2015 16:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHSkKlT-zhYO for ; Mon, 16 Feb 2015 16:43:36 -0800 (PST)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFE21A88F5 for ; Mon, 16 Feb 2015 16:43:35 -0800 (PST)
X-AuditID: 1209190f-f79546d000007593-ed-54e28eb66c41
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 84.36.30099.6BE82E45; Mon, 16 Feb 2015 19:43:34 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t1H0hX0R007912; Mon, 16 Feb 2015 19:43:33 -0500
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1H0hVi0023121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 16 Feb 2015 19:43:32 -0500
Message-ID: <54E28EB1.7020504@mit.edu>
Date: Mon, 16 Feb 2015 19:43:29 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Mike Jones , Phil Hunt 
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0d3W9yjE4MIyAYu90z6xWJx8+4rN YsH8RnYHZo8lS34yebTu+Mvu8fHpLZYA5igum5TUnMyy1CJ9uwSujI4p3UwFa1Iqfl25y9zA eCOgi5GTQ0LARKL7xSZ2CFtM4sK99WxdjFwcQgKLmSQ2zFjECOFsZJSYeXI/VOY2k8StCdPA WngF1CRmb1zICmKzCKhK7O+dCBZnA7Knr2lhArFFBaIkZp9/wApRLyhxcuYTFhBbRMBP4u7p w2D1zED161dfBKsXFjCX+P/gDhPEsk+MEuuWnwHazMHBKZAocX5WIkS9rcSdubuZIWx5ie1v 5zBPYBSchWTFLCRls5CULWBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRropebWaKXmlK6iREU 1pyS/DsYvx1UOsQowMGoxMP7QvZhiBBrYllxZe4hRkkOJiVR3s29j0KE+JLyUyozEosz4otK c1KLDzFKcDArifC+ygPK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ 8E4BGSpYlJqeWpGWmVOCkGbi4AQZzgM0fCNIDW9xQWJucWY6RP4Uo6KUOG8/SEIAJJFRmgfX C0s7rxjFgV4R5uUFJiEhHmDKgut+BTSYCWhwJvN9kMEliQgpqQbGidYf/p7a21G+sCBqTuC5 iDMNUiv3L1/lrr3uyNT8J41Pfm+qNi1W+7FGICZ7nvyBSRucWf/PjPp7qCko+V/VM7l8cZer KV06LxL7rnW07DSfvCtS+t8UwZW5RlU5+VwPDZuZV14Mub6xu9w4Zt6Xv1nqZ+u+BBTcu6NW 9zN5S/TBa6Yr/3EyK7EUZyQaajEXFScCAMriGxYWAwAA
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Feb 2015 00:43:39 -0000

To Mike's last question below: I'd like Phil (and others if desired) to 
propose a clarified version of the "deployment organization", "software 
api publisher", and "client developer" if possible. With some text for 
that in hand I can tackle the rest given the feedback below.

  -- Justin

On 2/16/2015 6:42 PM, Mike Jones wrote:
> A few responses and comments are inline below...
>
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
>> Sent: Thursday, February 12, 2015 11:47 AM
>> To: Justin Richer
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>>
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>
>> On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
>>
>> Kathleen, thanks for the review. Responses inline, though I'm going to let the other authors talk about their sections (deployment org, software version, etc) directly.
>>
>> On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
>> Thank you for your work on this draft and sorry for the delay in my review.  Before we progress to IETF last call, I'd like to see what we can resolve from the list below.   I am looking at the IPR issues to see if we can resolve the outstanding questions as well.
>>
>> The Shepherd report says the following:
>>     The document shepherd has raised concerns regarding the fuzzy description
>>     of the actors (deployment organization, software API publisher, client
>>     developer) and their impact on the protocol execution. The working
>>     group did not seem to worry about these aspects though.
>>
>> I can see the point after reading the draft.  The interactions are written much more clearly in the security considerations section than where the flows are described.  Can something be done to address these concerns?
>>
>> Section 1.2
>> Deployment Organization definition:
>> I highly recommend replacing the phrase "simple cloud deployment" with a description that accurately reflects what is intended.  If that's within a single service provider's network, a single data center, or a single hosted data center, I think it would be more clear.
>>
>> Section 1.2 nit:
>> Add the word "be" into the following term definition after "may":
>>    Software API Publisher
>>        The organization that defines a particular web accessible API that
>>        may deployed in one or more deployment environments.
>>
>> [deferred to original author of this text Phil et. al for better wording]
>>
>> [Phil] Agreed with Kathleen's suggestion.
> I also agree that the wording of the definitions could be clarified.  Justin, do you want to take a first pass at this or would you like to take lead on this, Phil?
>
>> Section 2:
>>
>> Why isn't a more secure option offered and set as the default for authentication types? I know I've asked this before and the answer was just that you can add something to the registry, but setting HTTP Basic as the default seems like a really bad choice. HOBA is on it's way to becoming an RFC from the HTTPAuth working group.  HTTPAuth also has an updated version of Basic that is in IETF last call, but I know you are pointing to the OAuth 2.0 document, so it would be that document that gets updated and not this draft.  The new version of HTTP Basic fixes some internationalization problems and spells out the security issues much more clearly, so it probably doesn't matter too much to update the reference, but maybe makes it more clear that basic is not a secure form of authentication.
>>
>> Can you provide some justification as to why this is okay to set basic as the default and add that to the draft?  Section 2.3.1 of OAuth 2.0 just says this MUST be implemented, but that any HTTP schemes can be used.  Why not register another method and use that instead as the default?  You could use digest and there is library support.  It's not a great answer, but slightly better than passwords with basic.  You could register HOBA and use that instead, the only downside is limited library support at the moment.
>>
>> It was our intent to document the methods already defined for use with OAuth and provide a registration mechanism for distinguishing between them, not to create new client authentication mechanisms. Digest and HOBA simply aren't defined for use with OAuth clients yet. It would be simple to do: put the client id in the "username" field and the client secret in the "password" field of both algorithms. However, I don't believe it's a good idea to conflate those two goals in a single specification. We actually had other, more secure definitions in an earlier draft of this document (using a JWT signed with a private key or a JWT signed with a shared key, specifically), but those were removed in order to focus on solving just the client registration problem. I agree with that decision of the WG.
>>
>> As other methods of client authentication are defined in the OAuth ecosystem, they can register as valid values in the registry. I think it would be a valuable output of this WG to define other client authentication mechanisms as a separate draft or an eventual update to RFC6749 (or both?).
> HTTP Basic is set to the default because that's the default in RFC 6749 and this specification is about registering clients for use with RFC 6749.  Trying to change the RFC 6749 default really isn't within the scope of this work.  (If that's done, it should probably be done in an http6749-bis spec.)  However, the spec does define a registry that new methods like HOBA can be registered in when people want to use them.  (And if HOBA finishes before Dynamic Registration, I'm fine adding a registry entry for it in this spec.)
>
> If you're interested in the client_secret_jwt and private_key_jwt client authentication methods that Justin alluded to, these are defined in Section 9 of OpenID Connect Core http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication.
>
> In relation to your internationalization comments Kathleen, note that Section 2.3.1 of RFC 6749 explicitly provides a mechanism for encoding international strings for use with HTTP Basic.  This was added under the supervision of Julian Reschke, I believe as a result of his WGLC comments.  So whether this is the same as what the new version of HTTP Basic does or not, OAuth 2.0 already does provide a standard way to use internationalized strings with HTTP Basic for OAuth client authentication.
>
>> Section 2: Contacts:
>>
>> I noticed privacy is not dealt with until you get to the security considerations section.  I'd prefer to see it with the definition, stating the address should be a general help address at the domain rather than directly to an identifiable individual.  It may be good to set a default for what this should be for consistency or give an example (think back to abuse@domain.com)?
>>
>> The problem that I see with putting it inside the definition is that it makes the definition text very long, as the definition sits in a list of other metadata items. We could add a forward pointer and an example easily enough, though. Or we could move the privacy considerations section up as a subsection here, though I don't know if that runs afoul of the RFC style guidelines for this new section.
>>
>>
>>
>> Software_id and software_version:
>> Are there any guidelines as to how these should be represented?  There are several specifications on software_id (and platform).  Does consistency here matter or is this just meant to be human readable?
>> Section 2.2 specifies some metadata values that are to be human readable, should the above be in the list?  I would expect this list to be comprehensive for clarity, rather than just examples since there aren't too many defined here.
>>
>>
>> [mostly deferred to Phil et. al, but note that software_id and software_version are not intended to be human readable and don't need the multi-language support]
> We should probably say that in the draft then.
>
>> [Phil]
>> I've added some more explanatory text. Note...some of this may be better put elsewhere.
>>
>> As to whether the values are human readable, I have no opinion. What matters most is unique matching.
>>
>>     software_id
>>        A unique identifier (e.g. UUID) assigned by the developer or software publisher
>>        used by registration endpoints to identify client software to be dynamically registered.
>>        Unlike "client_id", which is issued by the authorization server and varies between
>>        instances of software, the "software_id" SHOULD remain the same for all client software
>>        instances. The "software_id" SHOULD remain the same across multiple software updates
>>        or versions.
> I'd revise the last two sentences of this as follows:
>
>        Unlike "client_id", which is issued by the authorization server and may vary between
>        instances of a piece of software, the "software_id" SHOULD remain the same for all instances
>        of a piece of software. The "software_id" SHOULD remain the same across multiple software updates
>        or versions of the same piece of software.
>
>> software_version
>>        A version identifier for the software identified by "software_id".  The
>>        value of this field is a string that is intended to be compared
>>        using string equality matching. Unlike "software_id", the value of the
>>        "software_version" SHOULD change on any update to the client
>>        software. A service provider MAY use "software_id" and "software_version" to
>>        recognize approved software and version combinations approved for dynamic registration.
>>
>> Let me know if you want more background.
>>
>>
>> Section 3.2.1 & Privacy section
>> For client_name and client_id and associated information, how is user privacy affected and what can be done to mitigate concerns?  The definition should state that this is a public value and that it is specific to the software, not a person.  You have to get to the security consideration section before that is clear.  References are fine too, but some more information is needed in the privacy section.  I'm left with a bunch of questions:
>>    Can the client_name and client_id be tied to a person?
>> The client name is common across all copies of the software (usually), so no worries there. The ID represents an individual piece of software, not a person, though if that person is the sole user of the instance of software then I believe you're right that there are some privacy considerations that we should point that out. However, dynamic registration can actually help mitigate this as well, since in the normal case (with no software statements) there's no way to correlate instances of clients with each other.
>>
>>    Can the person be tracked by this?
>>    Can other information be gathered about a system (and it's user) during this process?
>> Nothing gathered about the user during registration, as this happens in the back channel outside the user's purview.
>>
>>    The information is used to dynamically register clients, what is logged?
>>    What data is aggregated?
>>    What can you tell about a client (time, location, travel, other personal details that may be considered sensitive)?  I don't think this was covered in the OAuth 2.0 RFC.
>>    How is this addressed at the authorization server and other points?
>>    The Security considerations talks about client_id as being short lived, so they expire, but are these event logged or is that prohibited?
>>
>> Many of these questions seem to be completely dependent on the implementation of the authorization server, and I'm not really sure how (or if) to address them in this draft. Any suggestions would be welcomed here.
>>
>> The client_id *could* be short lived, but they usually aren't. I don't see any particular logging or tracking concerns using a dynamic OAuth client above using any other piece of software, ever. As such, I don't think it requires special calling out here.
>>
>>
>>
>> 5. Security considerations
>> The first paragraph is a repeat of text.  Can this just be in one place and use a pointer to the full text?  I like the requirement, but reading it once is enough.
>>
>> I think it was less onerous of a repeat when both simply said "use TLS", so some refactoring after the expansion of the text makes sense to me. Would it be better to have it upfront in the endpoint definition, or in the security considerations?
> Justin, do you want to make specific rewording proposals for this and the other editorial issues that were identified?
>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> Thanks again for your review!
>>
>>   -- Justin
> 				Thanks all,
> 				-- Mike
>


From nobody Tue Feb 17 08:50:21 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C5C1A88E4 for ; Tue, 17 Feb 2015 08:50:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8RVujW2dKQ5 for ; Tue, 17 Feb 2015 08:50:18 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A6F1A88DC for ; Tue, 17 Feb 2015 08:50:17 -0800 (PST)
Received: from [192.168.131.128] ([80.92.119.127]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LeSOH-1XnHx53zen-00qAfB; Tue, 17 Feb 2015 17:50:15 +0100
Message-ID: <54E370F9.8060209@gmx.net>
Date: Tue, 17 Feb 2015 17:48:57 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Torsten Lodderstedt ,  Brian Campbell 
References: <54C7BBA4.4030702@gmx.net>  <2E3D2EE7-8F5F-452D-880A-D62A513AC853@lodderstedt.net>
In-Reply-To: <2E3D2EE7-8F5F-452D-880A-D62A513AC853@lodderstedt.net>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GwxTF61nIlvVpBhixjk7KHxmXjCjmF6V4"
X-Provags-ID: V03:K0:yO5V6uU2221HqIVm4V6b3YmCW2itC9Ue1h74ecrDRoxWYTlKAc3 saZoonE6Fvryk6tCxcavJkY7sZKpoQvSuTKZxGbY5glXqmVmosQIY6vO0G3X0M8h/TvSpWi MHCgB5ciI2Z5liydmsc6AFX++EP/SGHbS+lKCOowH4c5VgsfKkkxD3lh5roYXfDYNJ1Az9n tSako/DOzYW1vRliYr4mg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "oauth@ietf.org" , "naa@google.com >> Naveen Agarwal" 
Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Feb 2015 16:50:20 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--GwxTF61nIlvVpBhixjk7KHxmXjCjmF6V4
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Torsten,

does this mean that your implementation is not compliant with the
current version anymore or that you haven't had time to verify whether
there are differences to the earlier version?

Ciao
Hannes


On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
> Deutsche Telekom also implemented an early version of the draft last ye=
ar.
>=20
>=20
>=20
> Am 30.01.2015 um 18:50 schrieb Brian Campbell
> >:
>=20
>>
>> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
>> > wrote:
>>
>>
>>     1) What implementations of the spec are you aware of?
>>
>>
>> We have an AS side implementation of an earlier draft that was
>> released in June of last year:
>> http://documentation.pingidentity.com/pages/viewpage.action?pageId=3D2=
6706844
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth


--GwxTF61nIlvVpBhixjk7KHxmXjCjmF6V4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJU43D5AAoJEGhJURNOOiAt/2sH/j9Wfv5JV7Vkvfj+oGMyVHI9
Mvl5Sb6/bBWavW76y6YN1U8MYY5hX74R0LqPGORT90r4VY9lJZHnYR3VB1bF4zFe
eYz+NM7LCqWBPfZFEA7FZsHBW4WXZu2Jyvdcq4ugJ+ap0XFoifFX5ioFxbVl6B1Q
l14aLls3+TNbhRC5qOyYf0R6bs4b/AOP+RLhTnmpT8n9dC4NWjpDNXktQAb+JIbD
s6t89cP8qkweIXqc2ONbiDEbOwAFtZ7OK8sFeVysSLTXJtagKC5HQyTyFeMOc1w3
F3r1tDOWfZN5KT2WauPatoi249J1NAw/hzixNwSL6y0DA4Ybo84CV87kTaltpwk=
=2n21
-----END PGP SIGNATURE-----

--GwxTF61nIlvVpBhixjk7KHxmXjCjmF6V4--


From nobody Tue Feb 17 08:51:35 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F74E1A88A8 for ; Tue, 17 Feb 2015 08:51:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QHmeqF4aSyW for ; Tue, 17 Feb 2015 08:51:23 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE03F1A88E0 for ; Tue, 17 Feb 2015 08:51:13 -0800 (PST)
Received: from [192.168.131.128] ([80.92.119.127]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MZU7V-1Y98Dr2az7-00LGFX; Tue, 17 Feb 2015 17:51:11 +0100
Message-ID: <54E37133.4090401@gmx.net>
Date: Tue, 17 Feb 2015 17:49:55 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Brian Campbell 
References: <54C7BBA4.4030702@gmx.net> 
In-Reply-To: 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2nbKi8xMJuxFCJbf4M6nUaWk0LuebXhU3"
X-Provags-ID: V03:K0:3IjsWvd3Dv9C9YrYPXJPVj9N7tI0DsGw6w1CxPZPMgTBSEHN1a0 5uz+UCddAz8dGY5f5m+AjnrcG6CqsSwLQsJTKfRPeVuLfJVFoyD+V3FCdq8DdFIKwizqbDM nrCWWkLvfPiJXlBmrsbvJxRcHY4IPZw2mCUy9i7huAZARaRAwbGQQz48xOQAYYvMdO7HOid Z/7xweBjZ127dvUOXjKOw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "oauth@ietf.org" , "naa@google.com >> Naveen Agarwal" 
Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Feb 2015 16:51:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2nbKi8xMJuxFCJbf4M6nUaWk0LuebXhU3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Brian,

what is different between the version you guys implemented and the
version that is currently documented in the latest version of the draft?

Ciao
Hannes


On 01/30/2015 06:50 PM, Brian Campbell wrote:
>=20
> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
> > wrote:
>=20
>=20
>     1) What implementations of the spec are you aware of?
>=20
>=20
> We have an AS side implementation of an earlier draft that was released=

> in June of last year:
> http://documentation.pingidentity.com/pages/viewpage.action?pageId=3D26=
706844


--2nbKi8xMJuxFCJbf4M6nUaWk0LuebXhU3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJU43EzAAoJEGhJURNOOiAt1KwH/jkDvlHW1JTBycQ88UvOEAT8
mcBdhem73fi3YXCKAiLxwkb1ATg1jzJaKQno/TZClY7PyRGkGKbwKOOQA1V+FtO4
lfLUlx2qnQzv+l13rP74scQALEiLkhdYq3vSEbhhGI3BJgjAQOSnSxI82wZ/vyrd
e5rf44j7fbA7A1t/AtGdgcOIECdsImVLDWVCZ7aZpa+rqcvBnEcpPKULgxVPZWZT
2TgtFxd2rbs7pCWzVv7Sl0zunr3KjdY1qB7mYl8jBnttKPqANjFV1f5+uIEm7jXO
1cCW6yzPt7yy+CEIqU1xievDuYjqOFzjcv044URHjE3bz2mvNgbRG6P+Z9bslS4=
=Kmy8
-----END PGP SIGNATURE-----

--2nbKi8xMJuxFCJbf4M6nUaWk0LuebXhU3--


From nobody Tue Feb 17 08:58:06 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F081A1BCC for ; Tue, 17 Feb 2015 08:58:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbodFHomK2No for ; Tue, 17 Feb 2015 08:58:02 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363FA1A1B85 for ; Tue, 17 Feb 2015 08:58:02 -0800 (PST)
Received: from [192.168.131.128] ([80.92.119.127]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MKZLb-1YO2aJ2kI3-0023Lm; Tue, 17 Feb 2015 17:57:56 +0100
Message-ID: <54E372C1.8040204@gmx.net>
Date: Tue, 17 Feb 2015 17:56:33 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: ve7jtb@ve7jtb.com, naa@google.com,  "n-sakimura@nri.co.jp >> Nat Sakimura" 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="m4PnsvKW2sWTU16K58s7P3b0tpSRUL8Dc"
X-Provags-ID: V03:K0:QLeWlWKcKXxwE0O+I7gmGOM0BRpahBh5tqPX6zN2Ldo+86nptDe Gn/BWaleD5/bS9wvRL7U8Hn8yPm5fNB1j2Rl+6O8GtKQcWlQlc/JezQ646ubDYaSHEBXYkU AUyq3Py7GiSWqnw9UgxnnFMMg6Vr7OwvH418ldHYH4CsSVvY5jfr5/CO9j8ga7cTzpRXGxl VA7WPj0n44TTmOxYgT/Mg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Feb 2015 16:58:04 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--m4PnsvKW2sWTU16K58s7P3b0tpSRUL8Dc
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Nat, John, Naveen,

thanks a lot for your work on the document.

I still need responses to this mail to complete the shepherd writeup:
http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html

I definitely need the IPR confirmation.

It would also be helpful to have someone who implemented the
specification as it currently is. I asked Brian and Thorsten for
clarification regarding their statements that they implemented earlier
versions of the spec.

As a final remark I still believe that the text regarding the randomness
is still a bit inconsistent. Here are two examples:

1) In the Security Consideration you write that "The security model
relies on the fact that the code verifier is not learned or guessed by
the attacker.  It is vitally important to adhere to this principle. "

2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD have
enough entropy to make it impractical to guess the value.  It is
RECOMMENDED that the output of a suitable random number generator be
used to create a 32-octet sequence."

There is clearly a long way from a SHOULD have enough entropy to the
text in the security consideration section where you ask for 32 bytes
entropy.

It is also not clear why you ask for 32 bytes of entropy in particular.

Ciao
Hannes


--m4PnsvKW2sWTU16K58s7P3b0tpSRUL8Dc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJU43LBAAoJEGhJURNOOiAtJDsH/1YCerx5oYh1mSXxKh+GhwnY
VPMXz4bILXn1RE1CMCtBZ+2iuzmnGfZLlv+L/TvAfhpUbmZDAR6oJoaUhx9TTJHB
Pj9KGVsu4nd1kY5jdtaYV1jYp83k7Oj/HDRSkDBlgpe/0Mzeqt4T4yWgveNvfWr3
Rs9XZYNsrW5gX71NduRdd5E+HNL4ODtfJveNg9+vQk4bTSs8iT4vMR9Jbphp1l2B
/5CBpyQQI6z6Dqlg0+6mPZxAXGrBdYvE2CNT/hQuDOps/wmqxHSVECr1fMuyLjMh
27Nd+M0Irg7yOWmKZJNzGbV/ew0BQ+4+ILCT8V7XckZM9TAURXjiCzeamY7wGoQ=
=1GXK
-----END PGP SIGNATURE-----

--m4PnsvKW2sWTU16K58s7P3b0tpSRUL8Dc--


From nobody Tue Feb 17 14:17:34 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A551A88C9 for ; Tue, 17 Feb 2015 14:17:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level: 
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6NXh1COJls1 for ; Tue, 17 Feb 2015 14:17:32 -0800 (PST)
Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115C11A88BC for ; Tue, 17 Feb 2015 14:17:31 -0800 (PST)
Received: from mail-qa0-f51.google.com ([209.85.216.51]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKVOO9+7kfRc+eNhePxO5n4XvmSr0fXORt@postini.com; Tue, 17 Feb 2015 14:17:32 PST
Received: by mail-qa0-f51.google.com with SMTP id i13so28340944qae.10 for ; Tue, 17 Feb 2015 14:17:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VBCJTpAalbUc2XaZXLKhtak5Qf6rhOQ6ZkmbKIDHYdU=; b=D05e0aotW689kq+KZ6HfOf68KqwMUzQ61FRO/BGtCPQ1GVjfPUkuQE9Wc1cOz2nByj x2aileM8BMZLRCvAjpuTnq0EleYkY5xyipKWVsU5oHvSmqu7PrQVOpPkH/YPr3unAw4d 3lkfQAXVwaTK0UIpqZSpKb7HW9iWKWR9OQ5d15Fi5LBaAHODnOczVSM2AUdS3kgn5lI0 98XkUDkkkGyVknPBqeHgO8BlnH4Fpp7iHxaAfTwmbcg8S5OrVE81UK7Aa+SVAzRdJEzM 96j3xQjO/iiccGeUsrXu3ngfVY5Ig7NicS1wkH3EzzAk9hNJ5TLrEOobOi/ETkpfN4rn zZ9Q==
X-Gm-Message-State: ALoCoQmCsuW1xdJi9bKXC8ulhsnHn+r947ThXHHm2ecVwWh1LEv79K6IDO1IYLdKvdwrphOGLSLkEP02Phagvfd4+qIwmsp7OkbFf+7m+Ha+uIRE16hkBGKyaKbU3qmtRqlOy52LHrjg
X-Received: by 10.140.237.6 with SMTP id i6mr396317qhc.32.1424211451081; Tue, 17 Feb 2015 14:17:31 -0800 (PST)
X-Received: by 10.140.237.6 with SMTP id i6mr396301qhc.32.1424211450990; Tue, 17 Feb 2015 14:17:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.95.45 with HTTP; Tue, 17 Feb 2015 14:17:00 -0800 (PST)
In-Reply-To: <54E37133.4090401@gmx.net>
References: <54C7BBA4.4030702@gmx.net>  <54E37133.4090401@gmx.net>
From: Brian Campbell 
Date: Tue, 17 Feb 2015 15:17:00 -0700
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a11359c709f2655050f501199
Archived-At: 
Cc: "oauth@ietf.org" , "naa@google.com >> Naveen Agarwal" 
Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Feb 2015 22:17:34 -0000

--001a11359c709f2655050f501199
Content-Type: text/plain; charset=UTF-8

When we did the implementation there was no S256 transformation defined or
made MTI for the server. I'm pretty sure it was http://tools.ietf.org/html/
draft-sakimura-oauth-tcse-03

Thus, our server supports only the "no transformation" (as it was called
then) or the "plain" code_challenge_method (as it's called now).

It is compatible with the latest version of the draft for a client using
the "plain" code_challenge_method (thank you to everyone for maintaining
that). But wouldn't work for the "S256" code_challenge_method as it didn't
exist at the time we implemented.

On Tue, Feb 17, 2015 at 9:49 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi Brian,
>
> what is different between the version you guys implemented and the
> version that is currently documented in the latest version of the draft?
>
> Ciao
> Hannes
>
>
> On 01/30/2015 06:50 PM, Brian Campbell wrote:
> >
> > On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
> > > wrote:
> >
> >
> >     1) What implementations of the spec are you aware of?
> >
> >
> > We have an AS side implementation of an earlier draft that was released
> > in June of last year:
> >
> http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844
>
>

--001a11359c709f2655050f501199
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


When we did the implementation there was no S256=
 transformation defined or made MTI for the server. I'm pretty sure it =
was http://tools.ietf.org/html/draft-sakimura-oauth<=
/span>-tcse-03 

Thus, our server s=
upports only the "no transformation" (as it was called then) or t=
he "plain" code_challenge_method (as it's called now).
It is compatible with the latest version of the draft for a client u=
sing the "plain" code_challenge_method (thank you to everyone for=
 maintaining that). But wouldn't work for the "S256" code_cha=
llenge_method as it didn't exist at the time we implemented. 
=


On Tue, Feb 17, 2=
015 at 9:49 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net&g=
t; wrote:
Hi Brian,



what is different between the version you guys implemented and the

version that is currently documented in the latest version of the draft?


Ciao

Hannes





On 01/30/2015 06:50 PM, Brian Campbell wrote:

>

> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig


> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>>=
 wrote:

>

>

>=C2=A0 =C2=A0 =C2=A01) What implementations of the spec are you aware o=
f?

>

>

> We have an AS side implementation of an earlier draft that was release=
d

> in June of last year:

> http://documentation.pingidentity.com=
/pages/viewpage.action?pageId=3D26706844







--001a11359c709f2655050f501199--


From nobody Tue Feb 17 16:03:14 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E954F1A88D8 for ; Tue, 17 Feb 2015 16:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1XrExmHnDd5 for ; Tue, 17 Feb 2015 16:03:09 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206921A88D7 for ; Tue, 17 Feb 2015 16:03:09 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1I037bu017741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Feb 2015 00:03:08 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1I0368v024165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Feb 2015 00:03:07 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1I036ul002598; Wed, 18 Feb 2015 00:03:06 GMT
Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 17 Feb 2015 16:03:05 -0800
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Phil Hunt 
In-Reply-To: <54E28EB1.7020504@mit.edu>
Date: Tue, 17 Feb 2015 16:03:04 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com> <54E28EB1.7020504@mit.edu>
To: Justin Richer 
X-Mailer: Apple Mail (2.2070.6)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 00:03:13 -0000

I=92m not sure if this is what Kathleen is after. I think part of the =
background in the current spec is that we were trying to differentiate =
from the large scale success stories OAuth has had in the past like =
Facebook and Google.  When you are a developer trying to build a client =
for IMAP, a standards based protocol, you can=92t predict what the =
endpoints are in advance, so obviously an IMAP developer can=92t obtain =
client_ids since they can=92t predict the future. Nor would it be =
reasonable to pre-register with every possible email deployment in the =
world.

NOTE:   We might want to change the terminology from =93API=94 to =
application service or application protocol.  I know some an IETF see =
the word API and associate that exclusively with programming libraries.

deployment organization
      An administrative security domain under which a software API =
(service) is
      deployed and protected by an OAuth 2.0 framework. In early OAuth
      scenarios, the deploying organization was often the same =
organization=20
      that published the API. In these cases the deploying organization =
can have=20
     a close relationship with client software developers.  In many =
other cases,
     the definer of the service may be an independent third-party =
publisher or
     a standards organization. The client software developer while =
working to
     a published specification for an API is unable to have a prior =
relationship=20
     with the organization deploying the software API (service).

software api publisher
      The organization that defines a particular web accessible API that
      may be deployed in one or more deployment environments.  A =
publisher
      may be any standards body, commercial, public, private, or open =
source
      organization that is responsible for publishing and distributing
      software that may be protected via OAuth 2.0.  In some cases a
      software API publisher and a client developer may be the same
      organization. At the time of publication of a web accessible API, =
the software
     publisher often does not have a prior relationship with deploying =
organizations.

 Client Developer
      The person or organization that builds a client software package
      and prepares it for distribution. At the time of building the =
client, the developer
      is often not aware of who the deploying service provider =
organizations will be.=20
      Except when the software API publisher and the deploying =
organization are=20
      the same, client developers will need to use dynamic registration =
when they are
      unable to predict the deployment URLs at =93compile time=94.

Phil

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

> On Feb 16, 2015, at 4:43 PM, Justin Richer  wrote:
>=20
> To Mike's last question below: I'd like Phil (and others if desired) =
to propose a clarified version of the "deployment organization", =
"software api publisher", and "client developer" if possible. With some =
text for that in hand I can tackle the rest given the feedback below.
>=20
> -- Justin
>=20
> On 2/16/2015 6:42 PM, Mike Jones wrote:
>> A few responses and comments are inline below...
>>=20
>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
>>> Sent: Thursday, February 12, 2015 11:47 AM
>>> To: Justin Richer
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>>>=20
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>> On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
>>>=20
>>> Kathleen, thanks for the review. Responses inline, though I'm going =
to let the other authors talk about their sections (deployment org, =
software version, etc) directly.
>>>=20
>>> On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
>>> Thank you for your work on this draft and sorry for the delay in my =
review.  Before we progress to IETF last call, I'd like to see what we =
can resolve from the list below.   I am looking at the IPR issues to see =
if we can resolve the outstanding questions as well.
>>>=20
>>> The Shepherd report says the following:
>>>    The document shepherd has raised concerns regarding the fuzzy =
description
>>>    of the actors (deployment organization, software API publisher, =
client
>>>    developer) and their impact on the protocol execution. The =
working
>>>    group did not seem to worry about these aspects though.
>>>=20
>>> I can see the point after reading the draft.  The interactions are =
written much more clearly in the security considerations section than =
where the flows are described.  Can something be done to address these =
concerns?
>>>=20
>>> Section 1.2
>>> Deployment Organization definition:
>>> I highly recommend replacing the phrase "simple cloud deployment" =
with a description that accurately reflects what is intended.  If that's =
within a single service provider's network, a single data center, or a =
single hosted data center, I think it would be more clear.
>>>=20
>>> Section 1.2 nit:
>>> Add the word "be" into the following term definition after "may":
>>>   Software API Publisher
>>>       The organization that defines a particular web accessible API =
that
>>>       may deployed in one or more deployment environments.
>>>=20
>>> [deferred to original author of this text Phil et. al for better =
wording]
>>>=20
>>> [Phil] Agreed with Kathleen's suggestion.
>> I also agree that the wording of the definitions could be clarified.  =
Justin, do you want to take a first pass at this or would you like to =
take lead on this, Phil?
>>=20
>>> Section 2:
>>>=20
>>> Why isn't a more secure option offered and set as the default for =
authentication types? I know I've asked this before and the answer was =
just that you can add something to the registry, but setting HTTP Basic =
as the default seems like a really bad choice. HOBA is on it's way to =
becoming an RFC from the HTTPAuth working group.  HTTPAuth also has an =
updated version of Basic that is in IETF last call, but I know you are =
pointing to the OAuth 2.0 document, so it would be that document that =
gets updated and not this draft.  The new version of HTTP Basic fixes =
some internationalization problems and spells out the security issues =
much more clearly, so it probably doesn't matter too much to update the =
reference, but maybe makes it more clear that basic is not a secure form =
of authentication.
>>>=20
>>> Can you provide some justification as to why this is okay to set =
basic as the default and add that to the draft?  Section 2.3.1 of OAuth =
2.0 just says this MUST be implemented, but that any HTTP schemes can be =
used.  Why not register another method and use that instead as the =
default?  You could use digest and there is library support.  It's not a =
great answer, but slightly better than passwords with basic.  You could =
register HOBA and use that instead, the only downside is limited library =
support at the moment.
>>>=20
>>> It was our intent to document the methods already defined for use =
with OAuth and provide a registration mechanism for distinguishing =
between them, not to create new client authentication mechanisms. Digest =
and HOBA simply aren't defined for use with OAuth clients yet. It would =
be simple to do: put the client id in the "username" field and the =
client secret in the "password" field of both algorithms. However, I =
don't believe it's a good idea to conflate those two goals in a single =
specification. We actually had other, more secure definitions in an =
earlier draft of this document (using a JWT signed with a private key or =
a JWT signed with a shared key, specifically), but those were removed in =
order to focus on solving just the client registration problem. I agree =
with that decision of the WG.
>>>=20
>>> As other methods of client authentication are defined in the OAuth =
ecosystem, they can register as valid values in the registry. I think it =
would be a valuable output of this WG to define other client =
authentication mechanisms as a separate draft or an eventual update to =
RFC6749 (or both?).
>> HTTP Basic is set to the default because that's the default in RFC =
6749 and this specification is about registering clients for use with =
RFC 6749.  Trying to change the RFC 6749 default really isn't within the =
scope of this work.  (If that's done, it should probably be done in an =
http6749-bis spec.)  However, the spec does define a registry that new =
methods like HOBA can be registered in when people want to use them.  =
(And if HOBA finishes before Dynamic Registration, I'm fine adding a =
registry entry for it in this spec.)
>>=20
>> If you're interested in the client_secret_jwt and private_key_jwt =
client authentication methods that Justin alluded to, these are defined =
in Section 9 of OpenID Connect Core =
http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication.=

>>=20
>> In relation to your internationalization comments Kathleen, note that =
Section 2.3.1 of RFC 6749 explicitly provides a mechanism for encoding =
international strings for use with HTTP Basic.  This was added under the =
supervision of Julian Reschke, I believe as a result of his WGLC =
comments.  So whether this is the same as what the new version of HTTP =
Basic does or not, OAuth 2.0 already does provide a standard way to use =
internationalized strings with HTTP Basic for OAuth client =
authentication.
>>=20
>>> Section 2: Contacts:
>>>=20
>>> I noticed privacy is not dealt with until you get to the security =
considerations section.  I'd prefer to see it with the definition, =
stating the address should be a general help address at the domain =
rather than directly to an identifiable individual.  It may be good to =
set a default for what this should be for consistency or give an example =
(think back to abuse@domain.com)?
>>>=20
>>> The problem that I see with putting it inside the definition is that =
it makes the definition text very long, as the definition sits in a list =
of other metadata items. We could add a forward pointer and an example =
easily enough, though. Or we could move the privacy considerations =
section up as a subsection here, though I don't know if that runs afoul =
of the RFC style guidelines for this new section.
>>>=20
>>>=20
>>>=20
>>> Software_id and software_version:
>>> Are there any guidelines as to how these should be represented?  =
There are several specifications on software_id (and platform).  Does =
consistency here matter or is this just meant to be human readable?
>>> Section 2.2 specifies some metadata values that are to be human =
readable, should the above be in the list?  I would expect this list to =
be comprehensive for clarity, rather than just examples since there =
aren't too many defined here.
>>>=20
>>>=20
>>> [mostly deferred to Phil et. al, but note that software_id and =
software_version are not intended to be human readable and don't need =
the multi-language support]
>> We should probably say that in the draft then.
>>=20
>>> [Phil]
>>> I've added some more explanatory text. Note...some of this may be =
better put elsewhere.
>>>=20
>>> As to whether the values are human readable, I have no opinion. What =
matters most is unique matching.
>>>=20
>>>    software_id
>>>       A unique identifier (e.g. UUID) assigned by the developer or =
software publisher
>>>       used by registration endpoints to identify client software to =
be dynamically registered.
>>>       Unlike "client_id", which is issued by the authorization =
server and varies between
>>>       instances of software, the "software_id" SHOULD remain the =
same for all client software
>>>       instances. The "software_id" SHOULD remain the same across =
multiple software updates
>>>       or versions.
>> I'd revise the last two sentences of this as follows:
>>=20
>>       Unlike "client_id", which is issued by the authorization server =
and may vary between
>>       instances of a piece of software, the "software_id" SHOULD =
remain the same for all instances
>>       of a piece of software. The "software_id" SHOULD remain the =
same across multiple software updates
>>       or versions of the same piece of software.
>>=20
>>> software_version
>>>       A version identifier for the software identified by =
"software_id".  The
>>>       value of this field is a string that is intended to be =
compared
>>>       using string equality matching. Unlike "software_id", the =
value of the
>>>       "software_version" SHOULD change on any update to the client
>>>       software. A service provider MAY use "software_id" and =
"software_version" to
>>>       recognize approved software and version combinations approved =
for dynamic registration.
>>>=20
>>> Let me know if you want more background.
>>>=20
>>>=20
>>> Section 3.2.1 & Privacy section
>>> For client_name and client_id and associated information, how is =
user privacy affected and what can be done to mitigate concerns?  The =
definition should state that this is a public value and that it is =
specific to the software, not a person.  You have to get to the security =
consideration section before that is clear.  References are fine too, =
but some more information is needed in the privacy section.  I'm left =
with a bunch of questions:
>>>   Can the client_name and client_id be tied to a person?
>>> The client name is common across all copies of the software =
(usually), so no worries there. The ID represents an individual piece of =
software, not a person, though if that person is the sole user of the =
instance of software then I believe you're right that there are some =
privacy considerations that we should point that out. However, dynamic =
registration can actually help mitigate this as well, since in the =
normal case (with no software statements) there's no way to correlate =
instances of clients with each other.
>>>=20
>>>   Can the person be tracked by this?
>>>   Can other information be gathered about a system (and it's user) =
during this process?
>>> Nothing gathered about the user during registration, as this happens =
in the back channel outside the user's purview.
>>>=20
>>>   The information is used to dynamically register clients, what is =
logged?
>>>   What data is aggregated?
>>>   What can you tell about a client (time, location, travel, other =
personal details that may be considered sensitive)?  I don't think this =
was covered in the OAuth 2.0 RFC.
>>>   How is this addressed at the authorization server and other =
points?
>>>   The Security considerations talks about client_id as being short =
lived, so they expire, but are these event logged or is that prohibited?
>>>=20
>>> Many of these questions seem to be completely dependent on the =
implementation of the authorization server, and I'm not really sure how =
(or if) to address them in this draft. Any suggestions would be welcomed =
here.
>>>=20
>>> The client_id *could* be short lived, but they usually aren't. I =
don't see any particular logging or tracking concerns using a dynamic =
OAuth client above using any other piece of software, ever. As such, I =
don't think it requires special calling out here.
>>>=20
>>>=20
>>>=20
>>> 5. Security considerations
>>> The first paragraph is a repeat of text.  Can this just be in one =
place and use a pointer to the full text?  I like the requirement, but =
reading it once is enough.
>>>=20
>>> I think it was less onerous of a repeat when both simply said "use =
TLS", so some refactoring after the expansion of the text makes sense to =
me. Would it be better to have it upfront in the endpoint definition, or =
in the security considerations?
>> Justin, do you want to make specific rewording proposals for this and =
the other editorial issues that were identified?
>>=20
>>> --
>>>=20
>>> Best regards,
>>> Kathleen
>>>=20
>>> Thanks again for your review!
>>>=20
>>>  -- Justin
>> 				Thanks all,
>> 				-- Mike
>>=20
>=20


From nobody Tue Feb 17 20:14:18 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF861A8982 for ; Tue, 17 Feb 2015 20:14:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.607
X-Spam-Level: ****
X-Spam-Status: No, score=4.607 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1.999, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRbuW5RdSwWD for ; Tue, 17 Feb 2015 20:14:14 -0800 (PST)
Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33E91A0163 for ; Tue, 17 Feb 2015 20:14:14 -0800 (PST)
Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs02.index.or.jp (Postfix) with SMTP id CA814196871; Wed, 18 Feb 2015 13:14:13 +0900 (JST)
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea03.index.or.jp (unknown) with ESMTP id t1I4EDGI014666; Wed, 18 Feb 2015 13:14:13 +0900
Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.3/Switch-3.3.3) with ESMTP id t1I4ED6q023994; Wed, 18 Feb 2015 13:14:13 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.3/Switch-3.3.0/Submit) id t1I4ED9g023993; Wed, 18 Feb 2015 13:14:13 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf21a.index.or.jp ([172.100.25.19]) by nrims00a.nri.co.jp (Switch-3.3.3/Switch-3.3.3) with ESMTP id t1I4EDGP023988; Wed, 18 Feb 2015 13:14:13 +0900
Received: from 127.0.0.1 (127.0.0.1) by m-FILTER with ESMTP; Wed, 18 Feb 2015 13:14:13 +0900
Date: Wed, 18 Feb 2015 13:13:59 +0900
From: Nat Sakimura 
To: Hannes Tschofenig 
Message-Id: <20150218131359.19dae026d3e459813e21dc55@nri.co.jp>
In-Reply-To: <54E372C1.8040204@gmx.net>
References: <54E372C1.8040204@gmx.net>
X-Mailer: Sylpheed 3.4.2 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-MailAdviser: 20141126
Archived-At: 
Cc: "oauth@ietf.org" , naa@google.com
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 04:14:17 -0000

Hi Hannes, 

I hereby confirm that I have submit the draft  in full conformance with the  provisions of BCP 78 and BCP 79.

Re: Security Consideration (7.1) and section 4.1

The first part of the 7.1 is a non-normative prose explaining that the implementers got to make sure that the code verifier is hard to guessed or modeled. In a way, this is laying out the basic security property requirment on the code verifier. 

Then, it goes onto the implementation guideance that one need to use a cryptographic random number generator instead of relying on a rand() in some language that are  not cryptographically random to generate 32-octet sequence. The same text is in 4.1 as well. 

We did not copy "code verifier SHOULD have enough entropy to make it impractical to guess the value" here because that looked needlessly repeating, but if you want, I have no objection in adding it to 7.1. 

Alternatively, in 7.1, after explaining the rationale, we can just point to 4.1 for the control and implementation guidance. 

Re: 32-octet

We chose it because we are using SHA256 in generating the code challange.
Having more entropy does not help us here, while having less octets increases the risk. 

Best, 

Nat 



On Tue, 17 Feb 2015 17:56:33 +0100
Hannes Tschofenig  wrote:

> Hi Nat, John, Naveen,
> 
> thanks a lot for your work on the document.
> 
> I still need responses to this mail to complete the shepherd writeup:
> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> 
> I definitely need the IPR confirmation.
> 
> It would also be helpful to have someone who implemented the
> specification as it currently is. I asked Brian and Thorsten for
> clarification regarding their statements that they implemented earlier
> versions of the spec.
> 
> As a final remark I still believe that the text regarding the
> randomness is still a bit inconsistent. Here are two examples:
> 
> 1) In the Security Consideration you write that "The security model
> relies on the fact that the code verifier is not learned or guessed by
> the attacker.  It is vitally important to adhere to this principle. "
> 
> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
> have enough entropy to make it impractical to guess the value.  It is
> RECOMMENDED that the output of a suitable random number generator be
> used to create a 32-octet sequence."
> 
> There is clearly a long way from a SHOULD have enough entropy to the
> text in the security consideration section where you ask for 32 bytes
> entropy.
> 
> It is also not clear why you ask for 32 bytes of entropy in
> particular.
> 
> Ciao
> Hannes
> 


-- 
Nat Sakimura (n-sakimura@nri.co.jp)
Nomura Research Institute, Ltd. 

$BK\%a!<%k$K4^$^$l$k>pJs$O5!L)>pJs$G$"$j!"08@h$K5-:\$5$l$F$$$kJ}$N$_$KAw?.(B
$B$9$k$3$H$r0U?^$7$F$*$j$^$9!#0U?^$5$l$?pJs$N(B
$B3+<(!"J#@=!":FG[I[$dE>Aw$J$I0l@Z$NMxMQ$,6X;_$5$l$F$$$^$9!#8m$C$FK\%a!<%k(B
$B$rl9g$O!"?=$7Lu$4$6$$$^$;$s$,!"Aw?.
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBB61A1B9A for ; Tue, 17 Feb 2015 20:33:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08DestPo1xab for ; Tue, 17 Feb 2015 20:33:44 -0800 (PST)
Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F400D1A03AB for ; Tue, 17 Feb 2015 20:33:43 -0800 (PST)
Received: by paceu11 with SMTP id eu11so11629486pac.10 for ; Tue, 17 Feb 2015 20:33:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=KdFqnfmUM4E4G8Cgc9aiKtKH2tkaU8vlC9QoRKBpNdo=; b=UKhqtuh+PglmXa7BExb0Jknui//vCOL0HTgagmOv8U6oepfFmba4sspEMfs/U1yksb 7hb7bZaWVPdw6QnrFE4Kf8a2reY/M/fR3HtOOFucMMmo+8L1tVWzNEgCnjgAir1wVylf nlz+jn0kOG3PbMZwki3VNQ5kKLLSOL5T0dsxwsXE7WAxQOLfyf+KxNYrdtjULojlxo08 9tcyUJNEy0N/SBs3fdrQGRmbd4uQP9kMoBYzhP4JX6+jH5gqBJdIwfaMBWbVXfXXVOc+ wGEPkIFZiS0bYhDCDH4NE5rdq7Va63TD3tEPRET8f4GDZlek/fDUZ582oKoWAUVXJyDj EWIQ==
X-Gm-Message-State: ALoCoQnVsDlidoFiblpS0rC2CNEEMgz+L30XHmZ1YjCM6QNy2Vf3hHJ7hiNPqva3xQ00FyvROjB8
X-Received: by 10.68.231.102 with SMTP id tf6mr55141945pbc.40.1424234023580; Tue, 17 Feb 2015 20:33:43 -0800 (PST)
Received: from [10.1.1.16] (75-149-33-126-SFBA.hfc.comcastbusiness.net. [75.149.33.126]) by mx.google.com with ESMTPSA id l4sm19203836pdj.47.2015.02.17.20.33.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Feb 2015 20:33:42 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_6E1EEE2F-E757-47D9-99A0-6990CB1B966D"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: <20150218131359.19dae026d3e459813e21dc55@nri.co.jp>
Date: Tue, 17 Feb 2015 20:33:36 -0800
Message-Id: 
References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "oauth@ietf.org" , Naveen Agarwal 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 04:33:45 -0000

--Apple-Mail=_6E1EEE2F-E757-47D9-99A0-6990CB1B966D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


I hereby confirm that I have submit the draft  in full conformance with =
the  provisions of BCP 78 and BCP 79.


--Apple-Mail=_6E1EEE2F-E757-47D9-99A0-6990CB1B966D
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMTgwNDMzMzdaMCMGCSqGSIb3DQEJBDEWBBSA/FaKQVuC8pztDzWyZlXN
qwgByTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCLqCqHxAGQZdZpnRgyG0Q3dq6r8/JJlF2lfJakoFrvSpFPXwYfPY5Q
Q/yLPbrbdZY/3QhIRK0ToETAKTUBrvNN4sRRuaZtmcP5Q3Q8DL2iCvddMg3wDIQ0RmZsTHeLJMid
3Zna8SrLuuIn+4TkXPGtjj2nCRLYCWkJU1/G8GgAYRB6fkPjXxVXTIrPfpji8BQ0A01Eln567cFf
uEk0MZB/oh0CclSkQXH/4ZxVQ6LGkflKia3COfK2WFkUVuqQNhJ/lSya39QVG1Z2pnGzuFkBVV9B
R528BC2M2Y+jqm+L2l8pSgFcDjUHfFEWYfgk8EU0NYFJ2FzRHyzB/q8MhLHqAAAAAAAA
--Apple-Mail=_6E1EEE2F-E757-47D9-99A0-6990CB1B966D--


From nobody Tue Feb 17 20:42:14 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970B41A899C for ; Tue, 17 Feb 2015 20:42:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIouEYQqoYNm for ; Tue, 17 Feb 2015 20:42:09 -0800 (PST)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35541A898F for ; Tue, 17 Feb 2015 20:42:09 -0800 (PST)
Received: by padet14 with SMTP id et14so11660256pad.11 for ; Tue, 17 Feb 2015 20:42:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=WhlvG8g0PH7cfETLCgp03P+yVrBDSd8/kWewAeKFBPk=; b=mXgOqwbLv5EY9wKlmacIbQy3VM0iRSap0Ubxw4l/kv2en044DcpAhKRiKxdp+lWU1H 2hIkX1XSWwB3/bd73I3GMBBD6itPkO2Xz7MgrmHemuqTZ6a2CYMlz5q71sYDb4jvHpLq Bh5AXpLW6nSJyRGgsqg9CF/6mwz9kmmK30dF2jhckLqATMMzl3OZYCvxEtlfpRRiL3aH GxsfRpxUAvzPxCErqHkgLNJeedYfec08ljVqQxYCIVEG+MW5k0b6Vgt8XfPWrWOIAa1W SniWKLcmX49uktdZTy6sHFeQrS8Dr7IhFCGnfC55oRGLB4AA5qZK9AkuxIgzi+QrvtY3 UIVw==
X-Gm-Message-State: ALoCoQm9p9an3X1eB0WWvlmKBrgeuR5VgPFBDFbhxgrtghbXxJ3BRD32X9/tE3xHMSqGhX0fz/jw
X-Received: by 10.68.224.71 with SMTP id ra7mr36922906pbc.140.1424234529292; Tue, 17 Feb 2015 20:42:09 -0800 (PST)
Received: from [10.1.1.16] (75-149-33-126-SFBA.hfc.comcastbusiness.net. [75.149.33.126]) by mx.google.com with ESMTPSA id sf7sm19141860pbc.29.2015.02.17.20.42.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Feb 2015 20:42:08 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_D30D56C1-4ED2-4B62-A956-3374BE20C531"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: <54E372C1.8040204@gmx.net>
Date: Tue, 17 Feb 2015 20:42:06 -0800
Message-Id: 
References: <54E372C1.8040204@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "oauth@ietf.org" , Naveen Agarwal 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 04:42:12 -0000

--Apple-Mail=_D30D56C1-4ED2-4B62-A956-3374BE20C531
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

We have discussed on the list making allowing the entropy for plain to =
be smaller.

32bytes was selected as a good value for S256. =20

The reason for S256 vs plain is that you are assuming an attacker is =
going to intercept the request, and thus you want to have enough entropy =
to prevent offline brute force.

For plain you are assuming that the attacker can't intercept the =
request, and if they do more entropy won't help you.

In the plain case you are only protecting against a on line guess for a =
single use token.   That could safely be much lower entropy as it is not =
protecting against off-line brute force.
128bits would be more than enough in that case.   I left it as 256bits =
for both to not introduce more options and not confuse people about why =
plain needs less entropy than S256.

What is the WG feeling should we recommend different minimum values for =
each of the transforms?

John B.

> On Feb 17, 2015, at 8:56 AM, Hannes Tschofenig =
 wrote:
>=20
> Hi Nat, John, Naveen,
>=20
> thanks a lot for your work on the document.
>=20
> I still need responses to this mail to complete the shepherd writeup:
> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
>=20
> I definitely need the IPR confirmation.
>=20
> It would also be helpful to have someone who implemented the
> specification as it currently is. I asked Brian and Thorsten for
> clarification regarding their statements that they implemented earlier
> versions of the spec.
>=20
> As a final remark I still believe that the text regarding the =
randomness
> is still a bit inconsistent. Here are two examples:
>=20
> 1) In the Security Consideration you write that "The security model
> relies on the fact that the code verifier is not learned or guessed by
> the attacker.  It is vitally important to adhere to this principle. "
>=20
> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD =
have
> enough entropy to make it impractical to guess the value.  It is
> RECOMMENDED that the output of a suitable random number generator be
> used to create a 32-octet sequence."
>=20
> There is clearly a long way from a SHOULD have enough entropy to the
> text in the security consideration section where you ask for 32 bytes
> entropy.
>=20
> It is also not clear why you ask for 32 bytes of entropy in =
particular.
>=20
> Ciao
> Hannes
>=20


--Apple-Mail=_D30D56C1-4ED2-4B62-A956-3374BE20C531
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMTgwNDQyMDdaMCMGCSqGSIb3DQEJBDEWBBQhh0xdxZRC6YZ9a5R47omi
OUNtvTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBai+vdzxPFUFZq69Ri5RHKaPl4dfb1yFWfvdhBZfjvea5Z7btUc7OU
sAT/D3+ttqKoUp6/LtjY7JGCFhdGvx1Lxcev06GBisSwtKtharY/Z4Y9WYYHUzgM67x80aaGnovi
1bSPRxzIeAGay99V6vpyaPyE/XLxBDzXN8xf5mwT7mNCYXF+XBNJ6HP5f7iVld+DGGAtkORyX4D4
VC1kUOsM0bsgB6l7IPWhmVXSj6JkrPAyn0XZCDEqWhiqwr4e8YK2/w0KKLW4en8vW9G7pi7Phz20
Wabk/pnf1m4a0ru2KChHAlaR2H3q14nfF7sA+iybcVLE9hg2sbmCBIQawjr2AAAAAAAA
--Apple-Mail=_D30D56C1-4ED2-4B62-A956-3374BE20C531--


From nobody Wed Feb 18 00:45:22 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEF01A1A5F for ; Wed, 18 Feb 2015 00:45:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cu7RKS-bYCY for ; Wed, 18 Feb 2015 00:45:19 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E111A1A29 for ; Wed, 18 Feb 2015 00:45:19 -0800 (PST)
Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LeMWL-1Xlwoh0lX3-00q8fO; Wed, 18 Feb 2015 09:45:14 +0100
Message-ID: <54E450B2.7020409@gmx.net>
Date: Wed, 18 Feb 2015 09:43:30 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Nat Sakimura 
References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp>
In-Reply-To: <20150218131359.19dae026d3e459813e21dc55@nri.co.jp>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SSFpfMuQHn3oUEBCG22MQrCu76f2eO6sl"
X-Provags-ID: V03:K0:IjSOA47LibIWmhYPF8okYzu77Eo+TVI1SHivbJGCGW3ELyzlXMa tAxpz7O+u6qqf+c2BBKhDQEO2bCXb72X1cwhrtu89gG1sfFgRs603x3K53sQrKQWHndMTW4 bGbZ5KpNylmUUAyj8N3M6APkRshyiYU0sqg/Y4mH54iz2plClTT/i5QWAIvXkDXgEIZnmox GIGPbZk4DUOZCYOuf6BgQ==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "oauth@ietf.org" , naa@google.com
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 08:45:21 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--SSFpfMuQHn3oUEBCG22MQrCu76f2eO6sl
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: quoted-printable

Hi Nat,

thanks for the quick response.

I was hoping to see a statement like "The code verifier MUST have enough
entropy to make it impractical to guess the value." in the text rather
than the SHOULD. Given all the other statements in the draft I am not
sure what the should actually means. Under what conditions would an
implementer not provide enough entropy to make guessing impractical?

Ciao
Hannes

On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> Hi Hannes,=20
>=20
> I hereby confirm that I have submit the draft  in full conformance with=
 the  provisions of BCP 78 and BCP 79.
>=20
> Re: Security Consideration (7.1) and section 4.1
>=20
> The first part of the 7.1 is a non-normative prose explaining that the =
implementers got to make sure that the code verifier is hard to guessed o=
r modeled. In a way, this is laying out the basic security property requi=
rment on the code verifier.=20
>=20
> Then, it goes onto the implementation guideance that one need to use a =
cryptographic random number generator instead of relying on a rand() in s=
ome language that are  not cryptographically random to generate 32-octet =
sequence. The same text is in 4.1 as well.=20
>=20
> We did not copy "code verifier SHOULD have enough entropy to make it im=
practical to guess the value" here because that looked needlessly repeati=
ng, but if you want, I have no objection in adding it to 7.1.=20
>=20
> Alternatively, in 7.1, after explaining the rationale, we can just poin=
t to 4.1 for the control and implementation guidance.=20
>=20
> Re: 32-octet
>=20
> We chose it because we are using SHA256 in generating the code challang=
e.
> Having more entropy does not help us here, while having less octets inc=
reases the risk.=20
>=20
> Best,=20
>=20
> Nat=20
>=20
>=20
>=20
> On Tue, 17 Feb 2015 17:56:33 +0100
> Hannes Tschofenig  wrote:
>=20
>> Hi Nat, John, Naveen,
>>
>> thanks a lot for your work on the document.
>>
>> I still need responses to this mail to complete the shepherd writeup:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
>>
>> I definitely need the IPR confirmation.
>>
>> It would also be helpful to have someone who implemented the
>> specification as it currently is. I asked Brian and Thorsten for
>> clarification regarding their statements that they implemented earlier=

>> versions of the spec.
>>
>> As a final remark I still believe that the text regarding the
>> randomness is still a bit inconsistent. Here are two examples:
>>
>> 1) In the Security Consideration you write that "The security model
>> relies on the fact that the code verifier is not learned or guessed by=

>> the attacker.  It is vitally important to adhere to this principle. "
>>
>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
>> have enough entropy to make it impractical to guess the value.  It is
>> RECOMMENDED that the output of a suitable random number generator be
>> used to create a 32-octet sequence."
>>
>> There is clearly a long way from a SHOULD have enough entropy to the
>> text in the security consideration section where you ask for 32 bytes
>> entropy.
>>
>> It is also not clear why you ask for 32 bytes of entropy in
>> particular.
>>
>> Ciao
>> Hannes
>>
>=20
>=20


--SSFpfMuQHn3oUEBCG22MQrCu76f2eO6sl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJU5FCyAAoJEGhJURNOOiAtRv8IAJM8woXukiEcvyTe3180pPHE
Ti9vh7GfexmAhWsMW+9Y3YzXTPIKUhZHHOdnncBVS5IgyS/F1/XSfi34PmHfrmKS
zlU2JpRYJou3fKBICHNqxv4wKgtCWvkwrwzENUr+GzV19fpjMxHrnMR6fUTB2hn4
Al0risEdi35dikWsE/cB3jgql0mlh4Qg8UCjrzGpW8X0rgbiY8ahVO89MhbSmLy1
Sy7IH64aiMLxYKrpDaqtHE71bCqqGUM8l0OiQQbwALJDWObGqDgsb6uZYDtmvO6V
qC+hvr1SasMV8caermsT9C+hgi0yxKyxueIpm5LcCIJY1vjrwDPf5X1nuYt68Qo=
=Y40K
-----END PGP SIGNATURE-----

--SSFpfMuQHn3oUEBCG22MQrCu76f2eO6sl--


From nobody Wed Feb 18 00:49:38 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5001A9115 for ; Wed, 18 Feb 2015 00:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hXQZZpt9e13 for ; Wed, 18 Feb 2015 00:49:35 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3872F1A8753 for ; Wed, 18 Feb 2015 00:49:35 -0800 (PST)
Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MI8iw-1YPfHS2Wq6-003rF4; Wed, 18 Feb 2015 09:49:29 +0100
Message-ID: <54E451AC.1060704@gmx.net>
Date: Wed, 18 Feb 2015 09:47:40 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: John Bradley 
References: <54E372C1.8040204@gmx.net> 
In-Reply-To: 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vkHQ1nhwDlE2f3lWK9Fb0cdAamKsXDhxX"
X-Provags-ID: V03:K0:KVuiU/fklITbYQqjEsjxDUyKe/8SKQDIqCqq7zGWFV/ZcH8CCYp okQUPFYqHM0WUTNklMccMkEaCrkSxzzYX/9RQ0pP0RSpaF53NaF0ZC2C39O4UI/Ss9KCi75 jShb7WBdFhUWoS+UP6QGZJB3t88GO7dwGh0lHFytJGFOj/7wOJzHUb7QSQCTufNFeUqculs uDB7ko5vaeNHbzfWUnCAw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "oauth@ietf.org" , Naveen Agarwal 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 08:49:37 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vkHQ1nhwDlE2f3lWK9Fb0cdAamKsXDhxX
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi John,

I am fine with the plain vs. SHA256 concept and I understand the
reasoning behind the two. Having the same for both types is also OK for m=
e.

My question about the 32 bytes entropy was based on curiosity. SHA256 is
a function that takes an arbitrary length input and produces an output
with 256 bits. The 256bit output length does not mean that you have put
give it 256bits randomness as input.

If the group thinks that this is a reasonable value (and not too big)
then I am fine with it as well.

Ciao
Hannes

On 02/18/2015 05:42 AM, John Bradley wrote:
> We have discussed on the list making allowing the entropy for plain to =
be smaller.
>=20
> 32bytes was selected as a good value for S256. =20
>=20
> The reason for S256 vs plain is that you are assuming an attacker is go=
ing to intercept the request, and thus you want to have enough entropy to=
 prevent offline brute force.
>=20
> For plain you are assuming that the attacker can't intercept the reques=
t, and if they do more entropy won't help you.
>=20
> In the plain case you are only protecting against a on line guess for a=
 single use token.   That could safely be much lower entropy as it is not=
 protecting against off-line brute force.
> 128bits would be more than enough in that case.   I left it as 256bits =
for both to not introduce more options and not confuse people about why p=
lain needs less entropy than S256.
>=20
> What is the WG feeling should we recommend different minimum values for=
 each of the transforms?
>=20
> John B.
>=20
>> On Feb 17, 2015, at 8:56 AM, Hannes Tschofenig  wrote:
>>
>> Hi Nat, John, Naveen,
>>
>> thanks a lot for your work on the document.
>>
>> I still need responses to this mail to complete the shepherd writeup:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
>>
>> I definitely need the IPR confirmation.
>>
>> It would also be helpful to have someone who implemented the
>> specification as it currently is. I asked Brian and Thorsten for
>> clarification regarding their statements that they implemented earlier=

>> versions of the spec.
>>
>> As a final remark I still believe that the text regarding the randomne=
ss
>> is still a bit inconsistent. Here are two examples:
>>
>> 1) In the Security Consideration you write that "The security model
>> relies on the fact that the code verifier is not learned or guessed by=

>> the attacker.  It is vitally important to adhere to this principle. "
>>
>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD hav=
e
>> enough entropy to make it impractical to guess the value.  It is
>> RECOMMENDED that the output of a suitable random number generator be
>> used to create a 32-octet sequence."
>>
>> There is clearly a long way from a SHOULD have enough entropy to the
>> text in the security consideration section where you ask for 32 bytes
>> entropy.
>>
>> It is also not clear why you ask for 32 bytes of entropy in particular=
=2E
>>
>> Ciao
>> Hannes
>>
>=20


--vkHQ1nhwDlE2f3lWK9Fb0cdAamKsXDhxX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJU5FGsAAoJEGhJURNOOiAtZ8oH/3sPPmBI2q8EvV4DNC5H0MPX
BEH9qntQW2AOcnxYgd5FQ/BvHnUFcnYtu8PHv7JNAYAb5GZycLrxkKwHVx8TbYZv
TqFv2NYKTUx4iS/EbB6tqlvSnwqc2UI/jf5LsG+QBSLe00F42mYCApT8azTd9sKi
LEWss/2+JsueAnD3/0k7GAaHxQSF3GYLOTMzBCPDNAbScFRlbn5aNX6j78MxY4WI
vK6xQyjxGa2lL4nab5BtzKpumqIe1Nq5YPl8bL7y8PZzEle/ys7mgQ5Z4c3qIMF2
nnAkMyfreA+ockbrC2DFN8Q0gDl9lQ936QW/ymdBvSnwOlK5FhwjwqcOgVw3xxM=
=HLBV
-----END PGP SIGNATURE-----

--vkHQ1nhwDlE2f3lWK9Fb0cdAamKsXDhxX--


From nobody Wed Feb 18 01:27:08 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CA21A03E1 for ; Wed, 18 Feb 2015 01:27:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.907
X-Spam-Level: *
X-Spam-Status: No, score=1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.999, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFiDtnV6z58C for ; Wed, 18 Feb 2015 01:27:04 -0800 (PST)
Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757951A0360 for ; Wed, 18 Feb 2015 01:27:04 -0800 (PST)
Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs02.index.or.jp (Postfix) with SMTP id A5CBE196862; Wed, 18 Feb 2015 18:27:03 +0900 (JST)
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea03.index.or.jp (unknown) with ESMTP id t1I9R3kc006003; Wed, 18 Feb 2015 18:27:03 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.3/Switch-3.3.3) with ESMTP id t1I9R32Z007897; Wed, 18 Feb 2015 18:27:03 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.3/Switch-3.3.0/Submit) id t1I9R3Uj007891; Wed, 18 Feb 2015 18:27:03 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf11a.index.or.jp ([172.100.25.17]) by nrims00b.nri.co.jp (Switch-3.3.3/Switch-3.3.3) with ESMTP id t1I9R30W007886; Wed, 18 Feb 2015 18:27:03 +0900
Received: from 127.0.0.1 (127.0.0.1) by m-FILTER with ESMTP; Wed, 18 Feb 2015 18:27:03 +0900
Date: Wed, 18 Feb 2015 18:26:53 +0900
From: Nat Sakimura 
To: Hannes Tschofenig 
Message-Id: <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp>
In-Reply-To: <54E450B2.7020409@gmx.net>
References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp> <54E450B2.7020409@gmx.net>
X-Mailer: Sylpheed 3.4.2 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-MailAdviser: 20141126
Archived-At: 
Cc: "oauth@ietf.org" , naa@google.com
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 09:27:07 -0000

Hi Hannes, 

The reason I have put SHOULD there instead of MUST is 
that there may be a valid reason not to in a controlled 
environment, and it does not interfere the interoperability.
The deployment may opt to use other control than entropy, 
and SHOULD allows it while MUST does not. 

Having said that, if the WG is OK with a MUST there, 
I am fine with incorporating the proposed change. 

Cheers, 

Nat


On Wed, 18 Feb 2015 09:43:30 +0100
Hannes Tschofenig  wrote:

> Hi Nat,
> 
> thanks for the quick response.
> 
> I was hoping to see a statement like "The code verifier MUST have
> enough entropy to make it impractical to guess the value." in the
> text rather than the SHOULD. Given all the other statements in the
> draft I am not sure what the should actually means. Under what
> conditions would an implementer not provide enough entropy to make
> guessing impractical?
> 
> Ciao
> Hannes
> 
> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> > Hi Hannes, 
> > 
> > I hereby confirm that I have submit the draft  in full conformance
> > with the  provisions of BCP 78 and BCP 79.
> > 
> > Re: Security Consideration (7.1) and section 4.1
> > 
> > The first part of the 7.1 is a non-normative prose explaining that
> > the implementers got to make sure that the code verifier is hard to
> > guessed or modeled. In a way, this is laying out the basic security
> > property requirment on the code verifier. 
> > 
> > Then, it goes onto the implementation guideance that one need to
> > use a cryptographic random number generator instead of relying on a
> > rand() in some language that are  not cryptographically random to
> > generate 32-octet sequence. The same text is in 4.1 as well. 
> > 
> > We did not copy "code verifier SHOULD have enough entropy to make
> > it impractical to guess the value" here because that looked
> > needlessly repeating, but if you want, I have no objection in
> > adding it to 7.1. 
> > 
> > Alternatively, in 7.1, after explaining the rationale, we can just
> > point to 4.1 for the control and implementation guidance. 
> > 
> > Re: 32-octet
> > 
> > We chose it because we are using SHA256 in generating the code
> > challange. Having more entropy does not help us here, while having
> > less octets increases the risk. 
> > 
> > Best, 
> > 
> > Nat 
> > 
> > 
> > 
> > On Tue, 17 Feb 2015 17:56:33 +0100
> > Hannes Tschofenig  wrote:
> > 
> >> Hi Nat, John, Naveen,
> >>
> >> thanks a lot for your work on the document.
> >>
> >> I still need responses to this mail to complete the shepherd
> >> writeup:
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> >>
> >> I definitely need the IPR confirmation.
> >>
> >> It would also be helpful to have someone who implemented the
> >> specification as it currently is. I asked Brian and Thorsten for
> >> clarification regarding their statements that they implemented
> >> earlier versions of the spec.
> >>
> >> As a final remark I still believe that the text regarding the
> >> randomness is still a bit inconsistent. Here are two examples:
> >>
> >> 1) In the Security Consideration you write that "The security model
> >> relies on the fact that the code verifier is not learned or
> >> guessed by the attacker.  It is vitally important to adhere to
> >> this principle. "
> >>
> >> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
> >> have enough entropy to make it impractical to guess the value.  It
> >> is RECOMMENDED that the output of a suitable random number
> >> generator be used to create a 32-octet sequence."
> >>
> >> There is clearly a long way from a SHOULD have enough entropy to
> >> the text in the security consideration section where you ask for
> >> 32 bytes entropy.
> >>
> >> It is also not clear why you ask for 32 bytes of entropy in
> >> particular.
> >>
> >> Ciao
> >> Hannes
> >>
> > 
> > 
> 


-- 
Nat Sakimura (n-sakimura@nri.co.jp)
Nomura Research Institute, Ltd. 

$BK\%a!<%k$K4^$^$l$k>pJs$O5!L)>pJs$G$"$j!"08@h$K5-:\$5$l$F$$$kJ}$N$_$KAw?.(B
$B$9$k$3$H$r0U?^$7$F$*$j$^$9!#0U?^$5$l$?pJs$N(B
$B3+<(!"J#@=!":FG[I[$dE>Aw$J$I0l@Z$NMxMQ$,6X;_$5$l$F$$$^$9!#8m$C$FK\%a!<%k(B
$B$rl9g$O!"?=$7Lu$4$6$$$^$;$s$,!"Aw?.
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88451A86FC for ; Wed, 18 Feb 2015 01:47:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1b-tYjhzF1m for ; Wed, 18 Feb 2015 01:47:56 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725AB1A702C for ; Wed, 18 Feb 2015 01:47:56 -0800 (PST)
Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MOSNd-1YRZTP19vh-005pwx; Wed, 18 Feb 2015 10:47:50 +0100
Message-ID: <54E45F22.8060902@gmx.net>
Date: Wed, 18 Feb 2015 10:45:06 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Nat Sakimura 
References: <54E372C1.8040204@gmx.net>	<20150218131359.19dae026d3e459813e21dc55@nri.co.jp>	<54E450B2.7020409@gmx.net> <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp>
In-Reply-To: <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x7RnoLXHRhb01ttAiNthqSJQva0GuP2kA"
X-Provags-ID: V03:K0:b3d/t4SsgDZBGWPOiTHpErX9B1ZzVJDSImj2H+WNcxeslhLe6H2 kjn6A/K7SQAOnNTg7/2JdeVITrj+H/u+TBGyYXnYH0+Z2FlhMHrvKHhMsuhC2iPIJ8kKSwC KPbrOQS+Z5ULU9JhvBCPvjZvoudvy3gkSogiVa8TxcUedD1P1841SqEZRq2KVTkzLsQkhqV a2GogLt+3CPpPAOhxMDDg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "oauth@ietf.org" , naa@google.com
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 09:47:59 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--x7RnoLXHRhb01ttAiNthqSJQva0GuP2kA
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: quoted-printable

I think that the "controlled environment" is a risky idea. I believe we
should definitely go for a MUST.

On 02/18/2015 10:26 AM, Nat Sakimura wrote:
> Hi Hannes,=20
>=20
> The reason I have put SHOULD there instead of MUST is=20
> that there may be a valid reason not to in a controlled=20
> environment, and it does not interfere the interoperability.
> The deployment may opt to use other control than entropy,=20
> and SHOULD allows it while MUST does not.=20
>=20
> Having said that, if the WG is OK with a MUST there,=20
> I am fine with incorporating the proposed change.=20
>=20
> Cheers,=20
>=20
> Nat
>=20
>=20
> On Wed, 18 Feb 2015 09:43:30 +0100
> Hannes Tschofenig  wrote:
>=20
>> Hi Nat,
>>
>> thanks for the quick response.
>>
>> I was hoping to see a statement like "The code verifier MUST have
>> enough entropy to make it impractical to guess the value." in the
>> text rather than the SHOULD. Given all the other statements in the
>> draft I am not sure what the should actually means. Under what
>> conditions would an implementer not provide enough entropy to make
>> guessing impractical?
>>
>> Ciao
>> Hannes
>>
>> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
>>> Hi Hannes,=20
>>>
>>> I hereby confirm that I have submit the draft  in full conformance
>>> with the  provisions of BCP 78 and BCP 79.
>>>
>>> Re: Security Consideration (7.1) and section 4.1
>>>
>>> The first part of the 7.1 is a non-normative prose explaining that
>>> the implementers got to make sure that the code verifier is hard to
>>> guessed or modeled. In a way, this is laying out the basic security
>>> property requirment on the code verifier.=20
>>>
>>> Then, it goes onto the implementation guideance that one need to
>>> use a cryptographic random number generator instead of relying on a
>>> rand() in some language that are  not cryptographically random to
>>> generate 32-octet sequence. The same text is in 4.1 as well.=20
>>>
>>> We did not copy "code verifier SHOULD have enough entropy to make
>>> it impractical to guess the value" here because that looked
>>> needlessly repeating, but if you want, I have no objection in
>>> adding it to 7.1.=20
>>>
>>> Alternatively, in 7.1, after explaining the rationale, we can just
>>> point to 4.1 for the control and implementation guidance.=20
>>>
>>> Re: 32-octet
>>>
>>> We chose it because we are using SHA256 in generating the code
>>> challange. Having more entropy does not help us here, while having
>>> less octets increases the risk.=20
>>>
>>> Best,=20
>>>
>>> Nat=20
>>>
>>>
>>>
>>> On Tue, 17 Feb 2015 17:56:33 +0100
>>> Hannes Tschofenig  wrote:
>>>
>>>> Hi Nat, John, Naveen,
>>>>
>>>> thanks a lot for your work on the document.
>>>>
>>>> I still need responses to this mail to complete the shepherd
>>>> writeup:
>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
>>>>
>>>> I definitely need the IPR confirmation.
>>>>
>>>> It would also be helpful to have someone who implemented the
>>>> specification as it currently is. I asked Brian and Thorsten for
>>>> clarification regarding their statements that they implemented
>>>> earlier versions of the spec.
>>>>
>>>> As a final remark I still believe that the text regarding the
>>>> randomness is still a bit inconsistent. Here are two examples:
>>>>
>>>> 1) In the Security Consideration you write that "The security model
>>>> relies on the fact that the code verifier is not learned or
>>>> guessed by the attacker.  It is vitally important to adhere to
>>>> this principle. "
>>>>
>>>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
>>>> have enough entropy to make it impractical to guess the value.  It
>>>> is RECOMMENDED that the output of a suitable random number
>>>> generator be used to create a 32-octet sequence."
>>>>
>>>> There is clearly a long way from a SHOULD have enough entropy to
>>>> the text in the security consideration section where you ask for
>>>> 32 bytes entropy.
>>>>
>>>> It is also not clear why you ask for 32 bytes of entropy in
>>>> particular.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>
>>>
>>
>=20
>=20


--x7RnoLXHRhb01ttAiNthqSJQva0GuP2kA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJU5F8iAAoJEGhJURNOOiAtxEoH/2xYdihDiPp+C8uCj6dUxRgl
TNnZzr4pUILGWx53H8Kzb701AgCD8+wKVSHwIekXkwTsddV23l/dQei/sCgyTc2z
pkAjxcHWx7CJbGWoPQBG/4uRj4MYu1p9Zw0bzohRrOri8FiE9awFh+QeVArqCQpH
MjJJZzZpLw/R1hxgsgJSrWzwOj3LMrGzwDeVfvuBXHaQWzK2NFIxUqyDVMOwGNHH
d64db9WNbzn8eJAesEobbvxm6ehUCtsPCirp1uDf5fA2ZNMOMBCLNzo+LotXvvvi
TBItPJXjCevEyTyamwU27XFPHxpOqTWtHF4Qrv4/ijNFhHjGQxMR/0ZOzLazBHU=
=M8/Q
-----END PGP SIGNATURE-----

--x7RnoLXHRhb01ttAiNthqSJQva0GuP2kA--


From nobody Wed Feb 18 01:50:14 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980EC1A8711 for ; Wed, 18 Feb 2015 01:50:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-S61l1c2Rix for ; Wed, 18 Feb 2015 01:50:10 -0800 (PST)
Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF891A873C for ; Wed, 18 Feb 2015 01:50:10 -0800 (PST)
Received: by mail-ob0-f171.google.com with SMTP id gq1so91201obb.2 for ; Wed, 18 Feb 2015 01:50:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=YHg0CWDgkuup8LNIRJ0cVfs6Gw4QPREQaMiGKa/6FbQ=; b=ZrbxSYgPSxw8w6KrPeb3t9R+C6anbY5u1ibCyvaHBtS4gYKtq7gqacHUqxAK8iYGXH wgZ06d2dpSADJPXiipyGiQnSURjQBekDHoX6dEI1p/Ik5yRc9g3k2+j/3Lgwp0Fy2Z2r nO0Zo3kaSMegJcvwfpB+CbsH1uGWJl5JZKYe1actfNZgEYI9auo9R0eBkQOAjY8egTju slzrzZwIGSSf7mjQ9xhl9jtmIvopfLQcUlbHJUgTQzX/EcdmFQ3x0qfni9JdiZkgCH+n FW5LGJdWZyOsYC2oVlttgxnoSHKCEcHQ2tBop/VBS+sMSqlUzf1m52v4I13rng37Y+TA lzQQ==
X-Received: by 10.60.230.6 with SMTP id su6mr21576435oec.44.1424253010074; Wed, 18 Feb 2015 01:50:10 -0800 (PST)
MIME-Version: 1.0
References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp> <54E450B2.7020409@gmx.net> <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp> <54E45F22.8060902@gmx.net>
From: Nat Sakimura 
Date: Wed, 18 Feb 2015 09:50:08 +0000
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a1136400abc63ec050f59beaa
Archived-At: 
Cc: "oauth@ietf.org" , naa@google.com
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 09:50:13 -0000

--001a1136400abc63ec050f59beaa
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Is there anyone who has problems changing it to a MUST?
On 2015=E5=B9=B42=E6=9C=8818=E6=97=A5(=E6=B0=B4) at 18:48 Hannes Tschofenig=
 
wrote:

> I think that the "controlled environment" is a risky idea. I believe we
> should definitely go for a MUST.
>
> On 02/18/2015 10:26 AM, Nat Sakimura wrote:
> > Hi Hannes,
> >
> > The reason I have put SHOULD there instead of MUST is
> > that there may be a valid reason not to in a controlled
> > environment, and it does not interfere the interoperability.
> > The deployment may opt to use other control than entropy,
> > and SHOULD allows it while MUST does not.
> >
> > Having said that, if the WG is OK with a MUST there,
> > I am fine with incorporating the proposed change.
> >
> > Cheers,
> >
> > Nat
> >
> >
> > On Wed, 18 Feb 2015 09:43:30 +0100
> > Hannes Tschofenig  wrote:
> >
> >> Hi Nat,
> >>
> >> thanks for the quick response.
> >>
> >> I was hoping to see a statement like "The code verifier MUST have
> >> enough entropy to make it impractical to guess the value." in the
> >> text rather than the SHOULD. Given all the other statements in the
> >> draft I am not sure what the should actually means. Under what
> >> conditions would an implementer not provide enough entropy to make
> >> guessing impractical?
> >>
> >> Ciao
> >> Hannes
> >>
> >> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> >>> Hi Hannes,
> >>>
> >>> I hereby confirm that I have submit the draft  in full conformance
> >>> with the  provisions of BCP 78 and BCP 79.
> >>>
> >>> Re: Security Consideration (7.1) and section 4.1
> >>>
> >>> The first part of the 7.1 is a non-normative prose explaining that
> >>> the implementers got to make sure that the code verifier is hard to
> >>> guessed or modeled. In a way, this is laying out the basic security
> >>> property requirment on the code verifier.
> >>>
> >>> Then, it goes onto the implementation guideance that one need to
> >>> use a cryptographic random number generator instead of relying on a
> >>> rand() in some language that are  not cryptographically random to
> >>> generate 32-octet sequence. The same text is in 4.1 as well.
> >>>
> >>> We did not copy "code verifier SHOULD have enough entropy to make
> >>> it impractical to guess the value" here because that looked
> >>> needlessly repeating, but if you want, I have no objection in
> >>> adding it to 7.1.
> >>>
> >>> Alternatively, in 7.1, after explaining the rationale, we can just
> >>> point to 4.1 for the control and implementation guidance.
> >>>
> >>> Re: 32-octet
> >>>
> >>> We chose it because we are using SHA256 in generating the code
> >>> challange. Having more entropy does not help us here, while having
> >>> less octets increases the risk.
> >>>
> >>> Best,
> >>>
> >>> Nat
> >>>
> >>>
> >>>
> >>> On Tue, 17 Feb 2015 17:56:33 +0100
> >>> Hannes Tschofenig  wrote:
> >>>
> >>>> Hi Nat, John, Naveen,
> >>>>
> >>>> thanks a lot for your work on the document.
> >>>>
> >>>> I still need responses to this mail to complete the shepherd
> >>>> writeup:
> >>>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> >>>>
> >>>> I definitely need the IPR confirmation.
> >>>>
> >>>> It would also be helpful to have someone who implemented the
> >>>> specification as it currently is. I asked Brian and Thorsten for
> >>>> clarification regarding their statements that they implemented
> >>>> earlier versions of the spec.
> >>>>
> >>>> As a final remark I still believe that the text regarding the
> >>>> randomness is still a bit inconsistent. Here are two examples:
> >>>>
> >>>> 1) In the Security Consideration you write that "The security model
> >>>> relies on the fact that the code verifier is not learned or
> >>>> guessed by the attacker.  It is vitally important to adhere to
> >>>> this principle. "
> >>>>
> >>>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
> >>>> have enough entropy to make it impractical to guess the value.  It
> >>>> is RECOMMENDED that the output of a suitable random number
> >>>> generator be used to create a 32-octet sequence."
> >>>>
> >>>> There is clearly a long way from a SHOULD have enough entropy to
> >>>> the text in the security consideration section where you ask for
> >>>> 32 bytes entropy.
> >>>>
> >>>> It is also not clear why you ask for 32 bytes of entropy in
> >>>> particular.
> >>>>
> >>>> Ciao
> >>>> Hannes
> >>>>
> >>>
> >>>
> >>
> >
> >
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001a1136400abc63ec050f59beaa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Is there anyone who has problems changing it to a MUST? 
On 2015=E5=B9=B42=E6=9C=8818=E6=97=A5(=E6=B0=B4) at 18:48 Hanne=
s Tschofenig <hannes.tschof=
enig@gmx.net> wrote:
I think that =
the "controlled environment" is a risky idea. I believe we

should definitely go for a MUST.



On 02/18/2015 10:26 AM, Nat Sakimura wrote:

> Hi Hannes,

>

> The reason I have put SHOULD there instead of MUST is

> that there may be a valid reason not to in a controlled

> environment, and it does not interfere the interoperability.

> The deployment may opt to use other control than entropy,

> and SHOULD allows it while MUST does not.

>

> Having said that, if the WG is OK with a MUST there,

> I am fine with incorporating the proposed change.

>

> Cheers,

>

> Nat

>

>

> On Wed, 18 Feb 2015 09:43:30 +0100

> Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>

>> Hi Nat,

>>

>> thanks for the quick response.

>>

>> I was hoping to see a statement like "The code verifier MUST =
have

>> enough entropy to make it impractical to guess the value." in=
 the

>> text rather than the SHOULD. Given all the other statements in the=


>> draft I am not sure what the should actually means. Under what

>> conditions would an implementer not provide enough entropy to make=


>> guessing impractical?

>>

>> Ciao

>> Hannes

>>

>> On 02/18/2015 05:13 AM, Nat Sakimura wrote:

>>> Hi Hannes,

>>>

>>> I hereby confirm that I have submit the draft=C2=A0 in full co=
nformance

>>> with the=C2=A0 provisions of BCP 78 and BCP 79.

>>>

>>> Re: Security Consideration (7.1) and section 4.1

>>>

>>> The first part of the 7.1 is a non-normative prose explaining =
that

>>> the implementers got to make sure that the code verifier is ha=
rd to

>>> guessed or modeled. In a way, this is laying out the basic sec=
urity

>>> property requirment on the code verifier.

>>>

>>> Then, it goes onto the implementation guideance that one need =
to

>>> use a cryptographic random number generator instead of relying=
 on a

>>> rand() in some language that are=C2=A0 not cryptographically r=
andom to

>>> generate 32-octet sequence. The same text is in 4.1 as well.
>>>

>>> We did not copy "code verifier SHOULD have enough entropy=
 to make

>>> it impractical to guess the value" here because that look=
ed

>>> needlessly repeating, but if you want, I have no objection in<=
br>
>>> adding it to 7.1.

>>>

>>> Alternatively, in 7.1, after explaining the rationale, we can =
just

>>> point to 4.1 for the control and implementation guidance.

>>>

>>> Re: 32-octet

>>>

>>> We chose it because we are using SHA256 in generating the code=


>>> challange. Having more entropy does not help us here, while ha=
ving

>>> less octets increases the risk.

>>>

>>> Best,

>>>

>>> Nat

>>>

>>>

>>>

>>> On Tue, 17 Feb 2015 17:56:33 +0100

>>> Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>>>

>>>> Hi Nat, John, Naveen,

>>>>

>>>> thanks a lot for your work on the document.

>>>>

>>>> I still need responses to this mail to complete the shephe=
rd

>>>> writeup:

>>>> http://www.ietf.org/mail-archiv=
e/web/oauth/current/msg14100.html

>>>>

>>>> I definitely need the IPR confirmation.

>>>>

>>>> It would also be helpful to have someone who implemented t=
he

>>>> specification as it currently is. I asked Brian and Thorst=
en for

>>>> clarification regarding their statements that they impleme=
nted

>>>> earlier versions of the spec.

>>>>

>>>> As a final remark I still believe that the text regarding =
the

>>>> randomness is still a bit inconsistent. Here are two examp=
les:

>>>>

>>>> 1) In the Security Consideration you write that "The =
security model

>>>> relies on the fact that the code verifier is not learned o=
r

>>>> guessed by the attacker.=C2=A0 It is vitally important to =
adhere to

>>>> this principle. "

>>>>

>>>> 2) In Section 4.1 you, however, write: "NOTE: code ve=
rifier SHOULD

>>>> have enough entropy to make it impractical to guess the va=
lue.=C2=A0 It

>>>> is RECOMMENDED that the output of a suitable random number=


>>>> generator be used to create a 32-octet sequence."

>>>>

>>>> There is clearly a long way from a SHOULD have enough entr=
opy to

>>>> the text in the security consideration section where you a=
sk for

>>>> 32 bytes entropy.

>>>>

>>>> It is also not clear why you ask for 32 bytes of entropy i=
n

>>>> particular.

>>>>

>>>> Ciao

>>>> Hannes

>>>>

>>>

>>>

>>

>

>



_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth




--001a1136400abc63ec050f59beaa--


From nobody Wed Feb 18 05:16:13 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EDD1A1ACC for ; Wed, 18 Feb 2015 05:16:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Level: 
X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5PEsNWIQS6K for ; Wed, 18 Feb 2015 05:16:04 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D921A1A9A for ; Wed, 18 Feb 2015 05:16:04 -0800 (PST)
Received: from [80.67.16.136] (helo=webmail.df.eu) by smtprelay03.ispgateway.de with esmtpa (Exim 4.84) (envelope-from ) id 1YO4Ty-0004Jh-RZ; Wed, 18 Feb 2015 14:16:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 18 Feb 2015 14:16:02 +0100
From: torsten@lodderstedt.net
To: Hannes Tschofenig 
In-Reply-To: <54E370F9.8060209@gmx.net>
References: <54C7BBA4.4030702@gmx.net>  <2E3D2EE7-8F5F-452D-880A-D62A513AC853@lodderstedt.net> <54E370F9.8060209@gmx.net>
Message-ID: <17faabb6e724fb54f3cb8060a3d9cb08@lodderstedt.net>
X-Sender: torsten@lodderstedt.net
User-Agent: Roundcube Webmail
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: oauth@ietf.org, "naa@google.com >> Naveen Agarwal" 
Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 13:16:11 -0000

Hi Hannes,

our implementation supports the "plain" mode only. We just verified 
compliance of our implementation with the current spec. As the only 
deviation, we do not enforce the minimum length of 43 characters of the 
code verifier.

kind regards,
Torsten.

Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
> Hi Torsten,
> 
> does this mean that your implementation is not compliant with the
> current version anymore or that you haven't had time to verify whether
> there are differences to the earlier version?
> 
> Ciao
> Hannes
> 
> 
> On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
>> Deutsche Telekom also implemented an early version of the draft last 
>> year.
>> 
>> 
>> 
>> Am 30.01.2015 um 18:50 schrieb Brian Campbell
>> >:
>> 
>>> 
>>> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
>>> > wrote:
>>> 
>>> 
>>>     1) What implementations of the spec are you aware of?
>>> 
>>> 
>>> We have an AS side implementation of an earlier draft that was
>>> released in June of last year:
>>> http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth


From nobody Wed Feb 18 05:36:38 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E661A049C for ; Wed, 18 Feb 2015 05:36:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3INNbvLY4t3A for ; Wed, 18 Feb 2015 05:36:32 -0800 (PST)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D181A874A for ; Wed, 18 Feb 2015 05:36:32 -0800 (PST)
Received: from [80.67.16.136] (helo=webmail.df.eu) by smtprelay02.ispgateway.de with esmtpa (Exim 4.84) (envelope-from ) id 1YO4nk-0001Fs-0k; Wed, 18 Feb 2015 14:36:28 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_88f42f6cdf4a4948d571e13ef8175469"
Date: Wed, 18 Feb 2015 14:36:27 +0100
From: torsten@lodderstedt.net
To: Nat Sakimura 
In-Reply-To: 
References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp> <54E450B2.7020409@gmx.net> <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp> <54E45F22.8060902@gmx.net> 
Message-ID: <8b765b012cb7bf7ac3c6c203307d6d86@lodderstedt.net>
X-Sender: torsten@lodderstedt.net
User-Agent: Roundcube Webmail
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: oauth@ietf.org, naa@google.com
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 13:36:36 -0000

--=_88f42f6cdf4a4948d571e13ef8175469
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

 

Hi Nat, 

as far as I understand, the length of at least 32 octets is justified
for S256 only. So limiting the MUST to S256 would be ok (from my
perspective). I consider a general MUST (which also applies to plain) a
to strong requirement. 

kind regards,
Torsten. 

Am 18.02.2015 10:50, schrieb Nat Sakimura: 

> Is there anyone who has problems changing it to a MUST? 
> On 2015年2月18日(水) at 18:48 Hannes Tschofenig  wrote:
> 
>> I think that the "controlled environment" is a risky idea. I believe we
>> should definitely go for a MUST.
>> 
>> On 02/18/2015 10:26 AM, Nat Sakimura wrote:
>>> Hi Hannes,
>>> 
>>> The reason I have put SHOULD there instead of MUST is
>>> that there may be a valid reason not to in a controlled
>>> environment, and it does not interfere the interoperability.
>>> The deployment may opt to use other control than entropy,
>>> and SHOULD allows it while MUST does not.
>>> 
>>> Having said that, if the WG is OK with a MUST there,
>>> I am fine with incorporating the proposed change.
>>> 
>>> Cheers,
>>> 
>>> Nat
>>> 
>>> 
>>> On Wed, 18 Feb 2015 09:43:30 +0100
>>> Hannes Tschofenig  wrote:
>>> 
>>>> Hi Nat,
>>>> 
>>>> thanks for the quick response.
>>>> 
>>>> I was hoping to see a statement like "The code verifier MUST have
>>>> enough entropy to make it impractical to guess the value." in the
>>>> text rather than the SHOULD. Given all the other statements in the
>>>> draft I am not sure what the should actually means. Under what
>>>> conditions would an implementer not provide enough entropy to make
>>>> guessing impractical?
>>>> 
>>>> Ciao
>>>> Hannes
>>>> 
>>>> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
>>>>> Hi Hannes,
>>>>> 
>>>>> I hereby confirm that I have submit the draft in full conformance
>>>>> with the provisions of BCP 78 and BCP 79.
>>>>> 
>>>>> Re: Security Consideration (7.1) and section 4.1
>>>>> 
>>>>> The first part of the 7.1 is a non-normative prose explaining that
>>>>> the implementers got to make sure that the code verifier is hard to
>>>>> guessed or modeled. In a way, this is laying out the basic security
>>>>> property requirment on the code verifier.
>>>>> 
>>>>> Then, it goes onto the implementation guideance that one need to
>>>>> use a cryptographic random number generator instead of relying on a
>>>>> rand() in some language that are not cryptographically random to
>>>>> generate 32-octet sequence. The same text is in 4.1 as well.
>>>>> 
>>>>> We did not copy "code verifier SHOULD have enough entropy to make
>>>>> it impractical to guess the value" here because that looked
>>>>> needlessly repeating, but if you want, I have no objection in
>>>>> adding it to 7.1.
>>>>> 
>>>>> Alternatively, in 7.1, after explaining the rationale, we can just
>>>>> point to 4.1 for the control and implementation guidance.
>>>>> 
>>>>> Re: 32-octet
>>>>> 
>>>>> We chose it because we are using SHA256 in generating the code
>>>>> challange. Having more entropy does not help us here, while having
>>>>> less octets increases the risk.
>>>>> 
>>>>> Best,
>>>>> 
>>>>> Nat
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, 17 Feb 2015 17:56:33 +0100
>>>>> Hannes Tschofenig  wrote:
>>>>> 
>>>>>> Hi Nat, John, Naveen,
>>>>>> 
>>>>>> thanks a lot for your work on the document.
>>>>>> 
>>>>>> I still need responses to this mail to complete the shepherd
>>>>>> writeup:
>>>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html [1]
>>>>>> 
>>>>>> I definitely need the IPR confirmation.
>>>>>> 
>>>>>> It would also be helpful to have someone who implemented the
>>>>>> specification as it currently is. I asked Brian and Thorsten for
>>>>>> clarification regarding their statements that they implemented
>>>>>> earlier versions of the spec.
>>>>>> 
>>>>>> As a final remark I still believe that the text regarding the
>>>>>> randomness is still a bit inconsistent. Here are two examples:
>>>>>> 
>>>>>> 1) In the Security Consideration you write that "The security model
>>>>>> relies on the fact that the code verifier is not learned or
>>>>>> guessed by the attacker. It is vitally important to adhere to
>>>>>> this principle. "
>>>>>> 
>>>>>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
>>>>>> have enough entropy to make it impractical to guess the value. It
>>>>>> is RECOMMENDED that the output of a suitable random number
>>>>>> generator be used to create a 32-octet sequence."
>>>>>> 
>>>>>> There is clearly a long way from a SHOULD have enough entropy to
>>>>>> the text in the security consideration section where you ask for
>>>>>> 32 bytes entropy.
>>>>>> 
>>>>>> It is also not clear why you ask for 32 bytes of entropy in
>>>>>> particular.
>>>>>> 
>>>>>> Ciao
>>>>>> Hannes
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth [2]
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth [2]

 

Links:
------
[1] http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
[2] https://www.ietf.org/mailman/listinfo/oauth

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




Hi Nat,


as far as I understand, the length of at least 32 octets is justified fo=
r S256 only. So limiting the MUST to S256 would be ok (from my perspective)=
=2E I consider a general MUST (which also applies to plain) a to strong req=
uirement.


kind regards,
Torsten.


Am 18.02.2015 10:50, schrieb Nat Sakimura:




Is there anyone who has problems changing it to a MUST? 


On 2015=E5=B9=B42=E6=9C=8818=E6=97=A5(=E6=B0=B4)=
 at 18:48 Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:


I think that the "controlled environme=
nt" is a risky idea. I believe we
 should definitely go for a MUST.
 On 02/18/2015 10:26 AM, Nat Sakimura wrote:
 > Hi Hannes,=

 >
 > The reason I have put SHOULD there instead of MUST i=
s
 > that there may be a valid reason not to in a controlled
 =
> environment, and it does not interfere the interoperability.
 >=
; The deployment may opt to use other control than entropy,
 > and =
SHOULD allows it while MUST does not.
 >
 > Having said tha=
t, if the WG is OK with a MUST there,
 > I am fine with incorporati=
ng the proposed change.
 >
 > Cheers,
 >
 >=
 Nat
 >
 >
 > On Wed, 18 Feb 2015 09:43:30 +0100 > Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
 >
 >> Hi Nat,=

 >>
 >> thanks for the quick response.
 >>=
;
 >> I was hoping to see a statement like "The code verifier MU=
ST have
 >> enough entropy to make it impractical to guess the v=
alue." in the
 >> text rather than the SHOULD. Given all the oth=
er statements in the
 >> draft I am not sure what the should act=
ually means. Under what
 >> conditions would an implementer not =
provide enough entropy to make
 >> guessing impractical?
 &=
gt;>
 >> Ciao
 >> Hannes
 >>
 >=
> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
 >>> Hi Hann=
es,
 >>>
 >>> I hereby confirm that I have subm=
it the draft  in full conformance
 >>> with the  pr=
ovisions of BCP 78 and BCP 79.
 >>>
 >>> Re: Se=
curity Consideration (7.1) and section 4.1
 >>>
 >>=
;> The first part of the 7.1 is a non-normative prose explaining that >>> the implementers got to make sure that the code verifier i=
s hard to
 >>> guessed or modeled. In a way, this is laying o=
ut the basic security
 >>> property requirment on the code ve=
rifier.
 >>>
 >>> Then, it goes onto the implem=
entation guideance that one need to
 >>> use a cryptographic =
random number generator instead of relying on a
 >>> rand() i=
n some language that are  not cryptographically random to
 >&g=
t;> generate 32-octet sequence. The same text is in 4.1 as well.
 &=
gt;>>
 >>> We did not copy "code verifier SHOULD have e=
nough entropy to make
 >>> it impractical to guess the value"=
 here because that looked
 >>> needlessly repeating, but if y=
ou want, I have no objection in
 >>> adding it to 7.1.
 =
>>>
 >>> Alternatively, in 7.1, after explaining the=
 rationale, we can just
 >>> point to 4.1 for the control and=
 implementation guidance.
 >>>
 >>> Re: 32-octe=
t
 >>>
 >>> We chose it because we are using SH=
A256 in generating the code
 >>> challange. Having more entro=
py does not help us here, while having
 >>> less octets incre=
ases the risk.
 >>>
 >>> Best,
 >>&g=
t;
 >>> Nat
 >>>
 >>>
 >&=
gt;>
 >>> On Tue, 17 Feb 2015 17:56:33 +0100
 >>=
;> Hannes Tschofenig <ha=
nnes.tschofenig@gmx.net> wrote:
 >>>
 >>>=
;> Hi Nat, John, Naveen,
 >>>>
 >>>> t=
hanks a lot for your work on the document.
 >>>>
 >=
;>>> I still need responses to this mail to complete the shepherd<=
br /> >>>> writeup:
 >>>> http://www.ietf.or=
g/mail-archive/web/oauth=
/current/msg14100.html
 >>>>
 >>>> I definitely need the IPR =
confirmation.
 >>>>
 >>>> It would also b=
e helpful to have someone who implemented the
 >>>> specif=
ication as it currently is. I asked Brian and Thorsten for
 >>&g=
t;> clarification regarding their statements that they implemented
=
 >>>> earlier versions of the spec.
 >>>>
 >>>> As a final remark I still believe that the text regardin=
g the
 >>>> randomness is still a bit inconsistent. Here a=
re two examples:
 >>>>
 >>>> 1) In the Se=
curity Consideration you write that "The security model
 >>>&=
gt; relies on the fact that the code verifier is not learned or
 >&=
gt;>> guessed by the attacker.  It is vitally important to adher=
e to
 >>>> this principle. "
 >>>>
 =
>>>> 2) In Section 4.1 you, however, write: "NOTE: code verifie=
r SHOULD
 >>>> have enough entropy to make it impractical =
to guess the value.  It
 >>>> is RECOMMENDED that the=
 output of a suitable random number
 >>>> generator be use=
d to create a 32-octet sequence."
 >>>>
 >>>=
> There is clearly a long way from a SHOULD have enough entropy to
=
 >>>> the text in the security consideration section where you =
ask for
 >>>> 32 bytes entropy.
 >>>>
 >>>> It is also not clear why you ask for 32 bytes of entrop=
y in
 >>>> particular.
 >>>>
 >&g=
t;>> Ciao
 >>>> Hannes
 >>>>
 =
>>>
 >>>
 >>
 >
 >
<=
br /> _______________________________________________
 OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






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





 


 



--=_88f42f6cdf4a4948d571e13ef8175469--


From nobody Wed Feb 18 05:52:02 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E501A8851 for ; Wed, 18 Feb 2015 05:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ4aNyK37WsY for ; Wed, 18 Feb 2015 05:51:56 -0800 (PST)
Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785191A8835 for ; Wed, 18 Feb 2015 05:51:55 -0800 (PST)
Received: by labpn19 with SMTP id pn19so1227680lab.4 for ; Wed, 18 Feb 2015 05:51:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GoQfDbjBN7xR0vl0cnj9un0RNrb3k6rJ+SqPGlDW/A8=; b=Vfr5HfCWarEkVjWZ5s1Ym4W/qIlS+ZCfqPNqpxO3GMkCvDPMiJJE5Y7jixUghUCqoG VFJ7K89rJgCSVKwQF+x71pDgVYGf3V4kU1npMcEvyYpgF6+8/UC1FIICzGxTES83Hv1m HnoKF41kd9B29PciIhgGfvn2WBZCLC4MIRq0h0fI4/XHEmNeX31dM0sql6HBq1mSq6if 1aAra+PC88b3z/o4Fu59jmZ6VhFdk1nPpU3CxEtlveyHfKU+hiAKi2bPHEChVWxXxKXi MjgoMemYCURb6mex3JCdZbCZ+9sBRvq5Kdsp3zY9PrKygDHEHQAOrD9/iYdMeqTHOkdk zH/Q==
MIME-Version: 1.0
X-Received: by 10.152.8.33 with SMTP id o1mr34450870laa.56.1424267513947; Wed, 18 Feb 2015 05:51:53 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Wed, 18 Feb 2015 05:51:53 -0800 (PST)
In-Reply-To: 
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com> <54E28EB1.7020504@mit.edu> 
Date: Wed, 18 Feb 2015 08:51:53 -0500
Message-ID: 
From: Kathleen Moriarty 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=001a11c32d183bebc1050f5d1f70
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 13:52:02 -0000

--001a11c32d183bebc1050f5d1f70
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Feb 17, 2015 at 7:03 PM, Phil Hunt  wrote:

> I=E2=80=99m not sure if this is what Kathleen is after. I think part of t=
he
> background in the current spec is that we were trying to differentiate fr=
om
> the large scale success stories OAuth has had in the past like Facebook a=
nd
> Google.  When you are a developer trying to build a client for IMAP, a
> standards based protocol, you can=E2=80=99t predict what the endpoints ar=
e in
> advance, so obviously an IMAP developer can=E2=80=99t obtain client_ids s=
ince they
> can=E2=80=99t predict the future. Nor would it be reasonable to pre-regis=
ter with
> every possible email deployment in the world.
>

For this, I was just after improved text to clarify the definitions after
seeing the issue in the shepherd writeup and seeing it as I read the
draft.  This looks better to me and I'd like the shepherd to weigh in to
make sure he also thinks the updated definitions clarify the intent for him
as well.

Hannes, what do you think?

>
> NOTE:   We might want to change the terminology from =E2=80=9CAPI=E2=80=
=9D to application
> service or application protocol.  I know some an IETF see the word API an=
d
> associate that exclusively with programming libraries.
>
> deployment organization
>       An administrative security domain under which a software API
> (service) is
>       deployed and protected by an OAuth 2.0 framework. In early OAuth
>       scenarios, the deploying organization was often the same organizati=
on
>       that published the API. In these cases the deploying organization
> can have
>      a close relationship with client software developers.  In many other
> cases,
>      the definer of the service may be an independent third-party
> publisher or
>      a standards organization. The client software developer while workin=
g
> to
>      a published specification for an API is unable to have a prior
> relationship
>      with the organization deploying the software API (service).
>
> software api publisher
>       The organization that defines a particular web accessible API that
>       may be deployed in one or more deployment environments.  A publishe=
r
>       may be any standards body, commercial, public, private, or open
> source
>       organization that is responsible for publishing and distributing
>       software that may be protected via OAuth 2.0.  In some cases a
>       software API publisher and a client developer may be the same
>       organization. At the time of publication of a web accessible API,
> the software
>      publisher often does not have a prior relationship with deploying
> organizations.
>
>  Client Developer
>       The person or organization that builds a client software package
>       and prepares it for distribution. At the time of building the
> client, the developer
>       is often not aware of who the deploying service provider
> organizations will be.
>       Except when the software API publisher and the deploying
> organization are
>       the same, client developers will need to use dynamic registration
> when they are
>       unable to predict the deployment URLs at =E2=80=9Ccompile time=E2=
=80=9D.
>

Thank you,
Kathleen

>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
> > On Feb 16, 2015, at 4:43 PM, Justin Richer  wrote:
> >
> > To Mike's last question below: I'd like Phil (and others if desired) to
> propose a clarified version of the "deployment organization", "software a=
pi
> publisher", and "client developer" if possible. With some text for that i=
n
> hand I can tackle the rest given the feedback below.
> >
> > -- Justin
> >
> > On 2/16/2015 6:42 PM, Mike Jones wrote:
> >> A few responses and comments are inline below...
> >>
> >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
> >>> Sent: Thursday, February 12, 2015 11:47 AM
> >>> To: Justin Richer
> >>> Cc: oauth@ietf.org
> >>> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
> >>>
> >>>
> >>> Phil
> >>>
> >>> @independentid
> >>> www.independentid.com
> >>> phil.hunt@oracle.com
> >>>
> >>> On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
> >>>
> >>> Kathleen, thanks for the review. Responses inline, though I'm going t=
o
> let the other authors talk about their sections (deployment org, software
> version, etc) directly.
> >>>
> >>> On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
> >>> Thank you for your work on this draft and sorry for the delay in my
> review.  Before we progress to IETF last call, I'd like to see what we ca=
n
> resolve from the list below.   I am looking at the IPR issues to see if w=
e
> can resolve the outstanding questions as well.
> >>>
> >>> The Shepherd report says the following:
> >>>    The document shepherd has raised concerns regarding the fuzzy
> description
> >>>    of the actors (deployment organization, software API publisher,
> client
> >>>    developer) and their impact on the protocol execution. The working
> >>>    group did not seem to worry about these aspects though.
> >>>
> >>> I can see the point after reading the draft.  The interactions are
> written much more clearly in the security considerations section than whe=
re
> the flows are described.  Can something be done to address these concerns=
?
> >>>
> >>> Section 1.2
> >>> Deployment Organization definition:
> >>> I highly recommend replacing the phrase "simple cloud deployment" wit=
h
> a description that accurately reflects what is intended.  If that's withi=
n
> a single service provider's network, a single data center, or a single
> hosted data center, I think it would be more clear.
> >>>
> >>> Section 1.2 nit:
> >>> Add the word "be" into the following term definition after "may":
> >>>   Software API Publisher
> >>>       The organization that defines a particular web accessible API
> that
> >>>       may deployed in one or more deployment environments.
> >>>
> >>> [deferred to original author of this text Phil et. al for better
> wording]
> >>>
> >>> [Phil] Agreed with Kathleen's suggestion.
> >> I also agree that the wording of the definitions could be clarified.
> Justin, do you want to take a first pass at this or would you like to tak=
e
> lead on this, Phil?
> >>
> >>> Section 2:
> >>>
> >>> Why isn't a more secure option offered and set as the default for
> authentication types? I know I've asked this before and the answer was ju=
st
> that you can add something to the registry, but setting HTTP Basic as the
> default seems like a really bad choice. HOBA is on it's way to becoming a=
n
> RFC from the HTTPAuth working group.  HTTPAuth also has an updated versio=
n
> of Basic that is in IETF last call, but I know you are pointing to the
> OAuth 2.0 document, so it would be that document that gets updated and no=
t
> this draft.  The new version of HTTP Basic fixes some internationalizatio=
n
> problems and spells out the security issues much more clearly, so it
> probably doesn't matter too much to update the reference, but maybe makes
> it more clear that basic is not a secure form of authentication.
> >>>
> >>> Can you provide some justification as to why this is okay to set basi=
c
> as the default and add that to the draft?  Section 2.3.1 of OAuth 2.0 jus=
t
> says this MUST be implemented, but that any HTTP schemes can be used.  Wh=
y
> not register another method and use that instead as the default?  You cou=
ld
> use digest and there is library support.  It's not a great answer, but
> slightly better than passwords with basic.  You could register HOBA and u=
se
> that instead, the only downside is limited library support at the moment.
> >>>
> >>> It was our intent to document the methods already defined for use wit=
h
> OAuth and provide a registration mechanism for distinguishing between the=
m,
> not to create new client authentication mechanisms. Digest and HOBA simpl=
y
> aren't defined for use with OAuth clients yet. It would be simple to do:
> put the client id in the "username" field and the client secret in the
> "password" field of both algorithms. However, I don't believe it's a good
> idea to conflate those two goals in a single specification. We actually h=
ad
> other, more secure definitions in an earlier draft of this document (usin=
g
> a JWT signed with a private key or a JWT signed with a shared key,
> specifically), but those were removed in order to focus on solving just t=
he
> client registration problem. I agree with that decision of the WG.
> >>>
> >>> As other methods of client authentication are defined in the OAuth
> ecosystem, they can register as valid values in the registry. I think it
> would be a valuable output of this WG to define other client authenticati=
on
> mechanisms as a separate draft or an eventual update to RFC6749 (or both?=
).
> >> HTTP Basic is set to the default because that's the default in RFC 674=
9
> and this specification is about registering clients for use with RFC 6749=
.
> Trying to change the RFC 6749 default really isn't within the scope of th=
is
> work.  (If that's done, it should probably be done in an http6749-bis
> spec.)  However, the spec does define a registry that new methods like HO=
BA
> can be registered in when people want to use them.  (And if HOBA finishes
> before Dynamic Registration, I'm fine adding a registry entry for it in
> this spec.)
> >>
> >> If you're interested in the client_secret_jwt and private_key_jwt
> client authentication methods that Justin alluded to, these are defined i=
n
> Section 9 of OpenID Connect Core
> http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication=
.
> >>
> >> In relation to your internationalization comments Kathleen, note that
> Section 2.3.1 of RFC 6749 explicitly provides a mechanism for encoding
> international strings for use with HTTP Basic.  This was added under the
> supervision of Julian Reschke, I believe as a result of his WGLC comments=
.
> So whether this is the same as what the new version of HTTP Basic does or
> not, OAuth 2.0 already does provide a standard way to use internationaliz=
ed
> strings with HTTP Basic for OAuth client authentication.
> >>
> >>> Section 2: Contacts:
> >>>
> >>> I noticed privacy is not dealt with until you get to the security
> considerations section.  I'd prefer to see it with the definition, statin=
g
> the address should be a general help address at the domain rather than
> directly to an identifiable individual.  It may be good to set a default
> for what this should be for consistency or give an example (think back to
> abuse@domain.com)?
> >>>
> >>> The problem that I see with putting it inside the definition is that
> it makes the definition text very long, as the definition sits in a list =
of
> other metadata items. We could add a forward pointer and an example easil=
y
> enough, though. Or we could move the privacy considerations section up as=
 a
> subsection here, though I don't know if that runs afoul of the RFC style
> guidelines for this new section.
> >>>
> >>>
> >>>
> >>> Software_id and software_version:
> >>> Are there any guidelines as to how these should be represented?  Ther=
e
> are several specifications on software_id (and platform).  Does consisten=
cy
> here matter or is this just meant to be human readable?
> >>> Section 2.2 specifies some metadata values that are to be human
> readable, should the above be in the list?  I would expect this list to b=
e
> comprehensive for clarity, rather than just examples since there aren't t=
oo
> many defined here.
> >>>
> >>>
> >>> [mostly deferred to Phil et. al, but note that software_id and
> software_version are not intended to be human readable and don't need the
> multi-language support]
> >> We should probably say that in the draft then.
> >>
> >>> [Phil]
> >>> I've added some more explanatory text. Note...some of this may be
> better put elsewhere.
> >>>
> >>> As to whether the values are human readable, I have no opinion. What
> matters most is unique matching.
> >>>
> >>>    software_id
> >>>       A unique identifier (e.g. UUID) assigned by the developer or
> software publisher
> >>>       used by registration endpoints to identify client software to b=
e
> dynamically registered.
> >>>       Unlike "client_id", which is issued by the authorization server
> and varies between
> >>>       instances of software, the "software_id" SHOULD remain the same
> for all client software
> >>>       instances. The "software_id" SHOULD remain the same across
> multiple software updates
> >>>       or versions.
> >> I'd revise the last two sentences of this as follows:
> >>
> >>       Unlike "client_id", which is issued by the authorization server
> and may vary between
> >>       instances of a piece of software, the "software_id" SHOULD remai=
n
> the same for all instances
> >>       of a piece of software. The "software_id" SHOULD remain the same
> across multiple software updates
> >>       or versions of the same piece of software.
> >>
> >>> software_version
> >>>       A version identifier for the software identified by
> "software_id".  The
> >>>       value of this field is a string that is intended to be compared
> >>>       using string equality matching. Unlike "software_id", the value
> of the
> >>>       "software_version" SHOULD change on any update to the client
> >>>       software. A service provider MAY use "software_id" and
> "software_version" to
> >>>       recognize approved software and version combinations approved
> for dynamic registration.
> >>>
> >>> Let me know if you want more background.
> >>>
> >>>
> >>> Section 3.2.1 & Privacy section
> >>> For client_name and client_id and associated information, how is user
> privacy affected and what can be done to mitigate concerns?  The definiti=
on
> should state that this is a public value and that it is specific to the
> software, not a person.  You have to get to the security consideration
> section before that is clear.  References are fine too, but some more
> information is needed in the privacy section.  I'm left with a bunch of
> questions:
> >>>   Can the client_name and client_id be tied to a person?
> >>> The client name is common across all copies of the software (usually)=
,
> so no worries there. The ID represents an individual piece of software, n=
ot
> a person, though if that person is the sole user of the instance of
> software then I believe you're right that there are some privacy
> considerations that we should point that out. However, dynamic registrati=
on
> can actually help mitigate this as well, since in the normal case (with n=
o
> software statements) there's no way to correlate instances of clients wit=
h
> each other.
> >>>
> >>>   Can the person be tracked by this?
> >>>   Can other information be gathered about a system (and it's user)
> during this process?
> >>> Nothing gathered about the user during registration, as this happens
> in the back channel outside the user's purview.
> >>>
> >>>   The information is used to dynamically register clients, what is
> logged?
> >>>   What data is aggregated?
> >>>   What can you tell about a client (time, location, travel, other
> personal details that may be considered sensitive)?  I don't think this w=
as
> covered in the OAuth 2.0 RFC.
> >>>   How is this addressed at the authorization server and other points?
> >>>   The Security considerations talks about client_id as being short
> lived, so they expire, but are these event logged or is that prohibited?
> >>>
> >>> Many of these questions seem to be completely dependent on the
> implementation of the authorization server, and I'm not really sure how (=
or
> if) to address them in this draft. Any suggestions would be welcomed here=
.
> >>>
> >>> The client_id *could* be short lived, but they usually aren't. I don'=
t
> see any particular logging or tracking concerns using a dynamic OAuth
> client above using any other piece of software, ever. As such, I don't
> think it requires special calling out here.
> >>>
> >>>
> >>>
> >>> 5. Security considerations
> >>> The first paragraph is a repeat of text.  Can this just be in one
> place and use a pointer to the full text?  I like the requirement, but
> reading it once is enough.
> >>>
> >>> I think it was less onerous of a repeat when both simply said "use
> TLS", so some refactoring after the expansion of the text makes sense to
> me. Would it be better to have it upfront in the endpoint definition, or =
in
> the security considerations?
> >> Justin, do you want to make specific rewording proposals for this and
> the other editorial issues that were identified?
> >>
> >>> --
> >>>
> >>> Best regards,
> >>> Kathleen
> >>>
> >>> Thanks again for your review!
> >>>
> >>>  -- Justin
> >>                              Thanks all,
> >>                              -- Mike
> >>
> >
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



--=20

Best regards,
Kathleen

--001a11c32d183bebc1050f5d1f70
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

On Tue, Feb 17, 2015 at 7:03 PM, Phil Hunt <phil.hunt@oracle.com=
> wrote:
I=E2=80=99m not su=
re if this is what Kathleen is after. I think part of the background in the=
 current spec is that we were trying to differentiate from the large scale =
success stories OAuth has had in the past like Facebook and Google.=C2=A0 W=
hen you are a developer trying to build a client for IMAP, a standards base=
d protocol, you can=E2=80=99t predict what the endpoints are in advance, so=
 obviously an IMAP developer can=E2=80=99t obtain client_ids since they can=
=E2=80=99t predict the future. Nor would it be reasonable to pre-register w=
ith every possible email deployment in the world.

=

For this, I was just after improved text to clarify the definiti=
ons after seeing the issue in the shepherd writeup and seeing it as I read =
the draft.=C2=A0 This looks better to me and I'd like the shepherd to w=
eigh in to make sure he also thinks the updated definitions clarify the int=
ent for him as well.

Hannes, what do you think?



NOTE:=C2=A0 =C2=A0We might want to change the terminology from =E2=80=9CAPI=
=E2=80=9D to application service or application protocol.=C2=A0 I know some=
 an IETF see the word API and associate that exclusively with programming l=
ibraries.



deployment organization

=C2=A0 =C2=A0 =C2=A0 An administrative security domain under which a softwa=
re API (service) is

=C2=A0 =C2=A0 =C2=A0 deployed and protected by an OAuth 2.0 framework. In e=
arly OAuth

=C2=A0 =C2=A0 =C2=A0 scenarios, the deploying organization was often the sa=
me organization

=C2=A0 =C2=A0 =C2=A0 that published the API. In these cases the deploying o=
rganization can have

=C2=A0 =C2=A0 =C2=A0a close relationship with client software developers.=
=C2=A0 In many other cases,

=C2=A0 =C2=A0 =C2=A0the definer of the service may be an independent third-=
party publisher or

=C2=A0 =C2=A0 =C2=A0a standards organization. The client software developer=
 while working to

=C2=A0 =C2=A0 =C2=A0a published specification for an API is unable to have =
a prior relationship

=C2=A0 =C2=A0 =C2=A0with the organization deploying the software API (servi=
ce).



software api publisher

=C2=A0 =C2=A0 =C2=A0 The organization that defines a parti=
cular web accessible API that

=C2=A0 =C2=A0 =C2=A0 may be deployed in one or more deployment envir=
onments.=C2=A0 A publisher

=C2=A0 =C2=A0 =C2=A0 may be any standards body, commercial, public, private=
, or open source

=C2=A0 =C2=A0 =C2=A0 organization that is responsible for publishing and di=
stributing

=C2=A0 =C2=A0 =C2=A0 software that may be protected via OAuth 2.0.=C2=A0 In=
 some cases a

=C2=A0 =C2=A0 =C2=A0 software API publisher and a client developer may be t=
he same

=C2=A0 =C2=A0 =C2=A0 organization. At the time of publication of a web acce=
ssible API, the software

=C2=A0 =C2=A0 =C2=A0publisher often does not have a prior relationship with=
 deploying organizations.



=C2=A0Client Developer

=C2=A0 =C2=A0 =C2=A0 The person or organization that builds a client softwa=
re package

=C2=A0 =C2=A0 =C2=A0 and prepares it for distribution. At the time of build=
ing the client, the developer

=C2=A0 =C2=A0 =C2=A0 is often not aware of who the deploying service provid=
er organizations will be.

=C2=A0 =C2=A0 =C2=A0 Except when the software API publisher and the deployi=
ng organization are

=C2=A0 =C2=A0 =C2=A0 the same, client developers will need to use dynamic r=
egistration when they are

=C2=A0 =C2=A0 =C2=A0 unable to predict the deployment URLs at =E2=80=9Ccomp=
ile time=E2=80=9D.

Thank you,
Kathleen=C2=A0



Phil



@independentid

www.independenti=
d.com

phil.hunt@oracle.com




> On Feb 16, 2015, at 4:43 PM, Justin Richer <jricher@mit.edu> wrote:

>

> To Mike's last question below: I'd like Phil (and others if de=
sired) to propose a clarified version of the "deployment organization&=
quot;, "software api publisher", and "client developer"=
 if possible. With some text for that in hand I can tackle the rest given t=
he feedback below.

>

> -- Justin

>

> On 2/16/2015 6:42 PM, Mike Jones wrote:

>> A few responses and comments are inline below...

>>

>>> From: OAuth [mailto:=
oauth-bounces@ietf.org] On Behalf Of Phil Hunt

>>> Sent: Thursday, February 12, 2015 11:47 AM

>>> To: Justin Richer

>>> Cc: oauth@ietf.org

>>> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

>>>

>>>

>>> Phil

>>>

>>> @independentid

>>> www=
.independentid.com

>>> phil.hunt@oracle.com

>>>

>>> On Feb 11, 2015, at 8:31 PM, Justin Richer <jricher@mit.edu> wrote:

>>>

>>> Kathleen, thanks for the review. Responses inline, though I=
9;m going to let the other authors talk about their sections (deployment or=
g, software version, etc) directly.

>>>

>>> On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:

>>> Thank you for your work on this draft and sorry for the delay =
in my review.=C2=A0 Before we progress to IETF last call, I'd like to s=
ee what we can resolve from the list below.=C2=A0 =C2=A0I am looking at the=
 IPR issues to see if we can resolve the outstanding questions as well.

>>>

>>> The Shepherd report says the following:

>>>=C2=A0 =C2=A0 The document shepherd has raised concerns regardi=
ng the fuzzy description

>>>=C2=A0 =C2=A0 of the actors (deployment organization, software =
API publisher, client

>>>=C2=A0 =C2=A0 developer) and their impact on the protocol execu=
tion. The working

>>>=C2=A0 =C2=A0 group did not seem to worry about these aspects t=
hough.

>>>

>>> I can see the point after reading the draft.=C2=A0 The interac=
tions are written much more clearly in the security considerations section =
than where the flows are described.=C2=A0 Can something be done to address =
these concerns?

>>>

>>> Section 1.2

>>> Deployment Organization definition:

>>> I highly recommend replacing the phrase "simple cloud dep=
loyment" with a description that accurately reflects what is intended.=
=C2=A0 If that's within a single service provider's network, a sing=
le data center, or a single hosted data center, I think it would be more cl=
ear.

>>>

>>> Section 1.2 nit:

>>> Add the word "be" into the following term definition=
 after "may":

>>>=C2=A0 =C2=A0Software API Publisher

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The organization that defines a part=
icular web accessible API that

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0may deployed in one or more deployme=
nt environments.

>>>

>>> [deferred to original author of this text Phil et. al for bett=
er wording]

>>>

>>> [Phil] Agreed with Kathleen's suggestion.

>> I also agree that the wording of the definitions could be clarifie=
d.=C2=A0 Justin, do you want to take a first pass at this or would you like=
 to take lead on this, Phil?

>>

>>> Section 2:

>>>

>>> Why isn't a more secure option offered and set as the defa=
ult for authentication types? I know I've asked this before and the ans=
wer was just that you can add something to the registry, but setting HTTP B=
asic as the default seems like a really bad choice. HOBA is on it's way=
 to becoming an RFC from the HTTPAuth working group.=C2=A0 HTTPAuth also ha=
s an updated version of Basic that is in IETF last call, but I know you are=
 pointing to the OAuth 2.0 document, so it would be that document that gets=
 updated and not this draft.=C2=A0 The new version of HTTP Basic fixes some=
 internationalization problems and spells out the security issues much more=
 clearly, so it probably doesn't matter too much to update the referenc=
e, but maybe makes it more clear that basic is not a secure form of authent=
ication.

>>>

>>> Can you provide some justification as to why this is okay to s=
et basic as the default and add that to the draft?=C2=A0 Section 2.3.1 of O=
Auth 2.0 just says this MUST be implemented, but that any HTTP schemes can =
be used.=C2=A0 Why not register another method and use that instead as the =
default?=C2=A0 You could use digest and there is library support.=C2=A0 It&=
#39;s not a great answer, but slightly better than passwords with basic.=C2=
=A0 You could register HOBA and use that instead, the only downside is limi=
ted library support at the moment.

>>>

>>> It was our intent to document the methods already defined for =
use with OAuth and provide a registration mechanism for distinguishing betw=
een them, not to create new client authentication mechanisms. Digest and HO=
BA simply aren't defined for use with OAuth clients yet. It would be si=
mple to do: put the client id in the "username" field and the cli=
ent secret in the "password" field of both algorithms. However, I=
 don't believe it's a good idea to conflate those two goals in a si=
ngle specification. We actually had other, more secure definitions in an ea=
rlier draft of this document (using a JWT signed with a private key or a JW=
T signed with a shared key, specifically), but those were removed in order =
to focus on solving just the client registration problem. I agree with that=
 decision of the WG.

>>>

>>> As other methods of client authentication are defined in the O=
Auth ecosystem, they can register as valid values in the registry. I think =
it would be a valuable output of this WG to define other client authenticat=
ion mechanisms as a separate draft or an eventual update to RFC6749 (or bot=
h?).

>> HTTP Basic is set to the default because that's the default in=
 RFC 6749 and this specification is about registering clients for use with =
RFC 6749.=C2=A0 Trying to change the RFC 6749 default really isn't with=
in the scope of this work.=C2=A0 (If that's done, it should probably be=
 done in an http6749-bis spec.)=C2=A0 However, the spec does define a regis=
try that new methods like HOBA can be registered in when people want to use=
 them.=C2=A0 (And if HOBA finishes before Dynamic Registration, I'm fin=
e adding a registry entry for it in this spec.)

>>

>> If you're interested in the client_secret_jwt and private_key_=
jwt client authentication methods that Justin alluded to, these are defined=
 in Section 9 of OpenID Connect Core http://op=
enid.net/specs/openid-connect-core-1_0.html#ClientAuthentication.

>>

>> In relation to your internationalization comments Kathleen, note t=
hat Section 2.3.1 of RFC 6749 explicitly provides a mechanism for encoding =
international strings for use with HTTP Basic.=C2=A0 This was added under t=
he supervision of Julian Reschke, I believe as a result of his WGLC comment=
s.=C2=A0 So whether this is the same as what the new version of HTTP Basic =
does or not, OAuth 2.0 already does provide a standard way to use internati=
onalized strings with HTTP Basic for OAuth client authentication.

>>

>>> Section 2: Contacts:

>>>

>>> I noticed privacy is not dealt with until you get to the secur=
ity considerations section.=C2=A0 I'd prefer to see it with the definit=
ion, stating the address should be a general help address at the domain rat=
her than directly to an identifiable individual.=C2=A0 It may be good to se=
t a default for what this should be for consistency or give an example (thi=
nk back to abuse@domain.com)?

>>>

>>> The problem that I see with putting it inside the definition i=
s that it makes the definition text very long, as the definition sits in a =
list of other metadata items. We could add a forward pointer and an example=
 easily enough, though. Or we could move the privacy considerations section=
 up as a subsection here, though I don't know if that runs afoul of the=
 RFC style guidelines for this new section.

>>>

>>>

>>>

>>> Software_id and software_version:

>>> Are there any guidelines as to how these should be represented=
?=C2=A0 There are several specifications on software_id (and platform).=C2=
=A0 Does consistency here matter or is this just meant to be human readable=
?

>>> Section 2.2 specifies some metadata values that are to be huma=
n readable, should the above be in the list?=C2=A0 I would expect this list=
 to be comprehensive for clarity, rather than just examples since there are=
n't too many defined here.

>>>

>>>

>>> [mostly deferred to Phil et. al, but note that software_id and=
 software_version are not intended to be human readable and don't need =
the multi-language support]

>> We should probably say that in the draft then.

>>

>>> [Phil]

>>> I've added some more explanatory text. Note...some of this=
 may be better put elsewhere.

>>>

>>> As to whether the values are human readable, I have no opinion=
. What matters most is unique matching.

>>>

>>>=C2=A0 =C2=A0 software_id

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0A unique identifier (e.g. UUID) assi=
gned by the developer or software publisher

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0used by registration endpoints to id=
entify client software to be dynamically registered.

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Unlike "client_id", which =
is issued by the authorization server and varies between

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0instances of software, the "sof=
tware_id" SHOULD remain the same for all client software

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0instances. The "software_id&quo=
t; SHOULD remain the same across multiple software updates

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0or versions.

>> I'd revise the last two sentences of this as follows:

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Unlike "client_id", which is i=
ssued by the authorization server and may vary between

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0instances of a piece of software, the &q=
uot;software_id" SHOULD remain the same for all instances

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0of a piece of software. The "softwa=
re_id" SHOULD remain the same across multiple software updates

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0or versions of the same piece of softwar=
e.

>>

>>> software_version

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0A version identifier for the softwar=
e identified by "software_id".=C2=A0 The

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0value of this field is a string that=
 is intended to be compared

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0using string equality matching. Unli=
ke "software_id", the value of the

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"software_version" SHOULD =
change on any update to the client

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0software. A service provider MAY use=
 "software_id" and "software_version" to

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0recognize approved software and vers=
ion combinations approved for dynamic registration.

>>>

>>> Let me know if you want more background.

>>>

>>>

>>> Section 3.2.1 & Privacy section

>>> For client_name and client_id and associated information, how =
is user privacy affected and what can be done to mitigate concerns?=C2=A0 T=
he definition should state that this is a public value and that it is speci=
fic to the software, not a person.=C2=A0 You have to get to the security co=
nsideration section before that is clear.=C2=A0 References are fine too, bu=
t some more information is needed in the privacy section.=C2=A0 I'm lef=
t with a bunch of questions:

>>>=C2=A0 =C2=A0Can the client_name and client_id be tied to a per=
son?

>>> The client name is common across all copies of the software (u=
sually), so no worries there. The ID represents an individual piece of soft=
ware, not a person, though if that person is the sole user of the instance =
of software then I believe you're right that there are some privacy con=
siderations that we should point that out. However, dynamic registration ca=
n actually help mitigate this as well, since in the normal case (with no so=
ftware statements) there's no way to correlate instances of clients wit=
h each other.

>>>

>>>=C2=A0 =C2=A0Can the person be tracked by this?

>>>=C2=A0 =C2=A0Can other information be gathered about a system (=
and it's user) during this process?

>>> Nothing gathered about the user during registration, as this h=
appens in the back channel outside the user's purview.

>>>

>>>=C2=A0 =C2=A0The information is used to dynamically register cl=
ients, what is logged?

>>>=C2=A0 =C2=A0What data is aggregated?

>>>=C2=A0 =C2=A0What can you tell about a client (time, location, =
travel, other personal details that may be considered sensitive)?=C2=A0 I d=
on't think this was covered in the OAuth 2.0 RFC.

>>>=C2=A0 =C2=A0How is this addressed at the authorization server =
and other points?

>>>=C2=A0 =C2=A0The Security considerations talks about client_id =
as being short lived, so they expire, but are these event logged or is that=
 prohibited?

>>>

>>> Many of these questions seem to be completely dependent on the=
 implementation of the authorization server, and I'm not really sure ho=
w (or if) to address them in this draft. Any suggestions would be welcomed =
here.

>>>

>>> The client_id *could* be short lived, but they usually aren=
9;t. I don't see any particular logging or tracking concerns using a dy=
namic OAuth client above using any other piece of software, ever. As such, =
I don't think it requires special calling out here.

>>>

>>>

>>>

>>> 5. Security considerations

>>> The first paragraph is a repeat of text.=C2=A0 Can this just b=
e in one place and use a pointer to the full text?=C2=A0 I like the require=
ment, but reading it once is enough.

>>>

>>> I think it was less onerous of a repeat when both simply said =
"use TLS", so some refactoring after the expansion of the text ma=
kes sense to me. Would it be better to have it upfront in the endpoint defi=
nition, or in the security considerations?

>> Justin, do you want to make specific rewording proposals for this =
and the other editorial issues that were identified?

>>

>>> --

>>>

>>> Best regards,

>>> Kathleen

>>>

>>> Thanks again for your review!

>>>

>>>=C2=A0 -- Justin

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks all,

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

>>

>



_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





-- 
=


Best regards,
Kathleen




--001a11c32d183bebc1050f5d1f70--


From nobody Wed Feb 18 06:05:12 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770961A924E for ; Wed, 18 Feb 2015 06:05:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level: 
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPtD6W7gHTlN for ; Wed, 18 Feb 2015 06:05:06 -0800 (PST)
Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26B41A912D for ; Wed, 18 Feb 2015 06:04:56 -0800 (PST)
Received: from mail-ie0-f169.google.com ([209.85.223.169]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKVOScCLIpA43m+suHpELg3fPLWTWIHiK2@postini.com; Wed, 18 Feb 2015 06:04:57 PST
Received: by iecar1 with SMTP id ar1so1339156iec.11 for ; Wed, 18 Feb 2015 06:04:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eCZ2eEWgCYom3nFDNGnjXWxYQacGdU3O/vbsbaD0RmU=; b=ggdzS0zoCB7YftGNRAGg7sMPDqXGYY8lv9CUdQE3kTlm/DvRfaztwnZ+AOkEM1Rw7m HMofCctUc2uIXr+nW7ZK0SxvJ7SkkcJzOuKPy/jn96AU41NwdeoDF8/7i7BpQZBZhGXV uIDUsSd437EXI3aUE5DQtJDoIuD2M2NG5tfeAi0sfll0ugbOwgSBudEokhXD0bWRoifC ML8HRDsWckrgENm3s4YhI7D6fQ9rAU4anbFZBWkmsoXt8rCc7xaD7DwqK58hwKKCpBam 20DlNw7XqpQI9H6qCfV+WvmN7VAGthbsvHRcYZMP7HZZkqqxC1Iu9lifhi1KDDE4wrWf I8Sw==
X-Received: by 10.107.129.138 with SMTP id l10mr43770269ioi.37.1424268296266;  Wed, 18 Feb 2015 06:04:56 -0800 (PST)
X-Gm-Message-State: ALoCoQmZ+PFy86RqZBBkBWODr9NUQoTi3ZlEcCVb2cPeNPNbKxd5w7XJAFwJgWqHdXFZdmslmasDXiKXLWx3Sp4rew55i3jaq2DntMQCQEz5CXUdhtXdvwkvsmtTBEpXSUyGRKjSVs3N
X-Received: by 10.107.129.138 with SMTP id l10mr43770249ioi.37.1424268296060;  Wed, 18 Feb 2015 06:04:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.107.105 with HTTP; Wed, 18 Feb 2015 06:04:24 -0800 (PST)
In-Reply-To: <8b765b012cb7bf7ac3c6c203307d6d86@lodderstedt.net>
References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp> <54E450B2.7020409@gmx.net> <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp> <54E45F22.8060902@gmx.net>  <8b765b012cb7bf7ac3c6c203307d6d86@lodderstedt.net>
From: Brian Campbell 
Date: Wed, 18 Feb 2015 07:04:24 -0700
Message-ID: 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=001a113f9ba2da1c0c050f5d4d31
Archived-At: 
Cc: oauth , Naveen Agarwal 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 14:05:11 -0000

--001a113f9ba2da1c0c050f5d4d31
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I tend to agree with Torsten here - similar sentiments were (maybe not
well) expressed a few weeks ago:
http://www.ietf.org/mail-archive/web/oauth/current/msg14155.html



On Wed, Feb 18, 2015 at 6:36 AM,  wrote:

>  Hi Nat,
>
> as far as I understand, the length of at least 32 octets is justified for
> S256 only. So limiting the MUST to S256 would be ok (from my perspective)=
.
> I consider a general MUST (which also applies to plain) a to strong
> requirement.
>
> kind regards,
> Torsten.
>
> Am 18.02.2015 10:50, schrieb Nat Sakimura:
>
> Is there anyone who has problems changing it to a MUST?
> On 2015=E5=B9=B42=E6=9C=8818=E6=97=A5(=E6=B0=B4) at 18:48 Hannes Tschofen=
ig 
> wrote:
>
>> I think that the "controlled environment" is a risky idea. I believe we
>> should definitely go for a MUST.
>>
>> On 02/18/2015 10:26 AM, Nat Sakimura wrote:
>> > Hi Hannes,
>> >
>> > The reason I have put SHOULD there instead of MUST is
>> > that there may be a valid reason not to in a controlled
>> > environment, and it does not interfere the interoperability.
>> > The deployment may opt to use other control than entropy,
>> > and SHOULD allows it while MUST does not.
>> >
>> > Having said that, if the WG is OK with a MUST there,
>> > I am fine with incorporating the proposed change.
>> >
>> > Cheers,
>> >
>> > Nat
>> >
>> >
>> > On Wed, 18 Feb 2015 09:43:30 +0100
>> > Hannes Tschofenig  wrote:
>> >
>> >> Hi Nat,
>> >>
>> >> thanks for the quick response.
>> >>
>> >> I was hoping to see a statement like "The code verifier MUST have
>> >> enough entropy to make it impractical to guess the value." in the
>> >> text rather than the SHOULD. Given all the other statements in the
>> >> draft I am not sure what the should actually means. Under what
>> >> conditions would an implementer not provide enough entropy to make
>> >> guessing impractical?
>> >>
>> >> Ciao
>> >> Hannes
>> >>
>> >> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
>> >>> Hi Hannes,
>> >>>
>> >>> I hereby confirm that I have submit the draft  in full conformance
>> >>> with the  provisions of BCP 78 and BCP 79.
>> >>>
>> >>> Re: Security Consideration (7.1) and section 4.1
>> >>>
>> >>> The first part of the 7.1 is a non-normative prose explaining that
>> >>> the implementers got to make sure that the code verifier is hard to
>> >>> guessed or modeled. In a way, this is laying out the basic security
>> >>> property requirment on the code verifier.
>> >>>
>> >>> Then, it goes onto the implementation guideance that one need to
>> >>> use a cryptographic random number generator instead of relying on a
>> >>> rand() in some language that are  not cryptographically random to
>> >>> generate 32-octet sequence. The same text is in 4.1 as well.
>> >>>
>> >>> We did not copy "code verifier SHOULD have enough entropy to make
>> >>> it impractical to guess the value" here because that looked
>> >>> needlessly repeating, but if you want, I have no objection in
>> >>> adding it to 7.1.
>> >>>
>> >>> Alternatively, in 7.1, after explaining the rationale, we can just
>> >>> point to 4.1 for the control and implementation guidance.
>> >>>
>> >>> Re: 32-octet
>> >>>
>> >>> We chose it because we are using SHA256 in generating the code
>> >>> challange. Having more entropy does not help us here, while having
>> >>> less octets increases the risk.
>> >>>
>> >>> Best,
>> >>>
>> >>> Nat
>> >>>
>> >>>
>> >>>
>> >>> On Tue, 17 Feb 2015 17:56:33 +0100
>> >>> Hannes Tschofenig  wrote:
>> >>>
>> >>>> Hi Nat, John, Naveen,
>> >>>>
>> >>>> thanks a lot for your work on the document.
>> >>>>
>> >>>> I still need responses to this mail to complete the shepherd
>> >>>> writeup:
>> >>>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
>> >>>>
>> >>>> I definitely need the IPR confirmation.
>> >>>>
>> >>>> It would also be helpful to have someone who implemented the
>> >>>> specification as it currently is. I asked Brian and Thorsten for
>> >>>> clarification regarding their statements that they implemented
>> >>>> earlier versions of the spec.
>> >>>>
>> >>>> As a final remark I still believe that the text regarding the
>> >>>> randomness is still a bit inconsistent. Here are two examples:
>> >>>>
>> >>>> 1) In the Security Consideration you write that "The security model
>> >>>> relies on the fact that the code verifier is not learned or
>> >>>> guessed by the attacker.  It is vitally important to adhere to
>> >>>> this principle. "
>> >>>>
>> >>>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
>> >>>> have enough entropy to make it impractical to guess the value.  It
>> >>>> is RECOMMENDED that the output of a suitable random number
>> >>>> generator be used to create a 32-octet sequence."
>> >>>>
>> >>>> There is clearly a long way from a SHOULD have enough entropy to
>> >>>> the text in the security consideration section where you ask for
>> >>>> 32 bytes entropy.
>> >>>>
>> >>>> It is also not clear why you ask for 32 bytes of entropy in
>> >>>> particular.
>> >>>>
>> >>>> Ciao
>> >>>> Hannes
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>> >
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a113f9ba2da1c0c050f5d4d31
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I tend to agree with Torsten here - similar sentiments wer=
e (maybe not well) expressed a few weeks ago: http://www.ietf.org/mail-ar=
chive/web/oauth/current/msg14155.html



On Wed, Feb 18, 2015 at 6:36 AM, =
 <torsten@lodderstedt.net> wrote:




Hi Nat,


as far as I understand, the length of at least 32 octets is justified fo=
r S256 only. So limiting the MUST to S256 would be ok (from my perspective)=
. I consider a general MUST (which also applies to plain) a to strong requi=
rement.


kind regards,
Torsten.


Am 18.02.2015 10:50, schrieb Nat Sakimura:




Is there anyone who has problems changing it to a MUST? 


On 2015=E5=B9=B42=E6=9C=8818=E6=97=A5(=E6=B0=B4)=
 at 18:48 Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:


I think that the "controlled environmen=
t" is a risky idea. I believe we
 should definitely go for a MUST.<=
br>
 On 02/18/2015 10:26 AM, Nat Sakimura wrote:
 > Hi Hannes,
=
 >
 > The reason I have put SHOULD there instead of MUST is
 &g=
t; that there may be a valid reason not to in a controlled
 > environ=
ment, and it does not interfere the interoperability.
 > The deployme=
nt may opt to use other control than entropy,
 > and SHOULD allows it=
 while MUST does not.
 >
 > Having said that, if the WG is OK w=
ith a MUST there,
 > I am fine with incorporating the proposed change=
.
 >
 > Cheers,
 >
 > Nat
 >
 >
 >=
; On Wed, 18 Feb 2015 09:43:30 +0100
 > Hannes Tschofenig <hannes.tschofenig@g=
mx.net> wrote:
 >
 >> Hi Nat,
 >>
 >&g=
t; thanks for the quick response.
 >>
 >> I was hoping to=
 see a statement like "The code verifier MUST have
 >> enough=
 entropy to make it impractical to guess the value." in the
 >&g=
t; text rather than the SHOULD. Given all the other statements in the
 &=
gt;> draft I am not sure what the should actually means. Under what
 =
>> conditions would an implementer not provide enough entropy to make=

 >> guessing impractical?
 >>
 >> Ciao
 >=
> Hannes
 >>
 >> On 02/18/2015 05:13 AM, Nat Sakimura =
wrote:
 >>> Hi Hannes,
 >>>
 >>> I here=
by confirm that I have submit the draft=C2=A0 in full conformance
 >&=
gt;> with the=C2=A0 provisions of BCP 78 and BCP 79.
 >>> >>> Re: Security Consideration (7.1) and section 4.1
 >>=
;>
 >>> The first part of the 7.1 is a non-normative prose e=
xplaining that
 >>> the implementers got to make sure that the =
code verifier is hard to
 >>> guessed or modeled. In a way, thi=
s is laying out the basic security
 >>> property requirment on =
the code verifier.
 >>>
 >>> Then, it goes onto the=
 implementation guideance that one need to
 >>> use a cryptogra=
phic random number generator instead of relying on a
 >>> rand(=
) in some language that are=C2=A0 not cryptographically random to
 >&=
gt;> generate 32-octet sequence. The same text is in 4.1 as well.
 &g=
t;>>
 >>> We did not copy "code verifier SHOULD have=
 enough entropy to make
 >>> it impractical to guess the value&=
quot; here because that looked
 >>> needlessly repeating, but i=
f you want, I have no objection in
 >>> adding it to 7.1.
 &=
gt;>>
 >>> Alternatively, in 7.1, after explaining the ra=
tionale, we can just
 >>> point to 4.1 for the control and impl=
ementation guidance.
 >>>
 >>> Re: 32-octet
 >=
;>>
 >>> We chose it because we are using SHA256 in gener=
ating the code
 >>> challange. Having more entropy does not hel=
p us here, while having
 >>> less octets increases the risk. >>>
 >>> Best,
 >>>
 >>> Nat=

 >>>
 >>>
 >>>
 >>> On Tue=
, 17 Feb 2015 17:56:33 +0100
 >>> Hannes Tschofenig <hannes.tschofenig@g=
mx.net> wrote:
 >>>
 >>>> Hi Nat, John, N=
aveen,
 >>>>
 >>>> thanks a lot for your work=
 on the document.
 >>>>
 >>>> I still need re=
sponses to this mail to complete the shepherd
 >>>> writeup:=

 >>>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
 >>>=
>
 >>>> I definitely need the IPR confirmation.
 >&=
gt;>>
 >>>> It would also be helpful to have someone w=
ho implemented the
 >>>> specification as it currently is. I=
 asked Brian and Thorsten for
 >>>> clarification regarding =
their statements that they implemented
 >>>> earlier version=
s of the spec.
 >>>>
 >>>> As a final remark =
I still believe that the text regarding the
 >>>> randomness=
 is still a bit inconsistent. Here are two examples:
 >>>> >>>> 1) In the Security Consideration you write that "T=
he security model
 >>>> relies on the fact that the code ver=
ifier is not learned or
 >>>> guessed by the attacker.=C2=A0=
 It is vitally important to adhere to
 >>>> this principle. =
"
 >>>>
 >>>> 2) In Section 4.1 you, how=
ever, write: "NOTE: code verifier SHOULD
 >>>> have eno=
ugh entropy to make it impractical to guess the value.=C2=A0 It
 >>=
;>> is RECOMMENDED that the output of a suitable random number
 &g=
t;>>> generator be used to create a 32-octet sequence."
 &=
gt;>>>
 >>>> There is clearly a long way from a SHO=
ULD have enough entropy to
 >>>> the text in the security co=
nsideration section where you ask for
 >>>> 32 bytes entropy=
.
 >>>>
 >>>> It is also not clear why you as=
k for 32 bytes of entropy in
 >>>> particular.
 >>&=
gt;>
 >>>> Ciao
 >>>> Hannes
 >>&=
gt;>
 >>>
 >>>
 >>
 >
 >
 _______________________________________________
 OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/oauth





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





=C2=A0


=C2=A0




_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--001a113f9ba2da1c0c050f5d4d31--


From nobody Wed Feb 18 06:39:02 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966381A8833 for ; Wed, 18 Feb 2015 06:39:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GapzRhL8DfeD for ; Wed, 18 Feb 2015 06:38:57 -0800 (PST)
Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172C91A87F0 for ; Wed, 18 Feb 2015 06:38:57 -0800 (PST)
Received: by pabkx10 with SMTP id kx10so1558413pab.13 for ; Wed, 18 Feb 2015 06:38:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=CTUMfmRIh256sKlZbu/27cQ+OR/JW5EGXm6EKoeXobs=; b=F5Vap0W5tOypG75AAFYhxTga/7oERdhElCEzxI5OIsHGylVQaZromaxpVuqIbOBPNg OwypNc9HRQOkaeWJWI7n9BGt0+Jf2kCHkIOPt76PagFGMcRH3I8IjI6AsKtKeOM73vNP ZQtLFC3LDVTV5fm3Hj20nub+6v3tl4Ftute5ZTNEVlHzveyZa5WxA/Bq6iCOPYRFfruO 2kJpOmNPDWMPcpzbqObH7xxDqWWbgsdAdGlC1A26TelTOGezSOfcPoXvyTiIPvCIDppv qREDF3oLAdmKKmcrX902hADXihqRuLKGR2UpEYI8rEegczhdV6RlYXqPoXyvvRMSNPab fJSg==
X-Gm-Message-State: ALoCoQnDQt58TLzMRL0RMnkRyPvhm4yfZikKHdxWbuwXNLzwllX5/fyIM0rh+QAmtqhj4h3vW4L9
X-Received: by 10.68.132.103 with SMTP id ot7mr59755848pbb.0.1424270336708; Wed, 18 Feb 2015 06:38:56 -0800 (PST)
Received: from [10.1.1.16] (75-149-33-126-SFBA.hfc.comcastbusiness.net. [75.149.33.126]) by mx.google.com with ESMTPSA id oq4sm6981970pdb.73.2015.02.18.06.38.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Feb 2015 06:38:55 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_16492D11-A58A-4929-A841-BD91884E2F3A"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: 
Date: Wed, 18 Feb 2015 06:38:43 -0800
Message-Id: <175D5D8F-05C5-4926-A44C-D01E5398E49B@ve7jtb.com>
References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp> <54E450B2.7020409@gmx.net> <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp> <54E45F22.8060902@gmx.net> 
To: Nat Sakimura 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "oauth@ietf.org" , Naveen Agarwal 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 14:39:00 -0000

--Apple-Mail=_16492D11-A58A-4929-A841-BD91884E2F3A
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_55390F6D-C23F-4936-8AEC-C2B0DBAF8E8D"


--Apple-Mail=_55390F6D-C23F-4936-8AEC-C2B0DBAF8E8D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

As I stated in my message.  I think for plain having there be a MUST at =
256 bits would be overkill. =20

For plain given it is single use like the code is we should probably =
match it to the entropy required for code.

In RFC 6749 we say
The probability of an attacker guessing generated tokens (and other
   credentials not intended for handling by end-users) MUST be less than
   or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).

So to be consistent I would make plain "MUST be between 16 and 32 =
octets=E2=80=9D

I don=E2=80=99t remember precisely , but I may be the one responsible =
for the for the 2^(-128) value for code. =20
That was a bit higher than needed if people can really only use code =
once.   However the reality is that not all AS properly revoke code =
after it is used.
That is really hard in a clustered environment.  (There is more than one =
large one so I am not picking on anyone in particular)=20

Knowing that in reality an attacker might be able to make a limited =
number attacks before a code time expires there is a fudge factor in the =
128bit code to still make it plausibly unguessable even in that case.

The same factor would apply to code_verifier other wise I would say 8 =
octets would be sufficient.

 John B.

> On Feb 18, 2015, at 1:50 AM, Nat Sakimura  =
wrote:
>=20
> Is there anyone who has problems changing it to a MUST?=20
> On 2015=E5=B9=B42=E6=9C=8818=E6=97=A5(=E6=B0=B4) at 18:48 Hannes =
Tschofenig > wrote:
> I think that the "controlled environment" is a risky idea. I believe =
we
> should definitely go for a MUST.
>=20
> On 02/18/2015 10:26 AM, Nat Sakimura wrote:
> > Hi Hannes,
> >
> > The reason I have put SHOULD there instead of MUST is
> > that there may be a valid reason not to in a controlled
> > environment, and it does not interfere the interoperability.
> > The deployment may opt to use other control than entropy,
> > and SHOULD allows it while MUST does not.
> >
> > Having said that, if the WG is OK with a MUST there,
> > I am fine with incorporating the proposed change.
> >
> > Cheers,
> >
> > Nat
> >
> >
> > On Wed, 18 Feb 2015 09:43:30 +0100
> > Hannes Tschofenig > wrote:
> >
> >> Hi Nat,
> >>
> >> thanks for the quick response.
> >>
> >> I was hoping to see a statement like "The code verifier MUST have
> >> enough entropy to make it impractical to guess the value." in the
> >> text rather than the SHOULD. Given all the other statements in the
> >> draft I am not sure what the should actually means. Under what
> >> conditions would an implementer not provide enough entropy to make
> >> guessing impractical?
> >>
> >> Ciao
> >> Hannes
> >>
> >> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> >>> Hi Hannes,
> >>>
> >>> I hereby confirm that I have submit the draft  in full conformance
> >>> with the  provisions of BCP 78 and BCP 79.
> >>>
> >>> Re: Security Consideration (7.1) and section 4.1
> >>>
> >>> The first part of the 7.1 is a non-normative prose explaining that
> >>> the implementers got to make sure that the code verifier is hard =
to
> >>> guessed or modeled. In a way, this is laying out the basic =
security
> >>> property requirment on the code verifier.
> >>>
> >>> Then, it goes onto the implementation guideance that one need to
> >>> use a cryptographic random number generator instead of relying on =
a
> >>> rand() in some language that are  not cryptographically random to
> >>> generate 32-octet sequence. The same text is in 4.1 as well.
> >>>
> >>> We did not copy "code verifier SHOULD have enough entropy to make
> >>> it impractical to guess the value" here because that looked
> >>> needlessly repeating, but if you want, I have no objection in
> >>> adding it to 7.1.
> >>>
> >>> Alternatively, in 7.1, after explaining the rationale, we can just
> >>> point to 4.1 for the control and implementation guidance.
> >>>
> >>> Re: 32-octet
> >>>
> >>> We chose it because we are using SHA256 in generating the code
> >>> challange. Having more entropy does not help us here, while having
> >>> less octets increases the risk.
> >>>
> >>> Best,
> >>>
> >>> Nat
> >>>
> >>>
> >>>
> >>> On Tue, 17 Feb 2015 17:56:33 +0100
> >>> Hannes Tschofenig > wrote:
> >>>
> >>>> Hi Nat, John, Naveen,
> >>>>
> >>>> thanks a lot for your work on the document.
> >>>>
> >>>> I still need responses to this mail to complete the shepherd
> >>>> writeup:
> >>>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html =

> >>>>
> >>>> I definitely need the IPR confirmation.
> >>>>
> >>>> It would also be helpful to have someone who implemented the
> >>>> specification as it currently is. I asked Brian and Thorsten for
> >>>> clarification regarding their statements that they implemented
> >>>> earlier versions of the spec.
> >>>>
> >>>> As a final remark I still believe that the text regarding the
> >>>> randomness is still a bit inconsistent. Here are two examples:
> >>>>
> >>>> 1) In the Security Consideration you write that "The security =
model
> >>>> relies on the fact that the code verifier is not learned or
> >>>> guessed by the attacker.  It is vitally important to adhere to
> >>>> this principle. "
> >>>>
> >>>> 2) In Section 4.1 you, however, write: "NOTE: code verifier =
SHOULD
> >>>> have enough entropy to make it impractical to guess the value.  =
It
> >>>> is RECOMMENDED that the output of a suitable random number
> >>>> generator be used to create a 32-octet sequence."
> >>>>
> >>>> There is clearly a long way from a SHOULD have enough entropy to
> >>>> the text in the security consideration section where you ask for
> >>>> 32 bytes entropy.
> >>>>
> >>>> It is also not clear why you ask for 32 bytes of entropy in
> >>>> particular.
> >>>>
> >>>> Ciao
> >>>> Hannes
> >>>>
> >>>
> >>>
> >>
> >
> >
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_55390F6D-C23F-4936-8AEC-C2B0DBAF8E8D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

As I stated in my message.  I think for plain having =
there be a MUST at 256 bits would be overkill.  

For plain given it is single use like =
the code is we should probably match it to the entropy required for =
code.

In RFC =
6749 we say
The probability of an attacker guessing =
generated tokens (and other
   credentials not intended for handling by end-users) MUST be less than
   or equal to 2^(-128) and SHOULD be less than or equal to =
2^(-160).

So =
to be consistent I would make plain "MUST be between 16 and 32 =
octets=E2=80=9D

I don=E2=80=99t remember precisely , but I may be the one =
responsible for the for the 2^(-128) value for code.  
That was a bit higher than needed if people can really only =
use code once.   However the reality is that not all AS properly =
revoke code after it is used.
That is really hard =
in a clustered environment.  (There is more than one large one so I =
am not picking on anyone in particular) 

Knowing that in reality an attacker =
might be able to make a limited number attacks before a code time =
expires there is a fudge factor in the 128bit code to still make it =
plausibly unguessable even in that case.

The same factor would apply to =
code_verifier other wise I would say 8 octets would be =
sufficient.

 John B.

On Feb 18, 2015, at 1:50 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:

Is there anyone who =
has problems changing it to a MUST? 
On 2015=E5=B9=B42=E6=9C=8818=E6=97=A5(=E6=B0=B4) =
at 18:48 Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
I think that the =
"controlled environment" is a risky idea. I believe we

should definitely go for a MUST.



On 02/18/2015 10:26 AM, Nat Sakimura wrote:

> Hi Hannes,

>

> The reason I have put SHOULD there instead of MUST is

> that there may be a valid reason not to in a controlled

> environment, and it does not interfere the interoperability.

> The deployment may opt to use other control than entropy,

> and SHOULD allows it while MUST does not.

>

> Having said that, if the WG is OK with a MUST there,

> I am fine with incorporating the proposed change.

>

> Cheers,

>

> Nat

>

>

> On Wed, 18 Feb 2015 09:43:30 +0100

> Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>

>> Hi Nat,

>>

>> thanks for the quick response.

>>

>> I was hoping to see a statement like "The code verifier MUST =
have

>> enough entropy to make it impractical to guess the value." in =
the

>> text rather than the SHOULD. Given all the other statements in =
the

>> draft I am not sure what the should actually means. Under =
what

>> conditions would an implementer not provide enough entropy to =
make

>> guessing impractical?

>>

>> Ciao

>> Hannes

>>

>> On 02/18/2015 05:13 AM, Nat Sakimura wrote:

>>> Hi Hannes,

>>>

>>> I hereby confirm that I have submit the draft  in full =
conformance

>>> with the  provisions of BCP 78 and BCP 79.

>>>

>>> Re: Security Consideration (7.1) and section 4.1

>>>

>>> The first part of the 7.1 is a non-normative prose =
explaining that

>>> the implementers got to make sure that the code verifier is =
hard to

>>> guessed or modeled. In a way, this is laying out the basic =
security

>>> property requirment on the code verifier.

>>>

>>> Then, it goes onto the implementation guideance that one =
need to

>>> use a cryptographic random number generator instead of =
relying on a

>>> rand() in some language that are  not =
cryptographically random to

>>> generate 32-octet sequence. The same text is in 4.1 as =
well.

>>>

>>> We did not copy "code verifier SHOULD have enough entropy =
to make

>>> it impractical to guess the value" here because that =
looked

>>> needlessly repeating, but if you want, I have no objection =
in

>>> adding it to 7.1.

>>>

>>> Alternatively, in 7.1, after explaining the rationale, we =
can just

>>> point to 4.1 for the control and implementation =
guidance.

>>>

>>> Re: 32-octet

>>>

>>> We chose it because we are using SHA256 in generating the =
code

>>> challange. Having more entropy does not help us here, while =
having

>>> less octets increases the risk.

>>>

>>> Best,

>>>

>>> Nat

>>>

>>>

>>>

>>> On Tue, 17 Feb 2015 17:56:33 +0100

>>> Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>>>

>>>> Hi Nat, John, Naveen,

>>>>

>>>> thanks a lot for your work on the document.

>>>>

>>>> I still need responses to this mail to complete the =
shepherd

>>>> writeup:

>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html

>>>>

>>>> I definitely need the IPR confirmation.

>>>>

>>>> It would also be helpful to have someone who =
implemented the

>>>> specification as it currently is. I asked Brian and =
Thorsten for

>>>> clarification regarding their statements that they =
implemented

>>>> earlier versions of the spec.

>>>>

>>>> As a final remark I still believe that the text =
regarding the

>>>> randomness is still a bit inconsistent. Here are two =
examples:

>>>>

>>>> 1) In the Security Consideration you write that "The =
security model

>>>> relies on the fact that the code verifier is not =
learned or

>>>> guessed by the attacker.  It is vitally important =
to adhere to

>>>> this principle. "

>>>>

>>>> 2) In Section 4.1 you, however, write: "NOTE: code =
verifier SHOULD

>>>> have enough entropy to make it impractical to guess the =
value.  It

>>>> is RECOMMENDED that the output of a suitable random =
number

>>>> generator be used to create a 32-octet sequence."

>>>>

>>>> There is clearly a long way from a SHOULD have enough =
entropy to

>>>> the text in the security consideration section where =
you ask for

>>>> 32 bytes entropy.

>>>>

>>>> It is also not clear why you ask for 32 bytes of =
entropy in

>>>> particular.

>>>>

>>>> Ciao

>>>> Hannes

>>>>

>>>

>>>

>>

>

>



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



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

=

--Apple-Mail=_55390F6D-C23F-4936-8AEC-C2B0DBAF8E8D--

--Apple-Mail=_16492D11-A58A-4929-A841-BD91884E2F3A
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMTgxNDM4NDRaMCMGCSqGSIb3DQEJBDEWBBSyVIDdWW1UgYm3c22j4hnN
3c5+gjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBBaARJ0aHFePrKrvLMO9trsiqD+U2QnFuC5kKvcjlpX75Rl2p22GKI
alb9kDYSI98w/l6sknkUhq4wFx7LghI5NizYCax7E+dujvSRnyImZbX0y/3g9w1EQV+4N3E57FGD
ZZB6L0a9LKZB2PvJI44PPLSRf4rsvu0hkjDNocRvmgSDFOIKS3qe2yVQHQpJmS56KjOxa5ppR62w
5lJJe1l5/3hR8gYMCrySKsjNb9R+nx4qjoSPzBUcHZsAhOJ9PZDw0FMHJthoY8AY0+BX5rkv4SgI
irpzPo34JNlCYksmEgURrJ3mT2BqGZRR4uamLC2dhnJnjiYPvsVAFEh81oWEAAAAAAAA
--Apple-Mail=_16492D11-A58A-4929-A841-BD91884E2F3A--


From nobody Wed Feb 18 06:46:20 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CED1A8992 for ; Wed, 18 Feb 2015 06:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w9KgAUbdPd5 for ; Wed, 18 Feb 2015 06:46:10 -0800 (PST)
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4691E1A87D7 for ; Wed, 18 Feb 2015 06:46:09 -0800 (PST)
Received: by labgq15 with SMTP id gq15so1575531lab.3 for ; Wed, 18 Feb 2015 06:46:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YWe2RUDtK+/vCrC3HB3kuT5ZjqHGnkVNMGyci775TEI=; b=avYDMAmCSaZdPKu19ttZdHaJea4wvohrWIve52biN0Vgwog4ZkoNTxcict18RZZ8xO Hc5BqYPG8gfeW7TBrAzX3yum8Xnvterg1AQQs/fP9VxEy58bqWVgrRX9CRjUfcx1uaFU Ym9g8bkyxxBetCUT+37TyJe2Y7CFukscgEcTJoWgq3WwY74Q0CBxu87r1ixLZFDai2zT Ytzyxr4QK5KElCvUQPrS62PZLoUxB0gWp5QlFcOMr65fxsqr5fmgCc3DdBtdiZyTa9f/ fNgAHyKz763azsCJGwc/HL+brZEPr2WzzpGMBZ/9ta1+v/QX6cu5ThJi1Mq/8L29Sk3F cq9Q==
MIME-Version: 1.0
X-Received: by 10.112.90.193 with SMTP id by1mr26508404lbb.113.1424270767709;  Wed, 18 Feb 2015 06:46:07 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Wed, 18 Feb 2015 06:46:07 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>
Date: Wed, 18 Feb 2015 09:46:07 -0500
Message-ID: 
From: Kathleen Moriarty 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=001a1133ae122c6450050f5de1c7
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 14:46:19 -0000

--001a1133ae122c6450050f5de1c7
Content-Type: text/plain; charset=UTF-8

Hi,


On Mon, Feb 16, 2015 at 6:42 PM, Mike Jones 
wrote:

> A few responses and comments are inline below...
>
> > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
> > Sent: Thursday, February 12, 2015 11:47 AM
> > To: Justin Richer
> > Cc: oauth@ietf.org
> > Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
> >
> >
> > Phil
> >
> > @independentid
> > www.independentid.com
> > phil.hunt@oracle.com
> >
> > On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
> >
> > Kathleen, thanks for the review. Responses inline, though I'm going to
> let the other authors talk about their sections (deployment org, software
> version, etc) directly.
>

Thanks for the quick responses and sorry about my delay, it's a busy week!


> >
> > On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
> > Thank you for your work on this draft and sorry for the delay in my
> review.  Before we progress to IETF last call, I'd like to see what we can
> resolve from the list below.   I am looking at the IPR issues to see if we
> can resolve the outstanding questions as well.
> >
> > The Shepherd report says the following:
> >    The document shepherd has raised concerns regarding the fuzzy
> description
> >    of the actors (deployment organization, software API publisher, client
> >    developer) and their impact on the protocol execution. The working
> >    group did not seem to worry about these aspects though.
> >
> > I can see the point after reading the draft.  The interactions are
> written much more clearly in the security considerations section than where
> the flows are described.  Can something be done to address these concerns?
> >
> > Section 1.2
> > Deployment Organization definition:
> > I highly recommend replacing the phrase "simple cloud deployment" with a
> description that accurately reflects what is intended.  If that's within a
> single service provider's network, a single data center, or a single hosted
> data center, I think it would be more clear.
> >
> > Section 1.2 nit:
> > Add the word "be" into the following term definition after "may":
> >   Software API Publisher
> >       The organization that defines a particular web accessible API that
> >       may deployed in one or more deployment environments.
> >
> > [deferred to original author of this text Phil et. al for better wording]
> >
> > [Phil] Agreed with Kathleen's suggestion.
>
Thanks!

>
> I also agree that the wording of the definitions could be clarified.
> Justin, do you want to take a first pass at this or would you like to take
> lead on this, Phil?
>
> > Section 2:
> >
> > Why isn't a more secure option offered and set as the default for
> authentication types? I know I've asked this before and the answer was just
> that you can add something to the registry, but setting HTTP Basic as the
> default seems like a really bad choice. HOBA is on it's way to becoming an
> RFC from the HTTPAuth working group.  HTTPAuth also has an updated version
> of Basic that is in IETF last call, but I know you are pointing to the
> OAuth 2.0 document, so it would be that document that gets updated and not
> this draft.  The new version of HTTP Basic fixes some internationalization
> problems and spells out the security issues much more clearly, so it
> probably doesn't matter too much to update the reference, but maybe makes
> it more clear that basic is not a secure form of authentication.
> >
> > Can you provide some justification as to why this is okay to set basic
> as the default and add that to the draft?  Section 2.3.1 of OAuth 2.0 just
> says this MUST be implemented, but that any HTTP schemes can be used.  Why
> not register another method and use that instead as the default?  You could
> use digest and there is library support.  It's not a great answer, but
> slightly better than passwords with basic.  You could register HOBA and use
> that instead, the only downside is limited library support at the moment.
> >
> > It was our intent to document the methods already defined for use with
> OAuth and provide a registration mechanism for distinguishing between them,
> not to create new client authentication mechanisms. Digest and HOBA simply
> aren't defined for use with OAuth clients yet. It would be simple to do:
> put the client id in the "username" field and the client secret in the
> "password" field of both algorithms. However, I don't believe it's a good
> idea to conflate those two goals in a single specification. We actually had
> other, more secure definitions in an earlier draft of this document (using
> a JWT signed with a private key or a JWT signed with a shared key,
> specifically), but those were removed in order to focus on solving just the
> client registration problem. I agree with that decision of the WG.
> >
> > As other methods of client authentication are defined in the OAuth
> ecosystem, they can register as valid values in the registry. I think it
> would be a valuable output of this WG to define other client authentication
> mechanisms as a separate draft or an eventual update to RFC6749 (or both?).
>

A separate draft is fine and I'd like the WG to think about what more
secure options for authentication would be best to add in that draft and
into the registry.  With the popularity of Oauth, I think we could and
should be creating better options.


>
> HTTP Basic is set to the default because that's the default in RFC 6749
> and this specification is about registering clients for use with RFC 6749.
> Trying to change the RFC 6749 default really isn't within the scope of this
> work.  (If that's done, it should probably be done in an http6749-bis
> spec.)  However, the spec does define a registry that new methods like HOBA
> can be registered in when people want to use them.  (And if HOBA finishes
> before Dynamic Registration, I'm fine adding a registry entry for it in
> this spec.)
>
> Yep, I get this and stated I understood why this was the case in my
original message. I suggested HOBA because it is already in the RFC editor
queue, approved by the IESG.  The WG should discuss this and see how they
want to proceed.

If you're interested in the client_secret_jwt and private_key_jwt client
> authentication methods that Justin alluded to, these are defined in Section
> 9 of OpenID Connect Core
> http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication.
>

I'll take a look, thanks.

>
> In relation to your internationalization comments Kathleen, note that
> Section 2.3.1 of RFC 6749 explicitly provides a mechanism for encoding
> international strings for use with HTTP Basic.  This was added under the
> supervision of Julian Reschke, I believe as a result of his WGLC comments.
> So whether this is the same as what the new version of HTTP Basic does or
> not, OAuth 2.0 already does provide a standard way to use internationalized
> strings with HTTP Basic for OAuth client authentication.
>
The new version of Basic cleans up Internationalization concerns and adds
text to say how bad the security problems of basic are.  That's all I was
saying, I was not asking for you to update anything in this draft except to
see if the updated version of HTTP Basic should be used.  It's backwards
compatible and still horribly insecure, not to worry.  It's on this week's
teelchat, so it is ahead of this draft in the queue.


>
> > Section 2: Contacts:
> >
> > I noticed privacy is not dealt with until you get to the security
> considerations section.  I'd prefer to see it with the definition, stating
> the address should be a general help address at the domain rather than
> directly to an identifiable individual.  It may be good to set a default
> for what this should be for consistency or give an example (think back to
> abuse@domain.com)?
> >
> > The problem that I see with putting it inside the definition is that it
> makes the definition text very long, as the definition sits in a list of
> other metadata items. We could add a forward pointer and an example easily
> enough, though. Or we could move the privacy considerations section up as a
> subsection here, though I don't know if that runs afoul of the RFC style
> guidelines for this new section.
>

I don't care about the length argument, I think someone else else had a
more reasonable explanation of why this should be left out and I was okay
with that.  At least a pointer would be good to the privacy section so
folks know to look at it.  I had the questions as soon as I read this text
and had to wait until the very end to see an answer, it would be good for
folks who don't know this is an issue to have the pointer.

>
> >
> >
> > Software_id and software_version:
> > Are there any guidelines as to how these should be represented?  There
> are several specifications on software_id (and platform).  Does consistency
> here matter or is this just meant to be human readable?
> > Section 2.2 specifies some metadata values that are to be human
> readable, should the above be in the list?  I would expect this list to be
> comprehensive for clarity, rather than just examples since there aren't too
> many defined here.
> >
> >
> > [mostly deferred to Phil et. al, but note that software_id and
> software_version are not intended to be human readable and don't need the
> multi-language support]
>
> We should probably say that in the draft then.
>

Are there specific well-known formats that should be used?  If it's machine
parseable, how does one know which format is expected?  If it's just the
label sent by the application, then expect variance and issues as each
version might not be in a consistent format.  If it is a formatted
description like SWID, then that should be stated or if a mix of formats
are fine with no preference.


>
> > [Phil]
> > I've added some more explanatory text. Note...some of this may be better
> put elsewhere.
> >
> > As to whether the values are human readable, I have no opinion. What
> matters most is unique matching.
> >
> >    software_id
> >       A unique identifier (e.g. UUID) assigned by the developer or
> software publisher
> >       used by registration endpoints to identify client software to be
> dynamically registered.
> >       Unlike "client_id", which is issued by the authorization server
> and varies between
> >       instances of software, the "software_id" SHOULD remain the same
> for all client software
> >       instances. The "software_id" SHOULD remain the same across
> multiple software updates
> >       or versions.
>
> I'd revise the last two sentences of this as follows:
>
>       Unlike "client_id", which is issued by the authorization server and
> may vary between
>       instances of a piece of software, the "software_id" SHOULD remain
> the same for all instances
>       of a piece of software. The "software_id" SHOULD remain the same
> across multiple software updates
>       or versions of the same piece of software.
>
> > software_version
> >       A version identifier for the software identified by
> "software_id".  The
> >       value of this field is a string that is intended to be compared
> >       using string equality matching. Unlike "software_id", the value of
> the
> >       "software_version" SHOULD change on any update to the client
> >       software. A service provider MAY use "software_id" and
> "software_version" to
> >       recognize approved software and version combinations approved for
> dynamic registration.
> >
> > Let me know if you want more background.
> >
> >
> > Section 3.2.1 & Privacy section
> > For client_name and client_id and associated information, how is user
> privacy affected and what can be done to mitigate concerns?  The definition
> should state that this is a public value and that it is specific to the
> software, not a person.  You have to get to the security consideration
> section before that is clear.  References are fine too, but some more
> information is needed in the privacy section.  I'm left with a bunch of
> questions:
> >   Can the client_name and client_id be tied to a person?
> > The client name is common across all copies of the software (usually),
> so no worries there. The ID represents an individual piece of software, not
> a person, though if that person is the sole user of the instance of
> software then I believe you're right that there are some privacy
> considerations that we should point that out. However, dynamic registration
> can actually help mitigate this as well, since in the normal case (with no
> software statements) there's no way to correlate instances of clients with
> each other.
>

OK, can someone propose text?


> >
> >   Can the person be tracked by this?
> >   Can other information be gathered about a system (and it's user)
> during this process?
> > Nothing gathered about the user during registration, as this happens in
> the back channel outside the user's purview.
>

OK, please make that clear in the privacy considerations section.

> >
> >   The information is used to dynamically register clients, what is
> logged?
> >   What data is aggregated?
> >   What can you tell about a client (time, location, travel, other
> personal details that may be considered sensitive)?  I don't think this was
> covered in the OAuth 2.0 RFC.
> >   How is this addressed at the authorization server and other points?
> >   The Security considerations talks about client_id as being short
> lived, so they expire, but are these event logged or is that prohibited?
> >
> > Many of these questions seem to be completely dependent on the
> implementation of the authorization server, and I'm not really sure how (or
> if) to address them in this draft. Any suggestions would be welcomed here.
> >
> > The client_id *could* be short lived, but they usually aren't. I don't
> see any particular logging or tracking concerns using a dynamic OAuth
> client above using any other piece of software, ever. As such, I don't
> think it requires special calling out here.
>

Help me understand why there should not be text that shows this is not an
issue or please propose some text.  This is bound to come up in IESG
reviews if not addressed up front.

> >
> >
> >
> > 5. Security considerations
> > The first paragraph is a repeat of text.  Can this just be in one place
> and use a pointer to the full text?  I like the requirement, but reading it
> once is enough.
> >
> > I think it was less onerous of a repeat when both simply said "use TLS",
> so some refactoring after the expansion of the text makes sense to me.
> Would it be better to have it upfront in the endpoint definition, or in the
> security considerations?
>

I'd put it int he security considerations and just have a pointer from the
earlier text so references are all in one place.

Thank you,
Kathleen

>
> Justin, do you want to make specific rewording proposals for this and the
> other editorial issues that were identified?
>
> > --
> >
> > Best regards,
> > Kathleen
> >
> > Thanks again for your review!
> >
> >  -- Justin
>
>                                 Thanks all,
>                                 -- Mike
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 

Best regards,
Kathleen

--001a1133ae122c6450050f5de1c7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,


On Mon, Feb 16, 2015 at 6:42 PM, Mike Jones <M=
ichael.Jones@microsoft.com> wrote:
A few responses and comments are inline below...



> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt

> Sent: Thursday, February 12, 2015 11:47 AM

> To: Justin Richer

> Cc: oauth@ietf.org=


> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

>

>

> Phil

>

> @independentid

> www.indepen=
dentid.com

> phil.hunt@or=
acle.com

>

> On Feb 11, 2015, at 8:31 PM, Justin Richer <jricher@mit.edu> wrote:

>

> Kathleen, thanks for the review. Responses inline, though I'm goin=
g to let the other authors talk about their sections (deployment org, softw=
are version, etc) directly.

Than=
ks for the quick responses and sorry about my delay, it's a busy week!<=
/div>
=C2=A0

>

> On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:

> Thank you for your work on this draft and sorry for the delay in my re=
view.=C2=A0 Before we progress to IETF last call, I'd like to see what =
we can resolve from the list below.=C2=A0 =C2=A0I am looking at the IPR iss=
ues to see if we can resolve the outstanding questions as well.

>

> The Shepherd report says the following:

>=C2=A0 =C2=A0 The document shepherd has raised concerns regarding the f=
uzzy description

>=C2=A0 =C2=A0 of the actors (deployment organization, software API publ=
isher, client

>=C2=A0 =C2=A0 developer) and their impact on the protocol execution. Th=
e working

>=C2=A0 =C2=A0 group did not seem to worry about these aspects though.
>

> I can see the point after reading the draft.=C2=A0 The interactions ar=
e written much more clearly in the security considerations section than whe=
re the flows are described.=C2=A0 Can something be done to address these co=
ncerns?

>

> Section 1.2

> Deployment Organization definition:

> I highly recommend replacing the phrase "simple cloud deployment&=
quot; with a description that accurately reflects what is intended.=C2=A0 I=
f that's within a single service provider's network, a single data =
center, or a single hosted data center, I think it would be more clear.

>

> Section 1.2 nit:

> Add the word "be" into the following term definition after &=
quot;may":

>=C2=A0 =C2=A0Software API Publisher

>=C2=A0 =C2=A0 =C2=A0 =C2=A0The organization that defines a particular w=
eb accessible API that

>=C2=A0 =C2=A0 =C2=A0 =C2=A0may deployed in one or more deployment envir=
onments.

>

> [deferred to original author of this text Phil et. al for better wordi=
ng]

>

> [Phil] Agreed with Kathleen's suggestion.
<=
div>Thanks!=C2=A0



I also agree that the wording of the definitions could be clarified.=
=C2=A0 Justin, do you want to take a first pass at this or would you like t=
o take lead on this, Phil?



> Section 2:

>

> Why isn't a more secure option offered and set as the default for =
authentication types? I know I've asked this before and the answer was =
just that you can add something to the registry, but setting HTTP Basic as =
the default seems like a really bad choice. HOBA is on it's way to beco=
ming an RFC from the HTTPAuth working group.=C2=A0 HTTPAuth also has an upd=
ated version of Basic that is in IETF last call, but I know you are pointin=
g to the OAuth 2.0 document, so it would be that document that gets updated=
 and not this draft.=C2=A0 The new version of HTTP Basic fixes some interna=
tionalization problems and spells out the security issues much more clearly=
, so it probably doesn't matter too much to update the reference, but m=
aybe makes it more clear that basic is not a secure form of authentication.=


>

> Can you provide some justification as to why this is okay to set basic=
 as the default and add that to the draft?=C2=A0 Section 2.3.1 of OAuth 2.0=
 just says this MUST be implemented, but that any HTTP schemes can be used.=
=C2=A0 Why not register another method and use that instead as the default?=
=C2=A0 You could use digest and there is library support.=C2=A0 It's no=
t a great answer, but slightly better than passwords with basic.=C2=A0 You =
could register HOBA and use that instead, the only downside is limited libr=
ary support at the moment.

>

> It was our intent to document the methods already defined for use with=
 OAuth and provide a registration mechanism for distinguishing between them=
, not to create new client authentication mechanisms. Digest and HOBA simpl=
y aren't defined for use with OAuth clients yet. It would be simple to =
do: put the client id in the "username" field and the client secr=
et in the "password" field of both algorithms. However, I don'=
;t believe it's a good idea to conflate those two goals in a single spe=
cification. We actually had other, more secure definitions in an earlier dr=
aft of this document (using a JWT signed with a private key or a JWT signed=
 with a shared key, specifically), but those were removed in order to focus=
 on solving just the client registration problem. I agree with that decisio=
n of the WG.

>

> As other methods of client authentication are defined in the OAuth eco=
system, they can register as valid values in the registry. I think it would=
 be a valuable output of this WG to define other client authentication mech=
anisms as a separate draft or an eventual update to RFC6749 (or both?).
=


A separate draft is fine and I'=
d like the WG to think about what more secure options for authentication wo=
uld be best to add in that draft and into the registry.=C2=A0 With the popu=
larity of Oauth, I think we could and should be creating better options.
=C2=A0



HTTP Basic is set to the default because that's the default in R=
FC 6749 and this specification is about registering clients for use with RF=
C 6749.=C2=A0 Trying to change the RFC 6749 default really isn't within=
 the scope of this work.=C2=A0 (If that's done, it should probably be d=
one in an http6749-bis spec.)=C2=A0 However, the spec does define a registr=
y that new methods like HOBA can be registered in when people want to use t=
hem.=C2=A0 (And if HOBA finishes before Dynamic Registration, I'm fine =
adding a registry entry for it in this spec.)


Yep, I get this and stated I understood why this was =
the case in my original message. I suggested HOBA because it is already in =
the RFC editor queue, approved by the IESG.=C2=A0 The WG should discuss thi=
s and see how they want to proceed.


If you're interested in the client_secret_jwt and private_key_jwt clien=
t authentication methods that Justin alluded to, these are defined in Secti=
on 9 of OpenID Connect Core http://openid.net/=
specs/openid-connect-core-1_0.html#ClientAuthentication.

I'll take a look, thanks.=C2=A0



In relation to your internationalization comments Kathleen, note that Secti=
on 2.3.1 of RFC 6749 explicitly provides a mechanism for encoding internati=
onal strings for use with HTTP Basic.=C2=A0 This was added under the superv=
ision of Julian Reschke, I believe as a result of his WGLC comments.=C2=A0 =
So whether this is the same as what the new version of HTTP Basic does or n=
ot, OAuth 2.0 already does provide a standard way to use internationalized =
strings with HTTP Basic for OAuth client authentication.
The new version of Basic cleans up Internationalization concerns and add=
s text to say how bad the security problems of basic are.=C2=A0 That's =
all I was saying, I was not asking for you to update anything in this draft=
 except to see if the updated version of HTTP Basic should be used.=C2=A0 I=
t's backwards compatible and still horribly insecure, not to worry.=C2=
=A0 It's on this week's teelchat, so it is ahead of this draft in t=
he queue.
=C2=A0



> Section 2: Contacts:

>

> I noticed privacy is not dealt with until you get to the security cons=
iderations section.=C2=A0 I'd prefer to see it with the definition, sta=
ting the address should be a general help address at the domain rather than=
 directly to an identifiable individual.=C2=A0 It may be good to set a defa=
ult for what this should be for consistency or give an example (think back =
to abuse@domain.com)?

>

> The problem that I see with putting it inside the definition is that i=
t makes the definition text very long, as the definition sits in a list of =
other metadata items. We could add a forward pointer and an example easily =
enough, though. Or we could move the privacy considerations section up as a=
 subsection here, though I don't know if that runs afoul of the RFC sty=
le guidelines for this new section.

<=
div>I don't care about the length argument, I think someone else else h=
ad a more reasonable explanation of why this should be left out and I was o=
kay with that.=C2=A0 At least a pointer would be good to the privacy sectio=
n so folks know to look at it.=C2=A0 I had the questions as soon as I read =
this text and had to wait until the very end to see an answer, it would be =
good for folks who don't know this is an issue to have the pointer.


>

>

>

> Software_id and software_version:

> Are there any guidelines as to how these should be represented?=C2=A0 =
There are several specifications on software_id (and platform).=C2=A0 Does =
consistency here matter or is this just meant to be human readable?

> Section 2.2 specifies some metadata values that are to be human readab=
le, should the above be in the list?=C2=A0 I would expect this list to be c=
omprehensive for clarity, rather than just examples since there aren't =
too many defined here.

>

>

> [mostly deferred to Phil et. al, but note that software_id and softwar=
e_version are not intended to be human readable and don't need the mult=
i-language support]



We should probably say that in the draft then.
=

Are there specific well-known formats that should be used?=
=C2=A0 If it's machine parseable, how does one know which format is exp=
ected?=C2=A0 If it's just the label sent by the application, then expec=
t variance and issues as each version might not be in a consistent format.=
=C2=A0 If it is a formatted description like SWID, then that should be stat=
ed or if a mix of formats are fine with no preference.
=C2=A0



> [Phil]

> I've added some more explanatory text. Note...some of this may be =
better put elsewhere.

>

> As to whether the values are human readable, I have no opinion. What m=
atters most is unique matching.

>

>=C2=A0 =C2=A0 software_id

>=C2=A0 =C2=A0 =C2=A0 =C2=A0A unique identifier (e.g. UUID) assigned by =
the developer or software publisher

>=C2=A0 =C2=A0 =C2=A0 =C2=A0used by registration endpoints to identify c=
lient software to be dynamically registered.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Unlike "client_id", which is issue=
d by the authorization server and varies between

>=C2=A0 =C2=A0 =C2=A0 =C2=A0instances of software, the "software_id=
" SHOULD remain the same for all client software

>=C2=A0 =C2=A0 =C2=A0 =C2=A0instances. The "software_id" SHOUL=
D remain the same across multiple software updates

>=C2=A0 =C2=A0 =C2=A0 =C2=A0or versions.



I'd revise the last two sentences of this as follows:



=C2=A0 =C2=A0 =C2=A0 Unlike "client_id", which is issued by the a=
uthorization server and may vary between

=C2=A0 =C2=A0 =C2=A0 instances of a piece of software, the "software_i=
d" SHOULD remain the same for all instances

=C2=A0 =C2=A0 =C2=A0 of a piece of software. The "software_id" SH=
OULD remain the same across multiple software updates

=C2=A0 =C2=A0 =C2=A0 or versions of the same piece of software.




> software_version

>=C2=A0 =C2=A0 =C2=A0 =C2=A0A version identifier for the software identi=
fied by "software_id".=C2=A0 The

>=C2=A0 =C2=A0 =C2=A0 =C2=A0value of this field is a string that is inte=
nded to be compared

>=C2=A0 =C2=A0 =C2=A0 =C2=A0using string equality matching. Unlike "=
;software_id", the value of the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0"software_version" SHOULD change o=
n any update to the client

>=C2=A0 =C2=A0 =C2=A0 =C2=A0software. A service provider MAY use "s=
oftware_id" and "software_version" to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0recognize approved software and version comb=
inations approved for dynamic registration.

>

> Let me know if you want more background.

>

>

> Section 3.2.1 & Privacy section

> For client_name and client_id and associated information, how is user =
privacy affected and what can be done to mitigate concerns?=C2=A0 The defin=
ition should state that this is a public value and that it is specific to t=
he software, not a person.=C2=A0 You have to get to the security considerat=
ion section before that is clear.=C2=A0 References are fine too, but some m=
ore information is needed in the privacy section.=C2=A0 I'm left with a=
 bunch of questions:

>=C2=A0 =C2=A0Can the client_name and client_id be tied to a person?

> The client name is common across all copies of the software (usually),=
 so no worries there. The ID represents an individual piece of software, no=
t a person, though if that person is the sole user of the instance of softw=
are then I believe you're right that there are some privacy considerati=
ons that we should point that out. However, dynamic registration can actual=
ly help mitigate this as well, since in the normal case (with no software s=
tatements) there's no way to correlate instances of clients with each o=
ther.

OK, can someone propo=
se text?
=C2=A0

>

>=C2=A0 =C2=A0Can the person be tracked by this?

>=C2=A0 =C2=A0Can other information be gathered about a system (and it&#=
39;s user) during this process?

> Nothing gathered about the user during registration, as this happens i=
n the back channel outside the user's purview.

OK, please make that clear in the privacy considera=
tions section.=C2=A0

>

>=C2=A0 =C2=A0The information is used to dynamically register clients, w=
hat is logged?

>=C2=A0 =C2=A0What data is aggregated?

>=C2=A0 =C2=A0What can you tell about a client (time, location, travel, =
other personal details that may be considered sensitive)?=C2=A0 I don't=
 think this was covered in the OAuth 2.0 RFC.

>=C2=A0 =C2=A0How is this addressed at the authorization server and othe=
r points?

>=C2=A0 =C2=A0The Security considerations talks about client_id as being=
 short lived, so they expire, but are these event logged or is that prohibi=
ted?

>

> Many of these questions seem to be completely dependent on the impleme=
ntation of the authorization server, and I'm not really sure how (or if=
) to address them in this draft. Any suggestions would be welcomed here.
>

> The client_id *could* be short lived, but they usually aren't. I d=
on't see any particular logging or tracking concerns using a dynamic OA=
uth client above using any other piece of software, ever. As such, I don=
9;t think it requires special calling out here.

Help me understand why there should not be text that s=
hows this is not an issue or please propose some text.=C2=A0 This is bound =
to come up in IESG reviews if not addressed up front.=C2=A0

>

>

>

> 5. Security considerations

> The first paragraph is a repeat of text.=C2=A0 Can this just be in one=
 place and use a pointer to the full text?=C2=A0 I like the requirement, bu=
t reading it once is enough.

>

> I think it was less onerous of a repeat when both simply said "us=
e TLS", so some refactoring after the expansion of the text makes sens=
e to me. Would it be better to have it upfront in the endpoint definition, =
or in the security considerations?



-- 
=


Best regards,
Kathleen
=





--001a1133ae122c6450050f5de1c7--


From nobody Wed Feb 18 07:08:21 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578211A893E for ; Wed, 18 Feb 2015 07:08:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5KgtGZheiQM for ; Wed, 18 Feb 2015 07:08:16 -0800 (PST)
Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E831A923D for ; Wed, 18 Feb 2015 07:08:15 -0800 (PST)
Received: by pdjz10 with SMTP id z10so1748767pdj.0 for ; Wed, 18 Feb 2015 07:08:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1g9ba2c3VEyzPtkc+bHty54xHwn8YKh4NDbNGymt6Ms=; b=JAwMCMLFvSn/F+DBOR3Sjkzo+d0+6dQBESGYF0FuigaCWcm188QOqoaMfXY3qQCJwN FyhNgXtRClzPz2VyJJBSckWggAR0DgBm0Kvs7/8+EWOADDPyF4Qeto9J3jzHB4GWkkCG 70nVKc7dKg44rtWHQLMiIBr53u8EN1tcXzPHylH94PGLvusZKt9+NP0QQfGkFE/m219m HgYV4aRKURHJWtaQhI9MovXEerlR3siE0dYOHaQTrJ+tOIBGjrktXttAEW1JAAEuVe2E CKE+aR7KBTyAs666zkZPboSXYUnOichdM83G8P0M1DeDZrL1EY99fEt+czjtNAL4rovB U7Hw==
X-Gm-Message-State: ALoCoQmunOTNq3Ure9vlLF6C1PIOR2iF+V8MFv47qg+n1JY5/4xsWWOVRLDwwDO1kiO3LP6Yw2B0
X-Received: by 10.70.61.130 with SMTP id p2mr59987645pdr.0.1424272094675; Wed, 18 Feb 2015 07:08:14 -0800 (PST)
Received: from [10.1.1.16] (75-149-33-126-SFBA.hfc.comcastbusiness.net. [75.149.33.126]) by mx.google.com with ESMTPSA id gi6sm20826744pbd.93.2015.02.18.07.08.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Feb 2015 07:08:13 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_12E6CA57-8905-4D03-A769-924BF9CE8B6E"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: 
Date: Wed, 18 Feb 2015 07:07:57 -0800
Message-Id: <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com> 
To: Kathleen Moriarty 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 15:08:19 -0000

--Apple-Mail=_12E6CA57-8905-4D03-A769-924BF9CE8B6E
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B51C742A-3EF2-49DB-9B7E-D195D0ECEE5B"


--Apple-Mail=_B51C742A-3EF2-49DB-9B7E-D195D0ECEE5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

snip
> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty =
 wrote:
>=20
> > The client_id *could* be short lived, but they usually aren't. I =
don't see any particular logging or tracking concerns using a dynamic =
OAuth client above using any other piece of software, ever. As such, I =
don't think it requires special calling out here.
>=20
> Help me understand why there should not be text that shows this is not =
an issue or please propose some text.  This is bound to come up in IESG =
reviews if not addressed up front.=20
>=20

The client_id is used to communicate to the Authorization server to get =
a code or refresh token.  Those tokens uniquely identify the user from a =
privacy perspective.=20
It is the access tokens that are sent to the RS and those can and should =
be rotated, but the client)id is not sent to the RS in OAuth as part of =
the spec.=20

If you did rotate the client_id then the AS would track it across =
rotations, so it wouldn=E2=80=99t really achieve anything.

One thing we don=E2=80=99t do is allow the client to specify the =
client_id, that could allow correlation of the client across multiple AS =
and that might be a privacy issue, but we don=E2=80=99t allow it.

John B.


--Apple-Mail=_B51C742A-3EF2-49DB-9B7E-D195D0ECEE5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

snip
On Feb 18, 2015, at 6:46 AM, Kathleen =
Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

> The client_id *could* be short lived, =
but they usually aren't. I don't see any particular logging or tracking =
concerns using a dynamic OAuth client above using any other piece of =
software, ever. As such, I don't think it requires special calling out =
here.

Help me understand why =
there should not be text that shows this is not an issue or please =
propose some text.  This is bound to come up in IESG reviews if not =
addressed up front. 

=


The client_id is used to =
communicate to the Authorization server to get a code or refresh token. =
 Those tokens uniquely identify the user from a privacy =
perspective. 
It is the access tokens that are =
sent to the RS and those can and should be rotated, but the client)id is =
not sent to the RS in OAuth as part of the spec. 

If you did rotate the =
client_id then the AS would track it across rotations, so it wouldn=E2=80=99=
t really achieve anything.

One thing we don=E2=80=99t do is allow the client to specify =
the client_id, that could allow correlation of the client across =
multiple AS and that might be a privacy issue, but we don=E2=80=99t =
allow it.

John =
B.

=

--Apple-Mail=_B51C742A-3EF2-49DB-9B7E-D195D0ECEE5B--

--Apple-Mail=_12E6CA57-8905-4D03-A769-924BF9CE8B6E
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMTgxNTA3NThaMCMGCSqGSIb3DQEJBDEWBBQLIQy7Td14UVgyVvK0xFI/
LafLgTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQApmnIp9pkxd+mH3Ycw7n8ygPEFPzTdYahLbYxh8dAi0aw7DE4j/2vi
8ejfQQ8m+QCpPrJe9/ochVu90nneV4oG4MD5JkjcH2l/hfm2IBbe0MEvGyK8wA2gSupK+UO58P/o
IiFV8S8QzyB4TNcpXbG6ZDqeXmdLYQkxUFBQ7OomIdwHgpEYRyws7JbTd9GYr4JfhIe1IXpEbr3k
uCpzTnSvMsdsDOriELsbCkYY5/WR56s9HkIbRf3TdaMeDxWULmql856ua17LOjAoXO4Ug5dvWFXT
zDgsQw+nz1po7MfRgmyzYCtE5KGFtSb52zsxtKX8HluFfVJkDc7hcgyCJ9ayAAAAAAAA
--Apple-Mail=_12E6CA57-8905-4D03-A769-924BF9CE8B6E--


From nobody Wed Feb 18 07:30:27 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5DF1ABB19 for ; Wed, 18 Feb 2015 07:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC-zJQxEhS6t for ; Wed, 18 Feb 2015 07:30:23 -0800 (PST)
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5AD1ABC74 for ; Wed, 18 Feb 2015 07:30:22 -0800 (PST)
Received: by labms9 with SMTP id ms9so1810331lab.10 for ; Wed, 18 Feb 2015 07:30:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QL+qm7ndW1G5MYqVh6BLQubf4EnM2f2o0Yp0x1cuTVw=; b=wkrGukqxjbXwHH/h6ZazAyMrUYDTLDbSB/gSs/JMIjfMTTyV44r+XXY1/3GRRa6/ed DPQWWjOE3Zk6bgm+7SJO2pGmH9KoOUtB9V4d5Dz/hn1j14zk2avxXHtcgJxB5aOIDJAS sddni3u69gFGgWLQMCjdjHAjElQJMLJTxlNAyNa57DNTGGeNF6L6O8QYaNiytQLT74Is t3Po7BlcNZ1BIeMA0b7zD/Rt1Gkv9nQYSgVmNt3WQ49c2wtMMtcM4x9LB54Mm5EBgiCJ iMEnOm9NGPwd41trpfzxvZpgNy34YMzAx/313Y/nTiBMpU9xH24OPUd8xd2oVed8Zbgx OcJg==
MIME-Version: 1.0
X-Received: by 10.152.8.229 with SMTP id u5mr4828158laa.4.1424273421017; Wed, 18 Feb 2015 07:30:21 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Wed, 18 Feb 2015 07:30:20 -0800 (PST)
In-Reply-To: <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>
Date: Wed, 18 Feb 2015 10:30:20 -0500
Message-ID: 
From: Kathleen Moriarty 
To: John Bradley 
Content-Type: multipart/alternative; boundary=089e0158ab6052a9ad050f5e7f2e
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 15:30:26 -0000

--089e0158ab6052a9ad050f5e7f2e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 18, 2015 at 10:07 AM, John Bradley  wrote:

> snip
>
> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
> > The client_id *could* be short lived, but they usually aren't. I don't
>> see any particular logging or tracking concerns using a dynamic OAuth
>> client above using any other piece of software, ever. As such, I don't
>> think it requires special calling out here.
>>
>
> Help me understand why there should not be text that shows this is not an
> issue or please propose some text.  This is bound to come up in IESG
> reviews if not addressed up front.
>
>>
>>
> The client_id is used to communicate to the Authorization server to get a
> code or refresh token.  Those tokens uniquely identify the user from a
> privacy perspective.
> It is the access tokens that are sent to the RS and those can and should
> be rotated, but the client)id is not sent to the RS in OAuth as part of t=
he
> spec.
>
> If you did rotate the client_id then the AS would track it across
> rotations, so it wouldn=E2=80=99t really achieve anything.
>
> One thing we don=E2=80=99t do is allow the client to specify the client_i=
d, that
> could allow correlation of the client across multiple AS and that might b=
e
> a privacy issue, but we don=E2=80=99t allow it.
>

Thanks, John.  It may be helpful to add in this explanation unless there is
some reason not to?

>
> John B.
>
>


--=20

Best regards,
Kathleen

--089e0158ab6052a9ad050f5e7f2e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <ve7jtb@ve7jtb.com&=
gt; wrote:
snip
O=
n Feb 18, 2015, at 6:46 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.c=
om> wrote:

> The client_i=
d *could* be short lived, but they usually aren't. I don't see any =
particular logging or tracking concerns using a dynamic OAuth client above =
using any other piece of software, ever. As such, I don't think it requ=
ires special calling out here.
Help me understand why there should not be text that =
shows this is not an issue or please propose some text.=C2=A0 This is bound=
 to come up in IESG reviews if not addressed up front.=C2=A0


The client_id is used to communicate to the Authorization server to get a =
code or refresh token.=C2=A0 Those tokens uniquely identify the user from a=
 privacy perspective.=C2=A0
It is the access tokens that are sent=
 to the RS and those can and should be rotated, but the client)id is not se=
nt to the RS in OAuth as part of the spec.=C2=A0

I=
f you did rotate the client_id then the AS would track it across rotations,=
 so it wouldn=E2=80=99t really achieve anything.

O=
ne thing we don=E2=80=99t do is allow the client to specify the client_id, =
that could allow correlation of the client across multiple AS and that migh=
t be a privacy issue, but we don=E2=80=99t allow it.

Thanks, John.=C2=A0 It may be helpful to add in this =
explanation unless there is some reason not to?=C2=A0

John=
 B.




-- 

=
Best regards,
Kathleen




--089e0158ab6052a9ad050f5e7f2e--


From nobody Wed Feb 18 07:34:19 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C923A1A8994 for ; Wed, 18 Feb 2015 07:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RoKQyfKOQhZ for ; Wed, 18 Feb 2015 07:34:16 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B610C1A8852 for ; Wed, 18 Feb 2015 07:34:15 -0800 (PST)
Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lr32V-1Xtysg0KcF-00ecw3; Wed, 18 Feb 2015 16:34:13 +0100
Message-ID: <54E4B0AD.10801@gmx.net>
Date: Wed, 18 Feb 2015 16:33:01 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: torsten@lodderstedt.net
References: <54C7BBA4.4030702@gmx.net>  <2E3D2EE7-8F5F-452D-880A-D62A513AC853@lodderstedt.net> <54E370F9.8060209@gmx.net> <17faabb6e724fb54f3cb8060a3d9cb08@lodderstedt.net>
In-Reply-To: <17faabb6e724fb54f3cb8060a3d9cb08@lodderstedt.net>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5oeP2wWKeeji6dTUPhE5eWuLR7mFFAgUf"
X-Provags-ID: V03:K0:/zPDyPsxdTFKwdkxXuNZ6m+e3JtOa16l+/i7vcoRl+AcAUO3UMR I8QhEbTK3JLdbSfYGvNSpaQYMkigpfOivjigwwbffedzt+OscvFIAfKEoUfjVJfk5P74MjT Z3LL/jeB94rUTMPanvffv28Nd8yjdz9B/mvqIqNDIRHpp/p1Gr/4rKB06MsMU4z0fATd9Vs 8fGVPDQK4pplB1DsDUHqw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: oauth@ietf.org, "naa@google.com >> Naveen Agarwal" 
Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 15:34:17 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5oeP2wWKeeji6dTUPhE5eWuLR7mFFAgUf
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Thanks for the info, Torsten.

Your feedback raises an interesting question, namely what functionality
the parties have to implement to claim conformance to the specification.

Quickly scanning through the specification didn't tell me whether it is
OK to just implement the plain mode or whether both modes are
mandatory-to-implement. We have to say something about this.

Ciao
Hannes


On 02/18/2015 02:16 PM, torsten@lodderstedt.net wrote:
> Hi Hannes,
>=20
> our implementation supports the "plain" mode only. We just verified
> compliance of our implementation with the current spec. As the only
> deviation, we do not enforce the minimum length of 43 characters of the=

> code verifier.
>=20
> kind regards,
> Torsten.
>=20
> Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
>> Hi Torsten,
>>
>> does this mean that your implementation is not compliant with the
>> current version anymore or that you haven't had time to verify whether=

>> there are differences to the earlier version?
>>
>> Ciao
>> Hannes
>>
>>
>> On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
>>> Deutsche Telekom also implemented an early version of the draft last
>>> year.
>>>
>>>
>>>
>>> Am 30.01.2015 um 18:50 schrieb Brian Campbell
>>> >:
>>>
>>>>
>>>> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
>>>> > wrote=
:
>>>>
>>>>
>>>>     1) What implementations of the spec are you aware of?
>>>>
>>>>
>>>> We have an AS side implementation of an earlier draft that was
>>>> released in June of last year:
>>>> http://documentation.pingidentity.com/pages/viewpage.action?pageId=3D=
26706844
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth


--5oeP2wWKeeji6dTUPhE5eWuLR7mFFAgUf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJU5LC0AAoJEGhJURNOOiAtwAwH/jFkWQXjkzCzATVv+6gZlSk2
8BGMGXnG3V1lSioFUPlPndc2ojIh1uVSjnCKy24Pdx8u9LOwby/5Xd0zT7DQ+YIj
i6dHrC5DyOoMcpuwaaZv7Pcmo2US7jkKZfjsRN1YQwejO1nHCpJeWqmwQAwHsUtn
D+uX9uu7LvaSfD5Z5sG932xbmvVjcTJ6dZ+nRs1+uhe17mLtrXycwWGP8HwV4Who
PJimwORQTDJTWL6kLnxUPRRqWsij1X0C2R5PBn1+r0csfnUNsRb0TsssjWJDpKAM
n2Bs64rbSX7DT8tqAbLNwmeda59yUUrrHM4jDpTvp4D8MMPJ7dLD0qQIaw9/TTw=
=8quO
-----END PGP SIGNATURE-----

--5oeP2wWKeeji6dTUPhE5eWuLR7mFFAgUf--


From nobody Wed Feb 18 08:18:16 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EC51A8931 for ; Wed, 18 Feb 2015 08:18:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.509
X-Spam-Level: 
X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nAK9SQayJ3j for ; Wed, 18 Feb 2015 08:18:13 -0800 (PST)
Received: from nm41.bullet.mail.bf1.yahoo.com (nm41.bullet.mail.bf1.yahoo.com [216.109.114.57]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83971A1AE8 for ; Wed, 18 Feb 2015 08:18:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1424276291; bh=XbTmUnfOrb8b5yyQobVXuHUcZMvk862de47nqsLgOBU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=JMYPRvmh8F1QjaaUo6C5DwOa6loR5OM+Vx+wpJwMG/o/iKRa6629S4FIGClyZqi+sFioAeERCXA34WZMpcdFaMDK9uxVCpsHZjJNAYTSQk0KWqUJf3VGXUAIofp4Pdq90bxnjN97CfkrZ0Qrj97rPVdbmseurgerMeRn3rmfDdor6jDh02TFMKZ454qY68USmCK9s3YFiCVGR0w/TNe3Vf2GfKRtRo8Xcp3wKBNXtSMEaKKZyUshdUAmB9ntZqiBa5l5EIFMpHPjBrQiOhkxFqto9zcAJ49Nc4MW73Mwc555eflG1R3qqGf5GxdDVXyr64slpUtMkgudwVKA7aE6Nw==
Received: from [66.196.81.171] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 18 Feb 2015 16:18:11 -0000
Received: from [98.139.212.213] by tm17.bullet.mail.bf1.yahoo.com with NNFMP;  18 Feb 2015 16:18:11 -0000
Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 18 Feb 2015 16:18:01 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 569112.98066.bm@omp1022.mail.bf1.yahoo.com
X-YMail-OSG: 1s4EHvQVM1nwCmAvDxqB.sari9Vm92L6j6HFDEMEHQpH09CExLpvqE_51RcFrnt TJrMENVkXTQ8d6RRcoEiJe0Im2ludDVnkk0wdJVDyhfwnY2XAvp1GzlIEZ5pcfjAinuRSPVyLNKt QBF06f3wXWZKySZRbF5mXEMJZOA.zFJJuqJ9vnKGZGhF1WTZST5lLCNYuhlxqHpIT3l7zGtxWb5K sDh4_TvyTtKvtb7A_wq.WO68P3yRvFok5iCfAgB.IVXoc8jZ7dJtkSbRiIK7WR114JzlTOa5fTU0 304Hvn4OSwpcylt0wBrm3H3ujz7kd_ZuTtFjeuRoS3N_aQyTwGGQ.8EeoXTq6ahkXL8zIG8G5L1h KLDLvQzZ1iAqdNqwPS50nZRN6kTXQ24wuG8fnt0xkE_tOUOk2A2.AiJ7cQ7yERYkExG4MadMt55v eAsD2RguhAjXMsLq3HU2tNzC6IzNZ2u4S7CDjUS4wLjVEpyL5aYmaiGngUtamCkKF1VTLha.iwsA 8ouahKl.77snBkiH2o6g28azVd.NbazSLWKRSS7DBTw--
Received: by 66.196.81.106; Wed, 18 Feb 2015 16:18:01 +0000 
Date: Wed, 18 Feb 2015 16:18:00 +0000 (UTC)
From: Bill Mills 
To: Nat Sakimura ,  Hannes Tschofenig 
Message-ID: <2147194906.1078114.1424276280519.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp>
References: <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1078113_537707165.1424276280509"
Archived-At: 
Cc: "oauth@ietf.org" , "naa@google.com" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 16:18:15 -0000

------=_Part_1078113_537707165.1424276280509
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I was OK with SHOULD because there's no firm measure of "enough entropy". =
=C2=A0Whether it's SHOULD or MUST is moot without some way to quantify it.=
=20

     On Wednesday, February 18, 2015 1:27 AM, Nat Sakimura  wrote:
  =20

 Hi Hannes,=20

The reason I have put SHOULD there instead of MUST is=20
that there may be a valid reason not to in a controlled=20
environment, and it does not interfere the interoperability.
The deployment may opt to use other control than entropy,=20
and SHOULD allows it while MUST does not.=20

Having said that, if the WG is OK with a MUST there,=20
I am fine with incorporating the proposed change.=20

Cheers,=20

Nat


On Wed, 18 Feb 2015 09:43:30 +0100
Hannes Tschofenig  wrote:

> Hi Nat,
>=20
> thanks for the quick response.
>=20
> I was hoping to see a statement like "The code verifier MUST have
> enough entropy to make it impractical to guess the value." in the
> text rather than the SHOULD. Given all the other statements in the
> draft I am not sure what the should actually means. Under what
> conditions would an implementer not provide enough entropy to make
> guessing impractical?
>=20
> Ciao
> Hannes
>=20
> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> > Hi Hannes,=20
> >=20
> > I hereby confirm that I have submit the draft=C2=A0 in full conformance
> > with the=C2=A0 provisions of BCP 78 and BCP 79.
> >=20
> > Re: Security Consideration (7.1) and section 4.1
> >=20
> > The first part of the 7.1 is a non-normative prose explaining that
> > the implementers got to make sure that the code verifier is hard to
> > guessed or modeled. In a way, this is laying out the basic security
> > property requirment on the code verifier.=20
> >=20
> > Then, it goes onto the implementation guideance that one need to
> > use a cryptographic random number generator instead of relying on a
> > rand() in some language that are=C2=A0 not cryptographically random to
> > generate 32-octet sequence. The same text is in 4.1 as well.=20
> >=20
> > We did not copy "code verifier SHOULD have enough entropy to make
> > it impractical to guess the value" here because that looked
> > needlessly repeating, but if you want, I have no objection in
> > adding it to 7.1.=20
> >=20
> > Alternatively, in 7.1, after explaining the rationale, we can just
> > point to 4.1 for the control and implementation guidance.=20
> >=20
> > Re: 32-octet
> >=20
> > We chose it because we are using SHA256 in generating the code
> > challange. Having more entropy does not help us here, while having
> > less octets increases the risk.=20
> >=20
> > Best,=20
> >=20
> > Nat=20
> >=20
> >=20
> >=20
> > On Tue, 17 Feb 2015 17:56:33 +0100
> > Hannes Tschofenig  wrote:
> >=20
> >> Hi Nat, John, Naveen,
> >>
> >> thanks a lot for your work on the document.
> >>
> >> I still need responses to this mail to complete the shepherd
> >> writeup:
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> >>
> >> I definitely need the IPR confirmation.
> >>
> >> It would also be helpful to have someone who implemented the
> >> specification as it currently is. I asked Brian and Thorsten for
> >> clarification regarding their statements that they implemented
> >> earlier versions of the spec.
> >>
> >> As a final remark I still believe that the text regarding the
> >> randomness is still a bit inconsistent. Here are two examples:
> >>
> >> 1) In the Security Consideration you write that "The security model
> >> relies on the fact that the code verifier is not learned or
> >> guessed by the attacker.=C2=A0 It is vitally important to adhere to
> >> this principle. "
> >>
> >> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
> >> have enough entropy to make it impractical to guess the value.=C2=A0 I=
t
> >> is RECOMMENDED that the output of a suitable random number
> >> generator be used to create a 32-octet sequence."
> >>
> >> There is clearly a long way from a SHOULD have enough entropy to
> >> the text in the security consideration section where you ask for
> >> 32 bytes entropy.
> >>
> >> It is also not clear why you ask for 32 bytes of entropy in
> >> particular.
> >>
> >> Ciao
> >> Hannes
> >>
> >=20
> >=20
>=20


--=20
Nat Sakimura (n-sakimura@nri.co.jp)
Nomura Research Institute, Ltd.=20

=E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E5=90=AB=E3=81=BE=E3=82=8C=E3=
=82=8B=E6=83=85=E5=A0=B1=E3=81=AF=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=
=A7=E3=81=82=E3=82=8A=E3=80=81=E5=AE=9B=E5=85=88=E3=81=AB=E8=A8=98=E8=BC=89=
=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E6=96=B9=E3=81=AE=E3=81=BF=E3=
=81=AB=E9=80=81=E4=BF=A1
=E3=81=99=E3=82=8B=E3=81=93=E3=81=A8=E3=82=92=E6=84=8F=E5=9B=B3=E3=81=97=E3=
=81=A6=E3=81=8A=E3=82=8A=E3=81=BE=E3=81=99=E3=80=82=E6=84=8F=E5=9B=B3=E3=81=
=95=E3=82=8C=E3=81=9F=E5=8F=97=E5=8F=96=E4=BA=BA=E4=BB=A5=E5=A4=96=E3=81=AE=
=E6=96=B9=E3=81=AB=E3=82=88=E3=82=8B=E3=81=93=E3=82=8C=E3=82=89=E3=81=AE=E6=
=83=85=E5=A0=B1=E3=81=AE
=E9=96=8B=E7=A4=BA=E3=80=81=E8=A4=87=E8=A3=BD=E3=80=81=E5=86=8D=E9=85=8D=E5=
=B8=83=E3=82=84=E8=BB=A2=E9=80=81=E3=81=AA=E3=81=A9=E4=B8=80=E5=88=87=E3=81=
=AE=E5=88=A9=E7=94=A8=E3=81=8C=E7=A6=81=E6=AD=A2=E3=81=95=E3=82=8C=E3=81=A6=
=E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E8=AA=A4=E3=81=A3=E3=81=A6=E6=9C=AC=E3=
=83=A1=E3=83=BC=E3=83=AB
=E3=82=92=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0=B4=E5=90=88=E3=
=81=AF=E3=80=81=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=
=BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=
=E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E3=81=84=E3=81=9F=E3=81=A0=E3=
=81=8D=E3=80=81=E5=8F=97
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=92=E5=
=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=84=E3=81=9F=E3=81=A0=E3=81=8D=E3=81=
=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E8=87=B4=E3=81=97=
=E3=81=BE=E3=81=99=E3=80=82 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.

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


   
------=_Part_1078113_537707165.1424276280509
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I was OK with SHOULD because th=
ere's no firm measure of "enough entropy".  Whether it's SHOULD or MUS=
T is moot without some way to quantify it.
 


 
 
 
  O=
n Wednesday, February 18, 2015 1:27 AM, Nat Sakimura <n-sakimura@nri.co.=
jp> wrote:
  
  

 
H=
i Hannes, 

The reason I have put SHOUL=
D there instead of MUST is 
that there may be a valid rea=
son not to in a controlled 
environment, and it does not =
interfere the interoperability.
The deployment may opt to=
 use other control than entropy, 
and SHOULD allows it wh=
ile MUST does not. 

Having said that, =
if the WG is OK with a MUST there, 
I am fine with incorp=
orating the proposed change. 

Cheers, =


Nat


On Wed, 18 Feb 2015 09:43:30 +0100
Hannes Tschofenig <hannes.tschofenig@gmx.=
net> wrote:

> Hi Nat,
> 
> thanks for the quick response.
> 
> I was hoping to see a statement=
 like "The code verifier MUST have
> enough entropy to=
 make it impractical to guess the value." in the
> tex=
t rather than the SHOULD. Given all the other statements in the
> draft I am not sure what the should actually means. Under what<=
br clear=3D"none">> conditions would an implementer not provide enough e=
ntropy to make
> guessing impractical?
> 
> Ciao
> Hannes
> 
> On 02/18/2015 05:13 AM, Nat Sakimura=
 wrote:
> > Hi Hannes, 
> >=
 
> > I hereby confirm that I have submit the draft=
  in full conformance
> > with the  provi=
sions of BCP 78 and BCP 79.
> > 
=
> > Re: Security Consideration (7.1) and section 4.1
> > 
> > The first part of the 7.1 is a non=
-normative prose explaining that
> > the implemente=
rs got to make sure that the code verifier is hard to
>=
; > guessed or modeled. In a way, this is laying out the basic security<=
br clear=3D"none">> > property requirment on the code verifier. 
> > 
> > Then, it goes onto the=
 implementation guideance that one need to
> > use =
a cryptographic random number generator instead of relying on a
> > rand() in some language that are  not cryptographical=
ly random to
> > generate 32-octet sequence. The sa=
me text is in 4.1 as well. 
> > 
=
> > We did not copy "code verifier SHOULD have enough entropy to make=

> > it impractical to guess the value" here becaus=
e that looked
> > needlessly repeating, but if you =
want, I have no objection in
> > adding it to 7.1. =

> > 
> > Alternatively, in=
 7.1, after explaining the rationale, we can just
> &g=
t; point to 4.1 for the control and implementation guidance. 
> > 
> > Re: 32-octet
=
> > 
> > We chose it because we are using SHA=
256 in generating the code
> > challange. Having mo=
re entropy does not help us here, while having
> > =
less octets increases the risk. 
> > 
> > Best, 
> > 
> &=
gt; Nat 
> > 
> > 
> > 
> > On Tue, 17 Feb 2015 17:56:=
33 +0100
> > Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
&g=
t; > 
> >> Hi Nat, John, Naveen,
> >>
> >> thanks a lot for your w=
ork on the document.
> >>
>=
 >> I still need responses to this mail to complete the shepherd
> >> writeup:
> >> http://www.ietf.org/mail-archive/web/oauth/cur=
rent/msg14100.html
> >>
&g=
t; >> I definitely need the IPR confirmation.
> =
>>
> >> It would also be helpful to have s=
omeone who implemented the
> >> specification as=
 it currently is. I asked Brian and Thorsten for
> >=
;> clarification regarding their statements that they implemented
> >> earlier versions of the spec.
&=
gt; >>
> >> As a final remark I still beli=
eve that the text regarding the
> >> randomness =
is still a bit inconsistent. Here are two examples:
> =
>>
> >> 1) In the Security Consideration y=
ou write that "The security model
> >> relies on=
 the fact that the code verifier is not learned or
> &=
gt;> guessed by the attacker.  It is vitally important to adhere to=

> >> this principle. "
> &=
gt;>
> >> 2) In Section 4.1 you, however, wri=
te: "NOTE: code verifier SHOULD
> >> have enough=
 entropy to make it impractical to guess the value.  It
> >> is RECOMMENDED that the output of a suitable random numbe=
r
> >> generator be used to create a 32-octet se=
quence."
> >>
> >> Th=
ere is clearly a long way from a SHOULD have enough entropy to
> >> the text in the security consideration section where yo=
u ask for
> >> 32 bytes entropy.
> >>
> >> It is also not clear why y=
ou ask for 32 bytes of entropy in
> >> particula=
r.
> >>
> >> Ciao
> >> Hannes
> >>
> > 
> > 
> <=
br clear=3D"none">

-- 
Nat Sakimura (n-sakimura@nri.co.jp)
Nomura Research Institute, Ltd. 

=E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E5=90=AB=E3=81=BE=E3=82=8C=
=E3=82=8B=E6=83=85=E5=A0=B1=E3=81=AF=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=
=81=A7=E3=81=82=E3=82=8A=E3=80=81=E5=AE=9B=E5=85=88=E3=81=AB=E8=A8=98=E8=BC=
=89=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E6=96=B9=E3=81=AE=E3=81=BF=
=E3=81=AB=E9=80=81=E4=BF=A1
=E3=81=99=E3=82=8B=E3=81=93=
=E3=81=A8=E3=82=92=E6=84=8F=E5=9B=B3=E3=81=97=E3=81=A6=E3=81=8A=E3=82=8A=E3=
=81=BE=E3=81=99=E3=80=82=E6=84=8F=E5=9B=B3=E3=81=95=E3=82=8C=E3=81=9F=E5=8F=
=97=E5=8F=96=E4=BA=BA=E4=BB=A5=E5=A4=96=E3=81=AE=E6=96=B9=E3=81=AB=E3=82=88=
=E3=82=8B=E3=81=93=E3=82=8C=E3=82=89=E3=81=AE=E6=83=85=E5=A0=B1=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81=E8=A4=87=E8=A3=BD=E3=80=81=E5=
=86=8D=E9=85=8D=E5=B8=83=E3=82=84=E8=BB=A2=E9=80=81=E3=81=AA=E3=81=A9=E4=B8=
=80=E5=88=87=E3=81=AE=E5=88=A9=E7=94=A8=E3=81=8C=E7=A6=81=E6=AD=A2=E3=81=95=
=E3=82=8C=E3=81=A6=E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E8=AA=A4=E3=81=A3=E3=
=81=A6=E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB
=E3=82=92=E5=
=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=
=81=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=
=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=
=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E3=81=84=E3=81=9F=E3=81=A0=E3=81=8D=E3=80=
=81=E5=8F=97
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=
=A1=E3=83=BC=E3=83=AB=E3=82=92=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=84=
=E3=81=9F=E3=81=A0=E3=81=8D=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=
=A1=98=E3=81=84=E8=87=B4=E3=81=97=E3=81=BE=E3=81=99=E3=80=82 PLEASE READ:The information contained in this e-mail is confidential a=
nd intended
for the named recipient(s) only. If you are n=
ot an intended recipient
of this e-mail, you are hereby n=
otified that any review, dissemination,
distribution or d=
uplication of this message is strictly prohibited. If
you=
 have received this message in error, please notify the sender
immediately and delete your copy from your system.


_________=
______________________________________
OAuth mailing list=

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


  
 
  
 

------=_Part_1078113_537707165.1424276280509--


From nobody Wed Feb 18 08:29:46 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BDD1A89F6 for ; Wed, 18 Feb 2015 08:29:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level: 
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWLxUHecYDxV for ; Wed, 18 Feb 2015 08:29:43 -0800 (PST)
Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3500A1A8A60 for ; Wed, 18 Feb 2015 08:29:27 -0800 (PST)
Received: from mail-ie0-f182.google.com ([209.85.223.182]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKVOS95mAPDoedUkykTs9mqW4gFjKardjs@postini.com; Wed, 18 Feb 2015 08:29:27 PST
Received: by iecar1 with SMTP id ar1so2600585iec.0 for ; Wed, 18 Feb 2015 08:29:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KFe6lH9bKHDZX4nRwae55625eeIK//DlXmEz34bn17k=; b=LUuMhLaILD6UOpOFstLi0MDjDrRYAxCu2K4gSGH+Rb0+eYSqlODDpe1tmDetOEgfsY i8tWnlXQRqsdeC/07QSk0sXpP3qJwtIHPNgssC+iapK7MQk1WfVfF8Ha7cwExshNphIX j6zuMLlH/d278kgDO6MxbPwCiH+CLM1QgEQuPYkw8RtVJ1CV/JPZ/uCz6IK08GJeYgdO 5OW/dqnRtxgfSTEzu+QwoeDafe7mheu/yy77I35X9K5eN3yi3JJyRtOmnb3UuXRg74Pl 9XKriRZDzxyaG5MxwvL9++GxwQmHbNu8/hQKayakKHNzO2QJgovBLG+WPfI4JTixc36K 7Kdg==
X-Received: by 10.50.222.70 with SMTP id qk6mr3797678igc.47.1424276965988; Wed, 18 Feb 2015 08:29:25 -0800 (PST)
X-Gm-Message-State: ALoCoQm02xjfdh3vt8m6B+lr0lWuiZIrcz5Vf2XAzMXmxDuifwaiD65OaX4fhyv2le8oghL1M01wnUFR5FzZQkEbA4C9URCrD3lx4QGvM+1tCX/PMG/F6QN2J6Oik4DIuTO99sYJLvhI
X-Received: by 10.50.222.70 with SMTP id qk6mr3797361igc.47.1424276962926; Wed, 18 Feb 2015 08:29:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.107.105 with HTTP; Wed, 18 Feb 2015 08:28:52 -0800 (PST)
In-Reply-To: <175D5D8F-05C5-4926-A44C-D01E5398E49B@ve7jtb.com>
References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp> <54E450B2.7020409@gmx.net> <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp> <54E45F22.8060902@gmx.net>  <175D5D8F-05C5-4926-A44C-D01E5398E49B@ve7jtb.com>
From: Brian Campbell 
Date: Wed, 18 Feb 2015 09:28:52 -0700
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001a11344d8a83c766050f5f522f
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 16:29:45 -0000

--001a11344d8a83c766050f5f522f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 18, 2015 at 7:38 AM, John Bradley  wrote:

>
>
> I don=E2=80=99t remember precisely , but I may be the one responsible for=
 the for
> the 2^(-128) value for code.
>
>
The archives have a more precise memory
http://www.ietf.org/mail-archive/web/oauth/current/msg03844.html ;)

--001a11344d8a83c766050f5f522f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Wed, Feb 18, 2015 at 7:38 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:


I don=E2=80=99t rem=
ember precisely , but I may be the one responsible for the for the=C2=A02^(-128) value for code.


The archiv=
es have a more precise memory http://www.ietf.org/mail-archive/web/oauth/=
current/msg03844.html ;)


--001a11344d8a83c766050f5f522f--


From nobody Wed Feb 18 08:46:30 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376A71A8A70 for ; Wed, 18 Feb 2015 08:46:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level: 
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-ODYwQ2lkGL for ; Wed, 18 Feb 2015 08:46:24 -0800 (PST)
Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C571A8A71 for ; Wed, 18 Feb 2015 08:46:24 -0800 (PST)
Received: from mail-ig0-f180.google.com ([209.85.213.180]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKVOTB356EwnT4KW+jAyZUHLF4NWPdSlwr@postini.com; Wed, 18 Feb 2015 08:46:24 PST
Received: by mail-ig0-f180.google.com with SMTP id b16so3076005igk.1 for ; Wed, 18 Feb 2015 08:46:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OWNEcSZGLyJ6LiRflqhkgXERcthGah/Wg5+AgjDvsuA=; b=DNVj3isEnj2mAantowoaWAGyeR5PQg+1LPajWNXENHs82cYCwID5ALQSQ1VLyxk+iF cegk5TZBEon3t6xuabIP/VFGOpVDQU46BEnITnCbGpKpOs4Ixv9ZKadI2p5sB7AdCDfB RMfegvxVMyUxtRwnfEpX9+KYY7hGrvCu07LaA+Cwt0kdumIA/g7PLEPffWiBnhG5mNSW 5fGwul5RMtdcJ9szC2pTYO9vudS95ZPx6GQvtSqDqRbNZuCcTg+MuS80iLGUee0YCR8F gX1Mmcu6Yuj1BWxovhf8XwsrrFm6Vyc8WFBO0/duDwPXU9EeICdc/K9cg+Xb7S0gaFMJ dvOA==
X-Received: by 10.50.32.33 with SMTP id f1mr1336707igi.9.1424277983454; Wed, 18 Feb 2015 08:46:23 -0800 (PST)
X-Gm-Message-State: ALoCoQlUvhsE6APX/yF1gMQU2ejYxs3w0yr+9VZJ8AuUmAmjQcE7Gol8s3fb62/bdLihlD2tBtHmRAOgnM6YzVuGXNshAjegUWMO0ahBs7H0fMCoHfqvU6gtZRyBgFkjLij4v1N8bxU6
X-Received: by 10.50.32.33 with SMTP id f1mr1336684igi.9.1424277983301; Wed, 18 Feb 2015 08:46:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.107.105 with HTTP; Wed, 18 Feb 2015 08:45:53 -0800 (PST)
In-Reply-To: <54E4B0AD.10801@gmx.net>
References: <54C7BBA4.4030702@gmx.net>  <2E3D2EE7-8F5F-452D-880A-D62A513AC853@lodderstedt.net> <54E370F9.8060209@gmx.net> <17faabb6e724fb54f3cb8060a3d9cb08@lodderstedt.net> <54E4B0AD.10801@gmx.net>
From: Brian Campbell 
Date: Wed, 18 Feb 2015 09:45:53 -0700
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=047d7b10ce3d41b9cb050f5f8f20
Archived-At: 
Cc: oauth , "naa@google.com >> Naveen Agarwal" 
Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 16:46:29 -0000

--047d7b10ce3d41b9cb050f5f8f20
Content-Type: text/plain; charset=UTF-8

There's a bit of MTI talk tucked into
https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 that
perhaps needs to be expanded and/or placed somewhere else.

On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Thanks for the info, Torsten.
>
> Your feedback raises an interesting question, namely what functionality
> the parties have to implement to claim conformance to the specification.
>
> Quickly scanning through the specification didn't tell me whether it is
> OK to just implement the plain mode or whether both modes are
> mandatory-to-implement. We have to say something about this.
>
> Ciao
> Hannes
>
>
> On 02/18/2015 02:16 PM, torsten@lodderstedt.net wrote:
> > Hi Hannes,
> >
> > our implementation supports the "plain" mode only. We just verified
> > compliance of our implementation with the current spec. As the only
> > deviation, we do not enforce the minimum length of 43 characters of the
> > code verifier.
> >
> > kind regards,
> > Torsten.
> >
> > Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
> >> Hi Torsten,
> >>
> >> does this mean that your implementation is not compliant with the
> >> current version anymore or that you haven't had time to verify whether
> >> there are differences to the earlier version?
> >>
> >> Ciao
> >> Hannes
> >>
> >>
> >> On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
> >>> Deutsche Telekom also implemented an early version of the draft last
> >>> year.
> >>>
> >>>
> >>>
> >>> Am 30.01.2015 um 18:50 schrieb Brian Campbell
> >>> >:
> >>>
> >>>>
> >>>> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
> >>>> > wrote:
> >>>>
> >>>>
> >>>>     1) What implementations of the spec are you aware of?
> >>>>
> >>>>
> >>>> We have an AS side implementation of an earlier draft that was
> >>>> released in June of last year:
> >>>>
> http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844
> >>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org 
> >>>> https://www.ietf.org/mailman/listinfo/oauth
>
>

--047d7b10ce3d41b9cb050f5f8f20
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


There's a bit of MTI talk tucked into https://tool=
s.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 that perhaps nee=
ds to be expanded and/or placed somewhere else. 

On Wed, Feb 18, 2015 at 8:33 AM, Hannes =
Tschofenig <hannes.tschofenig@gmx.net> wrote:
Thanks for the info, Torsten=
.



Your feedback raises an interesting question, namely what functionality

the parties have to implement to claim conformance to the specification.


Quickly scanning through the specification didn't tell me whether it is=


OK to just implement the plain mode or whether both modes are

mandatory-to-implement. We have to say something about this.



Ciao

Hannes






On 02/18/2015 02:16 PM, torsten@=
lodderstedt.net wrote:

> Hi Hannes,

>

> our implementation supports the "plain" mode only. We just v=
erified

> compliance of our implementation with the current spec. As the only
> deviation, we do not enforce the minimum length of 43 characters of th=
e

> code verifier.

>

> kind regards,

> Torsten.

>

> Am 17.02.2015 17:48, schrieb Hannes Tschofenig:

>> Hi Torsten,

>>

>> does this mean that your implementation is not compliant with the<=
br>
>> current version anymore or that you haven't had time to verify=
 whether

>> there are differences to the earlier version?

>>

>> Ciao

>> Hannes

>>

>>

>> On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:

>>> Deutsche Telekom also implemented an early version of the draf=
t last

>>> year.

>>>

>>>

>>>

>>> Am 30.01.2015 um 18:50 schrieb Brian Campbell

>>> <bcampbell@pi=
ngidentity.com <mailto:bcampbell@pingidentity.com>>:

>>>

>>>>

>>>> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig

>>>> <hannes.ts=
chofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:

>>>>

>>>>

>>>>=C2=A0 =C2=A0 =C2=A01) What implementations of the spec are=
 you aware of?

>>>>

>>>>

>>>> We have an AS side implementation of an earlier draft that=
 was

>>>> released in June of last year:

>>>> http://documentation.ping=
identity.com/pages/viewpage.action?pageId=3D26706844

>>>>

>>>> _______________________________________________

>>>> OAuth mailing list

>>>> OAuth@ietf.org <m=
ailto:OAuth@ietf.org>

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







--047d7b10ce3d41b9cb050f5f8f20--


From nobody Wed Feb 18 09:33:44 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C321A8A91 for ; Wed, 18 Feb 2015 09:33:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9vR7A5J2riu for ; Wed, 18 Feb 2015 09:33:42 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F3A1A88E0 for ; Wed, 18 Feb 2015 09:33:24 -0800 (PST)
Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lcjdr-1Xfl7n1hrj-00k47b; Wed, 18 Feb 2015 18:33:20 +0100
Message-ID: <54E4CCDD.6010709@gmx.net>
Date: Wed, 18 Feb 2015 18:33:17 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Brian Campbell 
References: <54C7BBA4.4030702@gmx.net>  <2E3D2EE7-8F5F-452D-880A-D62A513AC853@lodderstedt.net> <54E370F9.8060209@gmx.net> <17faabb6e724fb54f3cb8060a3d9cb08@lodderstedt.net> <54E4B0AD.10801@gmx.net> 
In-Reply-To: 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CKvBJIBeNrICBFhEUAGIcpisiocFQ6Fuu"
X-Provags-ID: V03:K0:2e21g9h0eKZ2ZnbYDxAS+Lo5nxtqt8F82lRGaAk8rL55ZNf5dYO wqtWDY5agyJui+HVhkH/azBIGVWw84gTgfn/8LJNBcpGOk5VYSrxWfgXiVOSM/y/2aYX4HC B4n5Wx9vowUVyy7PPoP4pX34GZpILY8dYS2pYl5BtcPqCpEND/9Io20Velr+zwb/nKubPT4 YT7GX2k3H9wKmcfLQFc0Q==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: oauth , "naa@google.com >> Naveen Agarwal" 
Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 17:33:44 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--CKvBJIBeNrICBFhEUAGIcpisiocFQ6Fuu
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thanks Brian for pointing me to Section 4.4.1 and to the MTI for "S256".
While this is good from a security point of view I am wondering whether
anyone is actually compliant to the specification. Neither PingIdentity
nor DT implements the S256 transform, if I understood that correctly.
Are you guys going planning to update your implementations?

Ciao
Hannes

On 02/18/2015 05:45 PM, Brian Campbell wrote:
> There's a bit of MTI talk tucked into
> https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 that=

> perhaps needs to be expanded and/or placed somewhere else.
>=20
> On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig
> > wrote:
>=20
>     Thanks for the info, Torsten.
>=20
>     Your feedback raises an interesting question, namely what functiona=
lity
>     the parties have to implement to claim conformance to the specifica=
tion.
>=20
>     Quickly scanning through the specification didn't tell me whether i=
t is
>     OK to just implement the plain mode or whether both modes are
>     mandatory-to-implement. We have to say something about this.
>=20
>     Ciao
>     Hannes
>=20
>=20
>     On 02/18/2015 02:16 PM, torsten@lodderstedt.net
>      wrote:
>     > Hi Hannes,
>     >
>     > our implementation supports the "plain" mode only. We just verifi=
ed
>     > compliance of our implementation with the current spec. As the on=
ly
>     > deviation, we do not enforce the minimum length of 43 characters
>     of the
>     > code verifier.
>     >
>     > kind regards,
>     > Torsten.
>     >
>     > Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
>     >> Hi Torsten,
>     >>
>     >> does this mean that your implementation is not compliant with th=
e
>     >> current version anymore or that you haven't had time to verify
>     whether
>     >> there are differences to the earlier version?
>     >>
>     >> Ciao
>     >> Hannes
>     >>
>     >>
>     >> On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
>     >>> Deutsche Telekom also implemented an early version of the draft=
 last
>     >>> year.
>     >>>
>     >>>
>     >>>
>     >>> Am 30.01.2015 um 18:50 schrieb Brian Campbell
>     >>> =

>          >>:
>     >>>
>     >>>>
>     >>>> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
>     >>>> 
>          >> wrote:
>     >>>>
>     >>>>
>     >>>>     1) What implementations of the spec are you aware of?
>     >>>>
>     >>>>
>     >>>> We have an AS side implementation of an earlier draft that was=

>     >>>> released in June of last year:
>     >>>>
>     http://documentation.pingidentity.com/pages/viewpage.action?pageId=3D=
26706844
>     >>>>
>     >>>> _______________________________________________
>     >>>> OAuth mailing list
>     >>>> OAuth@ietf.org       >
>     >>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20


--CKvBJIBeNrICBFhEUAGIcpisiocFQ6Fuu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJU5MzdAAoJEGhJURNOOiAtp1MH/iseRPS076lp0jpfc8MkZNXs
W56a4VdXwLM9ypna7Uv9BHAaQIh0HAsLNWDYNCW5nmxFJdwDFz7TKz8+YvFwKI3I
PIhmJAkOY1m5f7T15hlShSD/hkY0ZPqw608mVeMoi0bBuSfmhMlX2yrowy9/ur0x
vkqdf/ZEZd1/neVArwTyrFrp5+IlG38Kr9pgodnrnyGpoDH67cqhYPvJsOEU/Vpd
B9VFEcHrPFAEoB4By1cssLIXkjSuW2LPk3uXpljsvqe1NO5GvW5UAo6KaQXKo2Ha
57m8PgGLlIGP/juEI933mKGXufFWFAFz/ZwmCqilc2ReaC9LKO6x0mCjXU0sKZE=
=EPry
-----END PGP SIGNATURE-----

--CKvBJIBeNrICBFhEUAGIcpisiocFQ6Fuu--


From nobody Wed Feb 18 09:38:03 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BAC1A8878 for ; Wed, 18 Feb 2015 09:38:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level: 
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy74PXIK2CBc for ; Wed, 18 Feb 2015 09:37:59 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A141A1BA2 for ; Wed, 18 Feb 2015 09:37:59 -0800 (PST)
X-AuditID: 1209190c-f79696d000005933-7b-54e4cdf6fa22
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id B3.A4.22835.6FDC4E45; Wed, 18 Feb 2015 12:37:58 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t1IHbv6x016785; Wed, 18 Feb 2015 12:37:57 -0500
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1IHbtKm002675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Feb 2015 12:37:56 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_8C5B83EC-809E-408E-9D05-616208FEB0EB"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Justin Richer 
In-Reply-To: 
Date: Wed, 18 Feb 2015 12:37:55 -0500
Message-Id: 
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com> 
To: Kathleen Moriarty 
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixG6novvt7JMQgz+/BSwaduZbnHz7is1i 9d2/bA7MHjtn3WX3WLLkJ5PH7dsbWQKYo7hsUlJzMstSi/TtErgyjqz4xVSw3K5iVcNl9gbG S2ZdjJwcEgImEh37OlkhbDGJC/fWs4HYQgKLmSRO/LXpYuQCsjcySqxcDFIE4jxkkpg65RIz SBWzQILEn39PGEFsXgEDibmnvjCB2MIC5hL/H9wBs9kEVCWmr2kBszkFAiWO3X0MtoEFKD55 822oOe4STXOXsEHMsZLY07CABWLZOmaJO03vwIpEBCwk1jR/AyriADpVXqJnU/oERoFZSM6Y heQMiLi2xLKFr5khbE2J/d3LWTDFNSQ6v01kXcDItopRNiW3Sjc3MTOnODVZtzg5MS8vtUjX UC83s0QvNaV0EyMoBjgleXYwvjmodIhRgINRiYe3g+lJiBBrYllxZe4hRkkOJiVR3tXHgUJ8 SfkplRmJxRnxRaU5qcWHGCU4mJVEeHfsA8rxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1O TS1ILYLJynBwKEnwPj8D1ChYlJqeWpGWmVOCkGbi4AQZzgM0nPksyPDigsTc4sx0iPwpRkUp cV5VkIQASCKjNA+uF5aiXjGKA70izBsOUsUDTG9w3a+ABjMBDZ7/5xHI4JJEhJRUA+NEG32x nw891n8TDolfzm/josSv4rNhs9PXshVGC3VF3z2v9uhZM/PuBvvualbT2T6bcvLvLPub5Xd2 3s3XjWvUmIOqnixjT9t/NC/jW9mKg1+9Y8IkBJ+pvJpW4F922VVWbFXHP1dJxc25gs7vPcIk VOyzkvjltmR8SOm71KsiruSj0P94khJLcUaioRZzUXEiAGS8Vt8sAwAA
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 17:38:02 -0000

--Apple-Mail=_8C5B83EC-809E-408E-9D05-616208FEB0EB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I=E2=80=99ll incorporate this feedback into another draft, to be posted =
by the end of the week. Thanks everyone!

 =E2=80=94 Justin

> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty =
 wrote:
>=20
>=20
>=20
> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley > wrote:
> snip
>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty =
> wrote:
>>=20
>> > The client_id *could* be short lived, but they usually aren't. I =
don't see any particular logging or tracking concerns using a dynamic =
OAuth client above using any other piece of software, ever. As such, I =
don't think it requires special calling out here.
>>=20
>> Help me understand why there should not be text that shows this is =
not an issue or please propose some text.  This is bound to come up in =
IESG reviews if not addressed up front.=20
>>=20
>=20
> The client_id is used to communicate to the Authorization server to =
get a code or refresh token.  Those tokens uniquely identify the user =
from a privacy perspective.=20
> It is the access tokens that are sent to the RS and those can and =
should be rotated, but the client)id is not sent to the RS in OAuth as =
part of the spec.=20
>=20
> If you did rotate the client_id then the AS would track it across =
rotations, so it wouldn=E2=80=99t really achieve anything.
>=20
> One thing we don=E2=80=99t do is allow the client to specify the =
client_id, that could allow correlation of the client across multiple AS =
and that might be a privacy issue, but we don=E2=80=99t allow it.
>=20
> Thanks, John.  It may be helpful to add in this explanation unless =
there is some reason not to?=20
>=20
> John B.
>=20
>=20
>=20
>=20
> --=20
>=20
> Best regards,
> Kathleen
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_8C5B83EC-809E-408E-9D05-616208FEB0EB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I=E2=80=99ll incorporate this feedback into another draft, to =
be posted by the end of the week. Thanks everyone!

 =E2=80=94 Justin

On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:



On Wed, =
Feb 18, 2015 at 10:07 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
snip
On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

> The =
client_id *could* be short lived, but they usually aren't. I don't see =
any particular logging or tracking concerns using a dynamic OAuth client =
above using any other piece of software, ever. As such, I don't think it =
requires special calling out here.

Help me understand why there should not be text =
that shows this is not an issue or please propose some text.  This =
is bound to come up in IESG reviews if not addressed up =
front. 


The client_id is used to communicate =
to the Authorization server to get a code or refresh token.  Those =
tokens uniquely identify the user from a privacy =
perspective. 
It is the access tokens that are =
sent to the RS and those can and should be rotated, but the client)id is =
not sent to the RS in OAuth as part of the spec. 

If you did rotate the =
client_id then the AS would track it across rotations, so it wouldn=E2=80=99=
t really achieve anything.

One thing we don=E2=80=99t do is allow the client to specify =
the client_id, that could allow correlation of the client across =
multiple AS and that might be a privacy issue, but we don=E2=80=99t =
allow it.

Thanks, John.  It may be helpful =
to add in this explanation unless there is some reason not =
to? 

John B.




-- 

Best regards,
Kathleen



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

=

--Apple-Mail=_8C5B83EC-809E-408E-9D05-616208FEB0EB--


From nobody Wed Feb 18 09:58:08 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C0B1A87A6 for ; Wed, 18 Feb 2015 09:58:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.31
X-Spam-Level: 
X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dil_BTkUm68U for ; Wed, 18 Feb 2015 09:58:05 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BCA1A7003 for ; Wed, 18 Feb 2015 09:58:05 -0800 (PST)
Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M7Y9j-1XbFZ002v1-00xO1A; Wed, 18 Feb 2015 18:58:01 +0100
Message-ID: <54E4D2A5.7090501@gmx.net>
Date: Wed, 18 Feb 2015 18:57:57 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Justin Richer ,  Kathleen Moriarty 
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>  
In-Reply-To: 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8ej04jDCNh1cu1GDdkwc7OcbiKoSCHWGN"
X-Provags-ID: V03:K0:IlF566tb5le4pvwWQZpvNZwkucdMXtVJ163QWpCkYv+hEyNHgtY EPET6NBe+C2fppKJAhLXTYaY4S6i5REszS2d+Cy3xCDEekOCS5ANTmkhSOUaw3lAcjUMPjx mpu5xUgbjfb3zCSdn/HFASdB2roDo9pLA61SBn3tbGifutj7cCCD3AVa8kSGbIgrtel57F9 qVMERB4YuaZeLfSNrymWQ==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 17:58:07 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--8ej04jDCNh1cu1GDdkwc7OcbiKoSCHWGN
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Justin, Hi John,

I believe that provisioning a client with a unique id (which is what a
client id/client secret is) allows some form of linkability. While it
may be possible to associate the client to a specific user I could very
well imagine that the correlation between activities from a user and
those from the client (particularly when the client is running on the
user's device) is quite possible.

Ciao
Hannes

On 02/18/2015 06:37 PM, Justin Richer wrote:
> I=92ll incorporate this feedback into another draft, to be posted by th=
e
> end of the week. Thanks everyone!
>=20
>  =97 Justin
>=20
>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>> > > wrote:
>>
>>
>>
>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley > > wrote:
>>
>>     snip
>>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>>     >>     > wrote:
>>>
>>>         > The client_id *could* be short lived, but they usually aren=
't. I don't see any particular logging or tracking concerns using a dynam=
ic OAuth client above using any other piece of software, ever. As such, I=
 don't think it requires special calling out here.
>>>
>>>
>>>     Help me understand why there should not be text that shows this
>>>     is not an issue or please propose some text.  This is bound to
>>>     come up in IESG reviews if not addressed up front.=20
>>>
>>>
>>
>>     The client_id is used to communicate to the Authorization server
>>     to get a code or refresh token.  Those tokens uniquely identify
>>     the user from a privacy perspective.=20
>>     It is the access tokens that are sent to the RS and those can and
>>     should be rotated, but the client)id is not sent to the RS in
>>     OAuth as part of the spec.=20
>>
>>     If you did rotate the client_id then the AS would track it across
>>     rotations, so it wouldn=92t really achieve anything.
>>
>>     One thing we don=92t do is allow the client to specify the
>>     client_id, that could allow correlation of the client across
>>     multiple AS and that might be a privacy issue, but we don=92t allo=
w it.
>>
>>
>> Thanks, John.  It may be helpful to add in this explanation unless
>> there is some reason not to?=20
>>
>>
>>     John B.
>>
>>
>>
>>
>> --=20
>>
>> Best regards,
>> Kathleen
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


--8ej04jDCNh1cu1GDdkwc7OcbiKoSCHWGN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJU5NKlAAoJEGhJURNOOiAtwTsH/1YDT74iYqN5eAqFvtNqyLJ5
4DBpvBABJN+m4j/BLaOP3G7cw16R0/TE3Ncw3qmgyA7IM5D/+b/57C2PtQGRRfBJ
kCYS+3XFkkgD1qXKfSK5JN+ZFxIm/0g2FHZTh5d8QuJKNKHDcLrxJUh2/VLHYijK
sqSC4NXjiexQKcPBtPnOW6Fgiajs+fpbmoEYP/INF9lOaHJIdVP56OPbwDvfEDuE
r6OHzrOspdIh/Ynq7RGJpu3R8ejpmlaPz8Jgxsq7Rl5GYX5tXoMQLaFGSR1ExtRh
WUwh9SZiI4jbxoAKdnIZ2N12C5WNOcUvOsPO1KQ8S+Z1/tsLRFTfHM5ZUJh6lR4=
=ZlUc
-----END PGP SIGNATURE-----

--8ej04jDCNh1cu1GDdkwc7OcbiKoSCHWGN--


From nobody Wed Feb 18 09:58:14 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124BE1A7003 for ; Wed, 18 Feb 2015 09:58:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.31
X-Spam-Level: 
X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEtpTsgJwFbU for ; Wed, 18 Feb 2015 09:58:05 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BF41A8749 for ; Wed, 18 Feb 2015 09:58:05 -0800 (PST)
Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lpfas-1Xsdp831i2-00fRnm; Wed, 18 Feb 2015 18:58:00 +0100
Message-ID: <54E4D2A5.5030705@gmx.net>
Date: Wed, 18 Feb 2015 18:57:57 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Justin Richer ,  Kathleen Moriarty 
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>  
In-Reply-To: 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gKxvB3lvqsQ9K9vVg40xU8OmVNEawNeKb"
X-Provags-ID: V03:K0:Tcd6z0RU15ENzvsVkjD5v0EkKdkMXaA9zY3ky1UVWzHIJXUOVPX +DeHQfUYjVl05qDJJo1tQEG8Grequ73YRG1QqeJdHC1q2jpouhIHwKfvo3Yhdfnmrvk4DtR +0urXbxHD/+tS5BTOEUXNE/sp8pF1Iv2baxrX4ibliizyambrvy9yO1ROE6sXY8qxlqqnre D128uf1esmL3N5U/tkw6w==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 17:58:08 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--gKxvB3lvqsQ9K9vVg40xU8OmVNEawNeKb
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Justin, Hi John,

I believe that provisioning a client with a unique id (which is what a
client id/client secret is) allows some form of linkability. While it
may be possible to associate the client to a specific user I could very
well imagine that the correlation between activities from a user and
those from the client (particularly when the client is running on the
user's device) is quite possible.

Ciao
Hannes

On 02/18/2015 06:37 PM, Justin Richer wrote:
> I=92ll incorporate this feedback into another draft, to be posted by th=
e
> end of the week. Thanks everyone!
>=20
>  =97 Justin
>=20
>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>> > > wrote:
>>
>>
>>
>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley > > wrote:
>>
>>     snip
>>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>>     >>     > wrote:
>>>
>>>         > The client_id *could* be short lived, but they usually aren=
't. I don't see any particular logging or tracking concerns using a dynam=
ic OAuth client above using any other piece of software, ever. As such, I=
 don't think it requires special calling out here.
>>>
>>>
>>>     Help me understand why there should not be text that shows this
>>>     is not an issue or please propose some text.  This is bound to
>>>     come up in IESG reviews if not addressed up front.=20
>>>
>>>
>>
>>     The client_id is used to communicate to the Authorization server
>>     to get a code or refresh token.  Those tokens uniquely identify
>>     the user from a privacy perspective.=20
>>     It is the access tokens that are sent to the RS and those can and
>>     should be rotated, but the client)id is not sent to the RS in
>>     OAuth as part of the spec.=20
>>
>>     If you did rotate the client_id then the AS would track it across
>>     rotations, so it wouldn=92t really achieve anything.
>>
>>     One thing we don=92t do is allow the client to specify the
>>     client_id, that could allow correlation of the client across
>>     multiple AS and that might be a privacy issue, but we don=92t allo=
w it.
>>
>>
>> Thanks, John.  It may be helpful to add in this explanation unless
>> there is some reason not to?=20
>>
>>
>>     John B.
>>
>>
>>
>>
>> --=20
>>
>> Best regards,
>> Kathleen
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


--gKxvB3lvqsQ9K9vVg40xU8OmVNEawNeKb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJU5NKlAAoJEGhJURNOOiAtwTsH/1YDT74iYqN5eAqFvtNqyLJ5
4DBpvBABJN+m4j/BLaOP3G7cw16R0/TE3Ncw3qmgyA7IM5D/+b/57C2PtQGRRfBJ
kCYS+3XFkkgD1qXKfSK5JN+ZFxIm/0g2FHZTh5d8QuJKNKHDcLrxJUh2/VLHYijK
sqSC4NXjiexQKcPBtPnOW6Fgiajs+fpbmoEYP/INF9lOaHJIdVP56OPbwDvfEDuE
r6OHzrOspdIh/Ynq7RGJpu3R8ejpmlaPz8Jgxsq7Rl5GYX5tXoMQLaFGSR1ExtRh
WUwh9SZiI4jbxoAKdnIZ2N12C5WNOcUvOsPO1KQ8S+Z1/tsLRFTfHM5ZUJh6lR4=
=ZlUc
-----END PGP SIGNATURE-----

--gKxvB3lvqsQ9K9vVg40xU8OmVNEawNeKb--


From nobody Wed Feb 18 12:16:03 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512271A0378 for ; Wed, 18 Feb 2015 12:16:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsbqVhYqhimp for ; Wed, 18 Feb 2015 12:16:00 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA9D1A02F1 for ; Wed, 18 Feb 2015 12:15:59 -0800 (PST)
Received: from [79.253.34.96] (helo=android-6af638abbd217564.speedport.ip) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1YOB2M-0003Xq-5B; Wed, 18 Feb 2015 21:15:58 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <54E4CCDD.6010709@gmx.net>
References: <54C7BBA4.4030702@gmx.net>  <2E3D2EE7-8F5F-452D-880A-D62A513AC853@lodderstedt.net> <54E370F9.8060209@gmx.net> <17faabb6e724fb54f3cb8060a3d9cb08@lodderstedt.net> <54E4B0AD.10801@gmx.net>  <54E4CCDD.6010709@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----77J7C8ZENUURQJSLPRX13CCV40RG3X"
Content-Transfer-Encoding: 8bit
From: Torsten Lodderstedt 
Date: Wed, 18 Feb 2015 21:15:52 +0100
To: Hannes Tschofenig , Brian Campbell 
Message-ID: <06989626-BCCD-443B-AD5F-98436D681DB2@lodderstedt.net>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: oauth , "naa@google.com >> Naveen Agarwal" 
Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 20:16:03 -0000

------77J7C8ZENUURQJSLPRX13CCV40RG3X
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8

We don't plan to support s256 

Basically, I don't see a need to. Plain already mitigates the threat, spop/tcse had been designed to mitigate - an app intercepting the code response of a public client.

Am 18. Februar 2015 18:33:17 MEZ, schrieb Hannes Tschofenig :
>Thanks Brian for pointing me to Section 4.4.1 and to the MTI for
>"S256".
>While this is good from a security point of view I am wondering whether
>anyone is actually compliant to the specification. Neither PingIdentity
>nor DT implements the S256 transform, if I understood that correctly.
>Are you guys going planning to update your implementations?
>
>Ciao
>Hannes
>
>On 02/18/2015 05:45 PM, Brian Campbell wrote:
>> There's a bit of MTI talk tucked into
>> https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1
>that
>> perhaps needs to be expanded and/or placed somewhere else.
>> 
>> On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig
>> > wrote:
>> 
>>     Thanks for the info, Torsten.
>> 
>>     Your feedback raises an interesting question, namely what
>functionality
>>     the parties have to implement to claim conformance to the
>specification.
>> 
>>     Quickly scanning through the specification didn't tell me whether
>it is
>>     OK to just implement the plain mode or whether both modes are
>>     mandatory-to-implement. We have to say something about this.
>> 
>>     Ciao
>>     Hannes
>> 
>> 
>>     On 02/18/2015 02:16 PM, torsten@lodderstedt.net
>>      wrote:
>>     > Hi Hannes,
>>     >
>>     > our implementation supports the "plain" mode only. We just
>verified
>>     > compliance of our implementation with the current spec. As the
>only
>>     > deviation, we do not enforce the minimum length of 43
>characters
>>     of the
>>     > code verifier.
>>     >
>>     > kind regards,
>>     > Torsten.
>>     >
>>     > Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
>>     >> Hi Torsten,
>>     >>
>>     >> does this mean that your implementation is not compliant with
>the
>>     >> current version anymore or that you haven't had time to verify
>>     whether
>>     >> there are differences to the earlier version?
>>     >>
>>     >> Ciao
>>     >> Hannes
>>     >>
>>     >>
>>     >> On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
>>     >>> Deutsche Telekom also implemented an early version of the
>draft last
>>     >>> year.
>>     >>>
>>     >>>
>>     >>>
>>     >>> Am 30.01.2015 um 18:50 schrieb Brian Campbell
>>     >>> 
>>     >     >>:
>>     >>>
>>     >>>>
>>     >>>> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
>>     >>>> 
>>     >     >> wrote:
>>     >>>>
>>     >>>>
>>     >>>>     1) What implementations of the spec are you aware of?
>>     >>>>
>>     >>>>
>>     >>>> We have an AS side implementation of an earlier draft that
>was
>>     >>>> released in June of last year:
>>     >>>>
>>    
>http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844
>>     >>>>
>>     >>>> _______________________________________________
>>     >>>> OAuth mailing list
>>     >>>> OAuth@ietf.org 
>>     >
>>     >>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
------77J7C8ZENUURQJSLPRX13CCV40RG3X
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

We don't plan to support s256 



Basically, I don't see a need to. Plain already mitigates the threat, spop/tcse had been designed to mitigate - an app intercepting the code response of a public client.

Am 18. Februar 2015 18:33:17 MEZ, schrieb Hannes Tschofenig <hannes.tschofenig@gmx.net>:


Thanks Brian for pointing me to Section 4.4.1 and to the MTI for "S256".
While this is good from a security point of view I am wondering whether
anyone is actually compliant to the specification. Neither PingIdentity
nor DT implements the S256 transform, if I understood that correctly.
Are you guys going planning to update your implementations?

Ciao
Hannes

On 02/18/2015 05:45 PM, Brian Campbell wrote:
 There's a bit of MTI talk tucked into
 https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 that
 perhaps needs to be expanded and/or placed somewhere else.
 
 On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig
 <hannes.tschofenig@gmx.net
<mailto:hannes.tschofenig@gmx.net>> wrote:
 
     Thanks for the info, Torsten.
 
     Your feedback raises an interesting question, namely what functionality
     the parties have to implement to claim conformance to the specification.
 
     Quickly scanning through the specification didn't tell me whether it is
     OK to just implement the plain mode or whether both modes are
     mandatory-to-implement. We have to say something about this.
 
     Ciao
     Hannes
 
 
     On 02/18/2015 02:16 PM, torsten@lodderstedt.net
     <mailto:torsten@lodderstedt.net> wrote:
 Hi Hannes,

 our implementation supports the "plain" mode only. We just verified
 compliance of our implementation with the current spec. As the only
 deviation, we do not enforce the
minimum length of 43 characters
     of the
 code verifier.

 kind regards,
 Torsten.

 Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
 Hi Torsten,

 does this mean that your implementation is not compliant with the
 current version anymore or that you haven't had time to verify
     whether
 there are differences to the earlier version?

 Ciao
 Hannes


 On 01/31/2015 05:34 PM, Torsten
Lodderstedt wrote:
 Deutsche Telekom also implemented an early version of the draft last
 year.



 Am 30.01.2015 um 18:50 schrieb Brian Campbell
 <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>
     <mailto:bcampbell@pingidentity.com
     <mailto:bcampbell@pingidentity.com>>>:


 On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
 <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>
     <mailto:hannes.tschofenig@gmx.net
     <mailto:hannes.tschofenig@gmx.net>>> wrote:


     1) What implementations of the spec are you aware of?


 We have an AS side implementation of an earlier draft that was
 released in June of last year:

     http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844


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



-- 

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
------77J7C8ZENUURQJSLPRX13CCV40RG3X--


From nobody Wed Feb 18 12:28:31 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33FD1A0127 for ; Wed, 18 Feb 2015 12:28: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=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_orHb-gwNoW for ; Wed, 18 Feb 2015 12:28:25 -0800 (PST)
Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77F71A00B7 for ; Wed, 18 Feb 2015 12:28:24 -0800 (PST)
Received: by pdjz10 with SMTP id z10so3644657pdj.0 for ; Wed, 18 Feb 2015 12:28:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=wGOxobwl66XAHyO7qMEe93X9Jxbvj5+OFJplA76nYZM=; b=EjVJ4B8W30NZoZOPF3R1Kt2YLHuRgTFzxQ+5HDpzRVLUyjwWs1Z7LJx2Gn6koI1Fph BSn/buJPgl5S87CRwkUf9GDo2u1rtX90OGeJZqJUfOQsehrlrP3DceEIhfW0U0i7fltQ U9l0lZJ7t/Ibqa9JjZO5xqWLLKbpCP7xmQl9jbEb/YjP84bt1n1Ws4DqvDgv1XUwGoPv LvsunQuZN7N0YIKArWcp2Uo143IuSp+H4KZyO7T4fCfAukUJz4qgIQh8GvfAjsiuqdCq f96S/m+bbdGaieHX0m6Ymj892riau7qMRGn40NQjyWpx+QeHe2hvYGV7I7NCzKhJXo+I k+Fw==
X-Gm-Message-State: ALoCoQlw/FKGNxwCc88/w8cf/RiZ6m2djIywKqG0dzOkpdgda/mnVZn95CGq50dp3XHoUz7wez+c
X-Received: by 10.68.137.229 with SMTP id ql5mr1795159pbb.134.1424291304105; Wed, 18 Feb 2015 12:28:24 -0800 (PST)
Received: from [100.110.161.212] ([104.135.1.212]) by mx.google.com with ESMTPSA id di10sm21767621pad.41.2015.02.18.12.28.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Feb 2015 12:28:22 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-35FA6C8A-9802-426A-8F38-2B78D9A96686
Mime-Version: 1.0 (1.0)
From: John Bradley 
X-Mailer: iPhone Mail (12B466)
In-Reply-To: <06989626-BCCD-443B-AD5F-98436D681DB2@lodderstedt.net>
Date: Wed, 18 Feb 2015 12:28:21 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <0406F230-9B00-4B18-9AD9-03DAD41C2B1C@ve7jtb.com>
References: <54C7BBA4.4030702@gmx.net>  <2E3D2EE7-8F5F-452D-880A-D62A513AC853@lodderstedt.net> <54E370F9.8060209@gmx.net> <17faabb6e724fb54f3cb8060a3d9cb08@lodderstedt.net> <54E4B0AD.10801@gmx.net>  <54E4CCDD.6010709@gmx.net> <06989626-BCCD-443B-AD5F-98436D681DB2@lodderstedt.net>
To: Torsten Lodderstedt 
Archived-At: 
Cc: oauth , "naa@google.com >> Naveen Agarwal" 
Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 20:28:28 -0000

--Apple-Mail-35FA6C8A-9802-426A-8F38-2B78D9A96686
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

It was Google that wanted S256 to be mandatory for the AS to support.  That m=
akes it easier for the client.=20

S256 is relatively new so not being supported yet is not surprising.=20

Sent from my iPhone

> On Feb 18, 2015, at 12:15 PM, Torsten Lodderstedt  wrote:
>=20
> We don't plan to support s256=20
>=20
> Basically, I don't see a need to. Plain already mitigates the threat, spop=
/tcse had been designed to mitigate - an app intercepting the code response o=
f a public client.
>=20
> Am 18. Februar 2015 18:33:17 MEZ, schrieb Hannes Tschofenig :
>>=20
>> Thanks Brian for pointing me to Section 4.4.1 and to the MTI for "S256".
>> While this is good from a security point of view I am wondering whether
>> anyone is actually compliant to the specification. Neither PingIdentity
>> nor DT implements the S256 transform, if I understood that correctly.
>> Are you guys going planning to update your implementations?
>>=20
>> Ciao
>> Hannes
>>=20
>>> On 02/18/2015 05:45 PM, Brian Campbell wrote:
>>>  There's a bit of MTI talk tucked into
>>>  https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 that=

>>>  perhaps needs to be expanded and/or placed somewhere else.
>>> =20
>>>  On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig
>>>  >> > wrote:
>>> =20
>>>      Thanks for the info, Torsten.
>>> =20
>>>      Your feedback raises an interesting question, namely what functiona=
lity
>>>      the parties have to implement to claim conformance to the specifica=
tion.
>>> =20
>>>      Quickly scanning through the specification didn't tell me whether i=
t is
>>>      OK to just implement the plain mode or whether both modes are
>>>      mandatory-to-implement. We have to say something about this.
>>> =20
>>>      Ciao
>>>      Hannes
>>> =20
>>> =20
>>>      On 02/18/2015 02:16 PM, torsten@lodderstedt.net
>>>       wrote:
>>>>  Hi Hannes,
>>>>=20
>>>>  our implementation supports the "plain" mode only. We just verified
>>>>  compliance of our implementation with the current spec. As the only
>>>>  deviation, we do not enforce the
>>>> minimum length of 43 characters
>>>      of the
>>>>  code verifier.
>>>>=20
>>>>  kind regards,
>>>>  Torsten.
>>>>=20
>>>>  Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
>>>>>  Hi Torsten,
>>>>>=20
>>>>>  does this mean that your implementation is not compliant with the
>>>>>  current version anymore or that you haven't had time to verify
>>>      whether
>>>>>  there are differences to the earlier version?
>>>>>=20
>>>>>  Ciao
>>>>>  Hannes
>>>>>=20
>>>>>=20
>>>>>  On 01/31/2015 05:34 PM, Torsten
>>>>> Lodderstedt wrote:
>>>>>>  Deutsche Telekom also implemented an early version of the draft last=

>>>>>>  year.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>  Am 30.01.2015 um 18:50 schrieb Brian Campbell
>>>>>>  
>>>      >>      >>:
>>>>>>=20
>>>>>>>=20
>>>>>>>  On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
>>>>>>>  
>>>      >>      >> wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>      1) What implementations of the spec are you aware of?
>>>>>>>=20
>>>>>>>=20
>>>>>>>  We have an AS side implementation of an earlier draft that was
>>>>>>>  released in June of last year:
>>>      http://documentation.pingidentity.com/pages/viewpage.action?pageId=3D=
26706844
>>>>>>>=20
>>>>>>>=20
>>>>>>>  OAuth mailing list
>>>>>>>  OAuth@ietf.org  >>      >
>>>>>>>  https://www.ietf.org/mailman/listinfo/oauth
>=20
> --=20
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesende=
t.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-35FA6C8A-9802-426A-8F38-2B78D9A96686
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


It was Google that wanted S256 to be m=
andatory for the AS to support.  That makes it easier for the client.&n=
bsp;

S256 is relatively new so not being supported y=
et is not surprising. 

Sent from my iPhone

=
On Feb 18, 2015, at 12:15 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

We don't plan to support s256 



Basically, I don't see a need to. Plain already mitigates the threat, spop/t=
cse had been designed to mitigate - an app intercepting the code response of=
 a public client.

Am 18. Februar 2015 18:3=
3:17 MEZ, schrieb Hannes Tschofenig <hannes.tschofenig@gmx.net>:


Thanks Brian for pointing me to Section 4.4.1 and to t=
he MTI for "S256".
While this is good from a security point of view I am w=
ondering whether
anyone is actually compliant to the specification. Neith=
er PingIdentity
nor DT implements the S256 transform, if I understood tha=
t correctly.
Are you guys going planning to update your implementations?<=
br>
Ciao
Hannes

On 02/18/2015 05:45 PM, Brian Campbell wrote:
 There's a bit of MTI talk t=
ucked into
 https://tools.ietf.org/html/draft-ietf-oauth-spop-10#secti=
on-4.4.1 that
 perhaps needs to be expanded and/or placed somewhere e=
lse.
 
 On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig
 <hannes.tschofenig@gmx.net
<mailto:hannes.tschofenig@gm=
x.net>> wrote:
 
     Thanks for the info, Torsten.
 
=
     Your feedback raises an interesting question, namely what functionality=

     the parties have to implement to claim conformance to the specifica=
tion.
 
     Quickly scanning through the specification didn't tell me=
 whether it is
     OK to just implement the plain mode or whether both m=
odes are
     mandatory-to-implement. We have to say something about this=
.
 
     Ciao
     Hannes
 
 
     On 02/18/2015 02:16 PM,=
 torsten@lodderstedt.net
 =
    <mailto:torsten@loddersted=
t.net> wrote:
 Hi Ha=
nnes,

 our implementation supports the "plain" mode only. We just ver=
ified
 compliance of our implementation with the current spec. As the onl=
y
 deviation, we do not enforce the
minimum length of 43 characters
     of the
 code verifier.

 kind regards,
 T=
orsten.

 Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
 Hi Torsten,

 does this mean tha=
t your implementation is not compliant with the
 current version anymore o=
r that you haven't had time to verify
     whet=
her
 there are differences to the earlier version?
 Ciao
 Hannes


 On 01/31/2015 05:34 PM, Torsten
Lodderstedt wrote:
 Deutsch=
e Telekom also implemented an early version of the draft last
 year.
<=
br>

 Am 30.01.2015 um 18:50 schrieb Brian Campbell
 <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>
     <mailto:bcampbell@pingidentity.com
     &l=
t;mailto:bcampbell@pingidentit=
y.com>>>:


 On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
 <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>
     <mailto:hannes.tschofenig@gmx.net<=
br>     <mailto:hannes.tscho=
fenig@gmx.net>>> wrote:

=

     1) What implementations of the spec are you aware of?


 W=
e have an AS side implementation of an earlier draft that was
 released i=
n June of last year:

=
     http://documentation.pingidentity.com/pages/viewpage.acti=
on?pageId=3D26706844


 OAu=
th mailing list
 OAuth@ietf.org <=
;mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
     <m=
ailto:OAuth@ietf.org>>
<=
blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0.8ex; border-=
left: 1px solid #fcaf3e; padding-left: 1ex;">
 http=
s://www.ietf.org/mailman/listinfo/oauth
 
 

<=
br>
-- 

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.=

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

--Apple-Mail-35FA6C8A-9802-426A-8F38-2B78D9A96686--


From nobody Wed Feb 18 13:45:51 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087D01A1AFB for ; Wed, 18 Feb 2015 13:45:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-3ryAa_T7ZH for ; Wed, 18 Feb 2015 13:45:48 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625151A1AE2 for ; Wed, 18 Feb 2015 13:45:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8042D20614; Wed, 18 Feb 2015 16:44:58 -0500 (EST)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozmkaq92Kgky; Wed, 18 Feb 2015 16:44:58 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (gain1-180.nortex.net [63.160.158.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 18 Feb 2015 16:44:57 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A3F698081B; Wed, 18 Feb 2015 16:45:06 -0500 (EST)
From: Sam Hartman 
To: Kathleen Moriarty 
References: 
Date: Wed, 18 Feb 2015 16:45:06 -0500
In-Reply-To:  (Kathleen Moriarty's message of "Wed, 11 Feb 2015 18:06:51 -0500")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 21:45:50 -0000

>>>>> "Kathleen" == Kathleen Moriarty  writes:

    Kathleen> registry, but setting HTTP Basic as the default seems like
    Kathleen> a really bad choice. HOBA is on it's way to becoming an
    Kathleen> RFC from the HTTPAuth working group.  HTTPAuth also has an
    Kathleen> updated version of Basic that is in IETF last call, but I
    Kathleen> know you are pointing to the OAuth 2.0 document, so it
    Kathleen> would be that document that gets updated and not this
    Kathleen> draft.  The new version of HTTP Basic fixes some
    Kathleen> internationalization problems and spells out the security
    Kathleen> issues much more clearly, so it probably doesn't matter
    Kathleen> too much to update the reference, but maybe makes it more
    Kathleen> clear that basic is not a secure form of authentication.
    Kathleen> Can you provide some justification as to why this is okay
    Kathleen> to set basic as the default and add that to the draft?
    Kathleen> Section 2.3.1 of OAuth 2.0 just says this MUST be
    Kathleen> implemented, but that any HTTP schemes can be used.  Why
    Kathleen> not register another method and use that instead as the
    Kathleen> default?  You could use digest and there is library
    Kathleen> support.  It's not a great answer, but slightly better
    Kathleen> than passwords with basic.  You could register HOBA and
    Kathleen> use that instead, the only downside is limited library
    Kathleen> support at the moment.  


I'm disappointed to be reading the above, particularly the last
sentence, today.
I'd hope that we'd have a better wide-spread understanding of the issues
in deploying credentials by this point.

Yes, you absolutely can choose whatever you like as the authentication
scheme for a single-use account.  If my account will only be used with a
particularly dynamically registration then I probably can get away with
choosing whatever I want as a default authentication and statements like
"the only down-side will be limited library availability," will be true.

However, a lot of deployments re-use accounts.  That is, the
deploymentwill allow some form of single sign-on.  The same account may
be used for an oauth dynamic registration as well as a bunch of other
things.
Even more of an issue, the backend database of credentials may already
exist and may not be defined by this particular application.

Digest is absolutely impossible to use if I've got a database of  NTLM
hashes (read Active Directory) that are my credentials.  (In the
particular case of AD and digest, you probably have a solution if you
are using Microsoft's implementation.)
However, if I've got some relational (or nosql) database storing hashes
that  I've been accumulating as I sign up users for the last few years,
I can only use authentication schemes compatible with those hashes.


The huge deployment advantage of basic is that if you present me the
password, I can match against whatever I have on the backend.  I can try
various normalizations, try code-page conversions, rehash, whatever.
If your client implements scram, and I have NTLM, we're never going to
be able to talk.  Me implementing scram doesn't help if that's not how
I've got credentials stored.

Put another way, end protocols like this are not the right place to
fight passwords.  You transition credential technologies at the
deployment level, not at the protocol level.

For interoperability in something like this we're likely going to do no
better than basic.  Anything else from httpauth will fall squarely into
the category of MUST BUT WE KNOW YOU WON't for some significant
deployments.

What I've said above doesn't apply particularly to protocols where the
credentials will not be reused.

I'd be happy to talk some time about strategies for giving deployments
the tools they need to move their credential interface away from
passwords, but it does need to be thought of as a deployment issue
crossing all the applications and protocols that a set of credentials
use.  This is the wrong place to fight that battle.

--Sam


From nobody Wed Feb 18 14:02:43 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DEC1A1B0C for ; Wed, 18 Feb 2015 14:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyeAapeYV4PG for ; Wed, 18 Feb 2015 14:02:39 -0800 (PST)
Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B2A1A1AE2 for ; Wed, 18 Feb 2015 14:02:39 -0800 (PST)
Received: by labpn19 with SMTP id pn19so4120046lab.4 for ; Wed, 18 Feb 2015 14:02:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fk3GHDVDN9rmJfXC9dkJzBPiZ7/cUpPcLZgJ2qdz+S0=; b=m4IcUhto1m3pfRF8+IGegH9XSdYoqw9AI+4KJCv8edangFdNxNMCuWavTFD69fvA61 hWFEnjDLW4L8wsg/AralmhStqDNEajtfZKnO+T4bqWJoHhQPf/ltxgpAgMeLKpJF2DO8 llH2XNGTcwo/T1aKrhCZYPPmJ+FmxbncDvq4q1wWStsc1+LLrDxQ7I/BQHoOXrMx+Nfq jGsHrOUPh4rcIRzY6ErtVThHsv135nEZg4S1ERruQ0hQxH9xxPmnYi3U7uJlbscBSkFh jKJcMyBXga2YxbicmQYcIc4leIv0LPC0K2LG2/xtmE+1LtmrjpyqqbumRAj0QXzTlfxb ofGA==
MIME-Version: 1.0
X-Received: by 10.112.181.41 with SMTP id dt9mr1450871lbc.56.1424296957362; Wed, 18 Feb 2015 14:02:37 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Wed, 18 Feb 2015 14:02:37 -0800 (PST)
In-Reply-To: 
References:  
Date: Wed, 18 Feb 2015 17:02:37 -0500
Message-ID: 
From: Kathleen Moriarty 
To: Sam Hartman 
Content-Type: multipart/alternative; boundary=001a11c3698632c750050f63fa97
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Feb 2015 22:02:42 -0000

--001a11c3698632c750050f63fa97
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 18, 2015 at 4:45 PM, Sam Hartman  wrote:

> >>>>> "Kathleen" == Kathleen Moriarty 
> writes:
>
>     Kathleen> registry, but setting HTTP Basic as the default seems like
>     Kathleen> a really bad choice. HOBA is on it's way to becoming an
>     Kathleen> RFC from the HTTPAuth working group.  HTTPAuth also has an
>     Kathleen> updated version of Basic that is in IETF last call, but I
>     Kathleen> know you are pointing to the OAuth 2.0 document, so it
>     Kathleen> would be that document that gets updated and not this
>     Kathleen> draft.  The new version of HTTP Basic fixes some
>     Kathleen> internationalization problems and spells out the security
>     Kathleen> issues much more clearly, so it probably doesn't matter
>     Kathleen> too much to update the reference, but maybe makes it more
>     Kathleen> clear that basic is not a secure form of authentication.
>     Kathleen> Can you provide some justification as to why this is okay
>     Kathleen> to set basic as the default and add that to the draft?
>     Kathleen> Section 2.3.1 of OAuth 2.0 just says this MUST be
>     Kathleen> implemented, but that any HTTP schemes can be used.  Why
>     Kathleen> not register another method and use that instead as the
>     Kathleen> default?  You could use digest and there is library
>     Kathleen> support.  It's not a great answer, but slightly better
>     Kathleen> than passwords with basic.  You could register HOBA and
>     Kathleen> use that instead, the only downside is limited library
>     Kathleen> support at the moment.
>
>
> I'm disappointed to be reading the above, particularly the last
> sentence, today.
> I'd hope that we'd have a better wide-spread understanding of the issues
> in deploying credentials by this point.
>
> Yes, you absolutely can choose whatever you like as the authentication
> scheme for a single-use account.  If my account will only be used with a
> particularly dynamically registration then I probably can get away with
> choosing whatever I want as a default authentication and statements like
> "the only down-side will be limited library availability," will be true.
>
> However, a lot of deployments re-use accounts.  That is, the
> deploymentwill allow some form of single sign-on.  The same account may
> be used for an oauth dynamic registration as well as a bunch of other
> things.
> Even more of an issue, the backend database of credentials may already
> exist and may not be defined by this particular application.
>
> Digest is absolutely impossible to use if I've got a database of  NTLM
> hashes (read Active Directory) that are my credentials.  (In the
> particular case of AD and digest, you probably have a solution if you
> are using Microsoft's implementation.)
> However, if I've got some relational (or nosql) database storing hashes
> that  I've been accumulating as I sign up users for the last few years,
> I can only use authentication schemes compatible with those hashes.
>
>
> The huge deployment advantage of basic is that if you present me the
> password, I can match against whatever I have on the backend.  I can try
> various normalizations, try code-page conversions, rehash, whatever.
> If your client implements scram, and I have NTLM, we're never going to
> be able to talk.  Me implementing scram doesn't help if that's not how
> I've got credentials stored.
>
> Put another way, end protocols like this are not the right place to
> fight passwords.  You transition credential technologies at the
> deployment level, not at the protocol level.
>
> For interoperability in something like this we're likely going to do no
> better than basic.  Anything else from httpauth will fall squarely into
> the category of MUST BUT WE KNOW YOU WON't for some significant
> deployments.
>
> What I've said above doesn't apply particularly to protocols where the
> credentials will not be reused.
>
> I'd be happy to talk some time about strategies for giving deployments
> the tools they need to move their credential interface away from
> passwords, but it does need to be thought of as a deployment issue
> crossing all the applications and protocols that a set of credentials
> use.  This is the wrong place to fight that battle.
>

Sam,

You may have missed part of the thread.  I did not ask the WG to fix it
here, just noted that I don't like that passwords is the best that we can
do and there is no other more secure option registered.  The WG will take a
look at this and see if other options are feasible.  An approach Justin is
working on was provided, but I haven't had time to read that yet.  If
something gets done, it was already agreed that it would be in a separate
draft, I did not ask for it to be done here.

Thanks,
Kathleen

>
> --Sam
>



-- 

Best regards,
Kathleen

--001a11c3698632c750050f63fa97
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Feb 18, 2015 at 4:45 PM, Sam Hartman <hartmans-ietf@mit.ed=
u> wrote:
>>>>&=
gt; "Kathleen" =3D=3D Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wri=
tes:



=C2=A0 =C2=A0 Kathleen> registry, but setting HTTP Basic as the default =
seems like

=C2=A0 =C2=A0 Kathleen> a really bad choice. HOBA is on it's way to =
becoming an

=C2=A0 =C2=A0 Kathleen> RFC from the HTTPAuth working group.=C2=A0 HTTPA=
uth also has an

=C2=A0 =C2=A0 Kathleen> updated version of Basic that is in IETF last ca=
ll, but I

=C2=A0 =C2=A0 Kathleen> know you are pointing to the OAuth 2.0 document,=
 so it

=C2=A0 =C2=A0 Kathleen> would be that document that gets updated and not=
 this

=C2=A0 =C2=A0 Kathleen> draft.=C2=A0 The new version of HTTP Basic fixes=
 some

=C2=A0 =C2=A0 Kathleen> internationalization problems and spells out the=
 security

=C2=A0 =C2=A0 Kathleen> issues much more clearly, so it probably doesn&#=
39;t matter

=C2=A0 =C2=A0 Kathleen> too much to update the reference, but maybe make=
s it more

=C2=A0 =C2=A0 Kathleen> clear that basic is not a secure form of authent=
ication.

=C2=A0 =C2=A0 Kathleen> Can you provide some justification as to why thi=
s is okay

=C2=A0 =C2=A0 Kathleen> to set basic as the default and add that to the =
draft?

=C2=A0 =C2=A0 Kathleen> Section 2.3.1 of OAuth 2.0 just says this MUST b=
e

=C2=A0 =C2=A0 Kathleen> implemented, but that any HTTP schemes can be us=
ed.=C2=A0 Why

=C2=A0 =C2=A0 Kathleen> not register another method and use that instead=
 as the

=C2=A0 =C2=A0 Kathleen> default?=C2=A0 You could use digest and there is=
 library

=C2=A0 =C2=A0 Kathleen> support.=C2=A0 It's not a great answer, but =
slightly better

=C2=A0 =C2=A0 Kathleen> than passwords with basic.=C2=A0 You could regis=
ter HOBA and

=C2=A0 =C2=A0 Kathleen> use that instead, the only downside is limited l=
ibrary

=C2=A0 =C2=A0 Kathleen> support at the moment.





I'm disappointed to be reading the above, particularly the last

sentence, today.

I'd hope that we'd have a better wide-spread understanding of the i=
ssues

in deploying credentials by this point.



Yes, you absolutely can choose whatever you like as the authentication

scheme for a single-use account.=C2=A0 If my account will only be used with=
 a

particularly dynamically registration then I probably can get away with

choosing whatever I want as a default authentication and statements like
"the only down-side will be limited library availability," will b=
e true.



However, a lot of deployments re-use accounts.=C2=A0 That is, the

deploymentwill allow some form of single sign-on.=C2=A0 The same account ma=
y

be used for an oauth dynamic registration as well as a bunch of other

things.

Even more of an issue, the backend database of credentials may already

exist and may not be defined by this particular application.



Digest is absolutely impossible to use if I've got a database of=C2=A0 =
NTLM

hashes (read Active Directory) that are my credentials.=C2=A0 (In the

particular case of AD and digest, you probably have a solution if you

are using Microsoft's implementation.)

However, if I've got some relational (or nosql) database storing hashes=


that=C2=A0 I've been accumulating as I sign up users for the last few y=
ears,

I can only use authentication schemes compatible with those hashes.





The huge deployment advantage of basic is that if you present me the

password, I can match against whatever I have on the backend.=C2=A0 I can t=
ry

various normalizations, try code-page conversions, rehash, whatever.

If your client implements scram, and I have NTLM, we're never going to<=
br>
be able to talk.=C2=A0 Me implementing scram doesn't help if that's=
 not how

I've got credentials stored.



Put another way, end protocols like this are not the right place to

fight passwords.=C2=A0 You transition credential technologies at the

deployment level, not at the protocol level.



For interoperability in something like this we're likely going to do no=


better than basic.=C2=A0 Anything else from httpauth will fall squarely int=
o

the category of MUST BUT WE KNOW YOU WON't for some significant

deployments.



What I've said above doesn't apply particularly to protocols where =
the

credentials will not be reused.



I'd be happy to talk some time about strategies for giving deployments<=
br>
the tools they need to move their credential interface away from

passwords, but it does need to be thought of as a deployment issue

crossing all the applications and protocols that a set of credentials

use.=C2=A0 This is the wrong place to fight that battle.

Sam,

You may have missed part of=
 the thread.=C2=A0 I did not ask the WG to fix it here, just noted that I d=
on't like that passwords is the best that we can do and there is no oth=
er more secure option registered.=C2=A0 The WG will take a look at this and=
 see if other options are feasible.=C2=A0 An approach Justin is working on =
was provided, but I haven't had time to read that yet.=C2=A0 If somethi=
ng gets done, it was already agreed that it would be in a separate draft, I=
 did not ask for it to be done here.

Thanks,
=

Kathleen=C2=A0



--Sam





-- 

Best regards,
Kathleen




--001a11c3698632c750050f63fa97--


From nobody Thu Feb 19 00:40:41 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CF51A1BA3 for ; Thu, 19 Feb 2015 00:40:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FlqjIOv-6pR for ; Thu, 19 Feb 2015 00:40:38 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF041A1B76 for ; Thu, 19 Feb 2015 00:40:38 -0800 (PST)
Received: from [192.168.131.130] ([80.92.119.127]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LpbfG-1Xstzp2ye6-00fRT0; Thu, 19 Feb 2015 09:40:35 +0100
Message-ID: <54E5A0EE.70309@gmx.net>
Date: Thu, 19 Feb 2015 09:38:06 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Security Developer , oauth@ietf.org,  ve7jtb@ve7jtb.com
References: 
In-Reply-To: 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NMROj0iRkM75MwfHJ1DkJaaCfusdlL93f"
X-Provags-ID: V03:K0:JkYOPmnBaUv9jTUZbb7aMqFQppuj41bGyByR6WyeYvVmswvRxic /8a/9Hg0wQCU2mzalF3XYETkx4Pw8GwZ2wdsrFohIl2hbqMPqxIYMxDn83SZhiclJxuLuyl J8EviisDiCovx9UCe+qTXivy9l4JshDd3kG5GTFae3u/xeLpHIb/+4rcEyK/rPfLvibY9W2 KIPHaNFq4w1LSXvm0O7Jw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth POP query
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Feb 2015 08:40:40 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--NMROj0iRkM75MwfHJ1DkJaaCfusdlL93f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Sorry for the late reply.

For the PoP architecture document we initiated the WGLC last year and a
new document has to be submitted to address those comments. I believe
then it is ready for the IESG.

The WGLC for the draft-ietf-oauth-proof-of-possession-00 should be
started next. Maybe already this week since we are doing OK with some of
our other documents.

The weakest part of the story at the moment is the
draft-ietf-oauth-signed-http-request-00 document. For this we obviously
need input from the group.

On 02/14/2015 12:40 PM, Security Developer wrote:
> Hi,
>=20
> I have a couple of questions.
>=20
> 1- What is the status of these documents as I am interested in
> implementing POP
>=20
> draft-ietf-oauth-pop-architecture-00.pdf
> draft-ietf-oauth-pop-key-distribution-00.pdf
> draft-ietf-oauth-proof-of-possession-00.pdf
> draft-ietf-oauth-signed-http-request-00.pdf
>=20
> 2- Should Authorization server restrict the number of authorization
> codes issued to a single user after successful authentication and
> authorization in OAuth? also What is the good practice in this case?
>=20
> Thanks for your time.
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


--NMROj0iRkM75MwfHJ1DkJaaCfusdlL93f
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJU5aDuAAoJEGhJURNOOiAtcBQIAKBCClDghZGFMkoomIxyWeAR
UtnL57JnAfcWEdo2sDYNaBUCsqLWAonpLBqVcyfnVyewU3ETGntYY8DtQpoWPzM5
hMrH9mKi1pFpvBAgFxnDZYwRuVqmxM9f/4UkI+54KuuOmfCE7HFrUW9q5cPdoR1M
n+P45Hfd/cW8X5THoQS0L0ZCGzMZfP2hFYdWzn6JDzA/D764NgXXEYwC5DKUsTxJ
lpiGlrvxY4+XBEuOITLfGxdfA8NvzNz0jtIsAVCAOxiu/Ao7dpHcMkSUQwDo5+va
tSThfwt0Z/RnIoIQFf2UrT+t8eM8lDSVa9fMiXnafLTc9xOH9LYI07U4+XAzBmE=
=bjfp
-----END PGP SIGNATURE-----

--NMROj0iRkM75MwfHJ1DkJaaCfusdlL93f--


From nobody Thu Feb 19 03:14:36 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC52A1A888F for ; Thu, 19 Feb 2015 03:14:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level: 
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2baU6c0GT8UV for ; Thu, 19 Feb 2015 03:14:29 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0665.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:665]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792591A8728 for ; Thu, 19 Feb 2015 03:14:28 -0800 (PST)
Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (25.161.203.148) by BY1PR0201MB1032.namprd02.prod.outlook.com (25.161.203.15) with Microsoft SMTP Server (TLS) id 15.1.87.18; Thu, 19 Feb 2015 11:14:06 +0000
Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([25.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([25.161.203.148]) with mapi id 15.01.0087.013; Thu, 19 Feb 2015 11:14:06 +0000
From: Antonio Sanso 
To: John Bradley 
Thread-Topic: [OAUTH-WG] Confusion on Implicit Grant flow
Thread-Index: AdBCU7lczcAZFshKSMOM30KEynNz8AAAdauAAJOOJYAAAFyKAAABMZ+AAABwzQAAAKRcgAAAWbWAACbHsZAAAmPmgAG4d58A
Date: Thu, 19 Feb 2015 11:14:06 +0000
Message-ID: <593558AD-A621-4734-B4E1-55345E3C3D96@adobe.com>
References:   <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com>  <54D924CB.6070504@oracle.com> <3B0DDA4D-F540-4E23-9842-275532F7405F@ve7jtb.com>  <5078C62F-DB84-435E-858E-D72013BE6BBA@ve7jtb.com>
In-Reply-To: <5078C62F-DB84-435E-858E-D72013BE6BBA@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.147.117.11]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; 
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1032;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1032; 
x-forefront-prvs: 0492FD61DD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(129404003)(24454002)(189002)(54094003)(479174004)(199003)(122556002)(76176999)(33656002)(19580395003)(16601075003)(87936001)(106356001)(16236675004)(54356999)(40100003)(97736003)(46102003)(99286002)(82746002)(50986999)(86362001)(19580405001)(93886004)(2950100001)(64706001)(83716003)(105586002)(36756003)(102836002)(2656002)(62966003)(110136001)(19617315012)(101416001)(587094005)(2900100001)(68736005)(92566002)(15975445007)(66066001)(77156002)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1032; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_593558ADA6214734B4E155345E3C3D96adobecom_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2015 11:14:06.0243 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1032
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Feb 2015 11:14:34 -0000

--_000_593558ADA6214734B4E155345E3C3D96adobecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I wonder if the spec would have contained POST + 307 response rather than a=
 GET+302 with fragment for the implicit grant would have been safer=85..

At least the risk of fragment leakage would have been lower...

regards

antonio


On Feb 10, 2015, at 6:10 PM, John Bradley > wrote:

Inline
On Feb 10, 2015, at 1:12 PM, Adam Lewis > wrote:

Hi John,

What do you mean by the app that is =93already loaded and cached in the bro=
wser?=94  Where did this app come from initially?  Is this what comes from =
the web-hosted client resource in step D/E of section 4.2?  So the first ti=
me D/E *will* flow over the wire, and in all subsequent requests it will be=
 cached?

Yes the web hosted client resource is typically the same JS code that is cr=
eating the Authorization request in A.   Now that you mention it the diagra=
m in 4.2 is ambiguous about where that request comes from , the fact that i=
t is coming from the browser implies that it is a JS CORS type request.

In some cases you might have a webserver invoke it via a 302 redirect and l=
oad a new JS app from the redirect URI.

The important thing is that the fragment is not sent to the server on the c=
all that loads the JS even if it is not cached.

The thing people do (facebook and others) that is twisting implicit in my o=
pinion is having the callback URI just load a JS snipppet that extracts the=
 token and posts it back to =93Web hosted client resource=94
Those applications should be using the code flow.



And with respect to the web hosted client resource, is this a resource depl=
oyed by the same domain as the RS to facilitate the deployment of user-agen=
t-based apps to access the APIs exposed by that RS?

The hosted client resource is typically a AJAX/AngularJS application that d=
oesn=92t want to swap out it=92s context by doing a full 302 redirect to th=
e AS.

The AS and RS could be completely separate from the client.

However it is not uncommon for people developing AngularJS apps to protect =
the API that they use with OAuth, in that case they may all be from the sam=
e domain.

It might be that a sophisticated app may have multiple tokens for different=
 API across multiple providers.

John B.


adam

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Monday, February 09, 2015 3:31 PM
To: Prateek Mishra
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow

Typically the implicit callback JS is part of the application that is alrea=
dy loaded and cached in the browser.

The implicit flow doesn=92t depend on on the fragment not being re-appended=
 to the resource location URI in the 302.  It would admittedly be more secu=
re if that didn=92t happen.
Re-appending the fragment is the correct browser behaviour according to the=
 W3C.

I still think you are farther ahead with that than leaking the code in the =
referrer.

Implicit if done correctly has the token in one leg.  code on the other han=
d has the code in 4 legs and the token in one.

It is having the JS make the exchange of code for the AT without a secret t=
hat is the problem in my opinion.

If the client is a server that is doing the code -> token exchange then the=
 answer is different, but the question was for a JS only client.

John B.


On Feb 9, 2015, at 6:21 PM, Prateek Mishra > wrote:

The implicit flow depends upon a subtle and little known aspect of browser =
behavior - that the URI fragment component isn't propagated across redirect=
s.

I havent checked this recently - but I am aware that several folks have fou=
nd that some browser versions dont comply with this requirement.
http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-w=
ith-oauth-2

The additional round-trip issue is also unclear. The implicit flow requires=
 an additional redirect (round-trip) to retrieve JS which retrieves the acc=
ess token from the fragment URI.

How is that different from a HTTPs callback to exchange the access code for=
 the access token?

- prateek



You are passing code in a query parameter, and without a secret that is mor=
e likely to be leaked than sending token in the fragment directly from the =
authorization endpoint to the browser JS in a fragment.



You have several extra round trips for no security benefit.   In your case =
the code in the query parameter goes from the browser to the redirect endpo=
int then must be sent back to the browser, and then to the token endpoint.



So yes using code for that is less secure.



Both rely solely on the registered redirect URI for security, but implicit =
has fewer hopes and is more friendly to JS.



John B.

On Feb 9, 2015, at 5:50 PM, Bill Burke  wrote:



If you don't have a client secret, why is Javascript-based auth code grant =
flow more risky?  We also require SSL and valid redirect URI patterns to be=
 registered for the application.  The code can only ever be sent to specifi=
c URLs and can only be used once.  CORS origin validation is also an extra =
step we do to ensure a rogue javascript app isn't making any code-to-token =
requests.



I'm just trying to figure out if we missed anything...



On 2/9/2015 3:16 PM, John Bradley wrote:

If you don't have a client secret, or are storing the the client secret in =
the Javascrypt, then you are probably more at risk using code than implicit=
.



Implicit is risky because running a OAuth client in the browser is risky.  =
Using code in that case makes it no better, and arguably worse.



Perhaps I don't understand the environment.



John B.



On Feb 9, 2015, at 5:05 PM, Bill Burke  wrote:



Due to the security risks of implicit Grant flow, our Javascript adapter on=
ly supports  Auth Code Grant flow.  Our IDP has an extra step of allowing y=
ou to specify a valid CORS origin for an application.  Anybody see any prob=
lems with this kind of approach?  Implicit Grant Flow just seemed really ri=
sky to even support as a protocol.





On 2/6/2015 4:40 PM, Josh Mandel wrote:

Hi Adam,



I'm not 100% sure what you're envisioning as an alternative to the

implicit flow, but if I'm reading between the lines of your question

correctly, there are two key parts to the answer, because the implicit

flow is designed to accomplish two key goals (vs. the authorization code

grant):



1. Shave off one round-trip HTTP request (the step of exchanging a code

for a token)

2. Avoid unnecessarily leading the token to the client's back-end web serve=
r



Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes

advantage of the fact that a URL's "#hash" is not sent to the server

with an HTTP request. By embedding the token in a "#hash", it won't

inadvertently appear in server logs, for example. So with the implicit

flow, I can (for example) statically host a browser-based app at Amazon

S3 without having access tokens leak to Amazon. (Of course, if your

threat model includes a compromised server, then bets are off on this

point.)



Hope this helps,



  -Josh







On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis



> wrote:



   Hi,____



   __ __



   Having spent most of my time with native apps and web apps, I now am

   looking at use cases where I need to implement a user-agent-based

   app.  The Implicit flow seems to be optimized for this.____



   __ __



   To test my understanding, this flow is for a JavaScript client (or

   similar) executing within a web browser.____



   __ __



   At step (a) the client directs the UA to the authorization server,

   but the authorization server redirects the UA to a web-hosted client

   resource.  Why?  It says so that the web-hosted client resources can

   push javascript (or other) back into the UA so it can extract the

   access token in the fragment; but some sort of javascript is already

   running in the browser, since it initiated the authorization request

   in the first place.  So why this extra step?  Why not treat the

   javascript client running in the UA like a native app and handle the

   redirect uri?____



   __ __



   I know this was well thought out when the spec was written, so

   trying to figure out what I=92m missing?____



   __ __



   __ __



   __ __



   Tx!

   adam____





   _______________________________________________

   OAuth mailing list

   OAuth@ietf.org 

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









_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



--

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

--

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com




_______________________________________________

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


--_000_593558ADA6214734B4E155345E3C3D96adobecom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <9C100F463E274B45B6CA1C94F7049963@namprd02.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable






I wonder if the spec would have contained POST + 307 response rather th=
an a GET+302 with fragment for the implicit grant would have been safer=
=85..






At least the risk of fragment leakage would have been lower... 






regards







antonio












On Feb 10, 2015, at 6:10 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:







Inline






On Feb 10, 2015, at 1:12 PM, Adam Lewis <Adam.Lewis@motorolasolution=
s.com> wrote:









Hi John,



 



What do you mean by the app that is =93already =
loaded and cached in the browser?=94  Where did this app come from ini=
tially?  Is this what comes from the web-hosted
 client resource in step D/E of section 4.2?  So the first time D/E *<=
b class=3D"">will* flow over the wire, and in all subsequent requests i=
t will be cached? 












Yes the web hosted client resource is typically the same JS code that is cr=
eating the Authorization request in A.   Now that you mention it the d=
iagram in 4.2 is ambiguous about where that request comes from , the fact t=
hat it is coming from the browser implies
 that it is a JS CORS type request.







In some cases you might have a webserver invoke it via a 302 redirect =
and load a new JS app from the redirect URI.


 


The important thing is that the fragment is not sent to the server on =
the call that loads the JS even if it is not cached.  







The thing people do (facebook and others) that is twisting implicit in=
 my opinion is having the callback URI just load a JS snipppet that extract=
s the token and posts it back to =93Web hosted client resource=94


Those applications should be using the code flow. 





















 



And with respect to the web hosted client resou=
rce, is this a resource deployed by the same domain as the RS to facilitate=
 the deployment of user-agent-based
 apps to access the APIs exposed by that RS?












The hosted client resource is typically a AJAX/AngularJS application that d=
oesn=92t want to swap out it=92s context by doing a full 302 redirect to th=
e AS.  







The AS and RS could be completely separate from the client.







However it is not uncommon for people developing AngularJS apps to pro=
tect the API that they use with OAuth, in that case they may all be from th=
e same domain.







It might be that a sophisticated app may have multiple tokens for diff=
erent API across multiple providers.







John B.













 



 



adam



 







From:&nb=
sp;OAuth [mailt=
o:oauth-bounces@ietf.org] On
 Behalf Of John Bradl=
ey

Sent: M=
onday, February 09, 2015 3:31 PM

To: Pra=
teek Mishra

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow







 



Typically the implicit callback JS is part of the application that is alrea=
dy loaded and cached in the browser.





 







The implicit flow doesn=92t depend on on the fragment not being re-appended=
 to the resource location URI in the 302.  It would admittedly be more=
 secure if that didn=92t happen.  







Re-appending the fragment is the correct browser behaviour according to the=
 W3C.







 







I still think you are farther ahead with that than leaking the code in the =
referrer.







 







Implicit if done correctly has the token in one leg.  code on the othe=
r hand has the code in 4 legs and the token in one.






 







It is having the JS make the exchange of code for the AT without a secret t=
hat is the problem in my opinion.







 







If the client is a server that is doing the code -> token exchange then =
the answer is different, but the question was for a JS only client.







 







John B.







 







 













On Feb 9, 2015, at 6:21 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:





 







The implicit flow depends upon a subtle and little known aspect of browser =
behavior - that the URI fragment component isn't propagated across redirect=
s. 



I havent checked this recently - but I am aware that several folks have fou=
nd that some browser versions dont comply with this requirement.

http://weblog.bulknews.net/post/85008516879/covert-redirect-vu=
lnerability-with-oauth-2



The additional round-trip issue is also unclear. The implicit flow requires=
 an additional redirect (round-trip) to retrieve JS which retrieves the acc=
ess token from the fragment URI. =
;



How is that different from a HTTPs callback to exchange the access code for=
 the access token?



- prateek








You are passing code in a query parameter, and withou=
t a secret that is more likely to be leaked than sending token in the fragm=
ent directly from the authorization endpoint to the browser JS in a fragmen=
t.


 


You have several extra round trips for no security be=
nefit.   In your case the code in the query parameter goes from t=
he browser to the redirect endpoint then must be sent back to the browser, =
and then to the token endpoint.


 


So yes using code for that is less secure.


 


Both rely solely on the registered redirect URI for s=
ecurity, but implicit has fewer hopes and is more friendly to JS.


 


John B.




On Feb 9, 2015, at 5:50 PM, Bill Burke <bburke@redhat.com> wrote:

 


If you don't have a client secret, why is Javascript-=
based auth code grant flow more risky?  We also require SSL and valid =
redirect URI patterns to be registered for the application.  The code =
can only ever be sent to specific URLs and can only be used once.  COR=
S origin validation is also an extra step we do to ensure a rogue javascrip=
t app isn't making any code-to-token requests.


 


I'm just trying to figure out if we missed anything..=
.


 


On 2/9/2015 3:16 PM, John Bradley wrote:




If you don't have a client secret, or are storing the=
 the client secret in the Javascrypt, then you are probably more at risk us=
ing code than implicit.


 


Implicit is risky because running a OAuth client in t=
he browser is risky.  Using code in that case makes it no better, and =
arguably worse.


 


Perhaps I don't understand the environment.


 


John B.


 




On Feb 9, 2015, at 5:05 PM, Bill Burke <bburke@redhat.com> wrote:

 


Due to the security risks of implicit Grant flow, our=
 Javascript adapter only supports  Auth Code Grant flow.  Our IDP=
 has an extra step of allowing you to specify a valid CORS origin for an ap=
plication.  Anybody see any problems with this kind of approach? =
 Implicit Grant Flow just seemed really risky to even support as a protocol=
.


 


 


On 2/6/2015 4:40 PM, Josh Mandel wrote:




Hi Adam,


 


I'm not 100% sure what you're envisioning as an alter=
native to the


implicit flow, but if I'm reading between the lines o=
f your question


correctly, there are two key parts to the answer, bec=
ause the implicit


flow is designed to accomplish two key goals (vs. the=
 authorization code


grant):


 


1. Shave off one round-trip HTTP request (the step of=
 exchanging a code


for a token)


2. Avoid unnecessarily leading the token to the clien=
t's back-end web server


 


Goal 1 is straightforward. For goal 2: OAuth2's impli=
cit flow takes


advantage of the fact that a URL's "#hash" =
is not sent to the server


with an HTTP request. By embedding the token in a &qu=
ot;#hash", it won't


inadvertently appear in server logs, for example. So =
with the implicit


flow, I can (for example) statically host a browser-b=
ased app at Amazon


S3 without having access tokens leak to Amazon. (Of c=
ourse, if your


threat model includes a compromised server, then bets=
 are off on this


point.)


 


Hope this helps,


 


  -Josh


 


 


 


On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis


<Adam.Lew=
is@motorolasolutions.com


<mailto:A=
dam.Lewis@motorolasolutions.com>> wrote:

 


   Hi,____


 


   __ __


 


   Having spent most of my time with native=
 apps and web apps, I now am


   looking at use cases where I need to imp=
lement a user-agent-based


   app.  The Implicit flow seems to be=
 optimized for this.____


 


   __ __


 


   To test my understanding, this flow is f=
or a JavaScript client (or


   similar) executing within a web browser.=
____


 


   __ __


 


   At step (a) the client directs the UA to=
 the authorization server,


   but the authorization server redirects t=
he UA to a web-hosted client


   resource.  Why?  It says so th=
at the web-hosted client resources can


   push javascript (or other) back into the=
 UA so it can extract the


   access token in the fragment; but some s=
ort of javascript is already


   running in the browser, since it initiat=
ed the authorization request


   in the first place.  So why this ex=
tra step?  Why not treat the


   javascript client running in the UA like=
 a native app and handle the


   redirect uri?____<=
/pre>

 


   __ __


 


   I know this was well thought out when th=
e spec was written, so


   trying to figure out what I=92m missing?=
____


 


   __ __


 


   __ __


 


   __ __


 


   Tx!


   adam____


 


 


   ________________________________________=
_______


   OAuth mailing list=



   OAuth@ietf.org <mailto:OAuth@ietf.org>=



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



 


 


 


 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


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


 




--


Bill Burke


JBoss, a division of Red Hat

http://bill.burkecentr=
al.com


 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


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






-- 


Bill Burke


JBoss, a division of Red Hat

http://bill.burkecentr=
al.com














_______________________________________________


OAuth mailing list


OAuth@ietf.org


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



 





_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/l=
istinfo/oauth





















_______________________________________________

OAuth mailing list

OAuth@ietf.org

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














--_000_593558ADA6214734B4E155345E3C3D96adobecom_--


From nobody Thu Feb 19 14:28:28 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12791A0AF8 for ; Thu, 19 Feb 2015 14:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level: 
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeVyAG3ca-Ko for ; Thu, 19 Feb 2015 14:28:20 -0800 (PST)
Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D2D1A0372 for ; Thu, 19 Feb 2015 14:28:17 -0800 (PST)
Received: from mail-ie0-f178.google.com ([209.85.223.178]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKVOZjgf+xXsrKvoxiC58lNI5dJH8L/K8K@postini.com; Thu, 19 Feb 2015 14:28:17 PST
Received: by iecat20 with SMTP id at20so3654985iec.12 for ; Thu, 19 Feb 2015 14:28:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=x/OTJ2X+LDXyBrLgBcZLUgQfrYm0KbnDypIM5Ghk7+o=; b=NIP4g8NyJRhOa6Wo4pOGQZMm2EnWe4Wsi4AhROC3c3xkEQA9Om6QahY1WtJpAU5EV+ z4VCWreKd6so3VwzD+LKG/EGB75+GcvlplZ5WOMhq2undXucpDRNx7I+mXb2pvZJMg8k w7ic90a7ajtoXyXuLBg9nbgw7Kxnt9wEUHRPIzfs3LpXdF8fO68DsHkEWSayuYV1Ege4 zIby4Php/pVgdJVY+9tdC0LLVl+phcChemFgXDcL8/SCBG8MLv2r6RbhpdbqhktcD25c 03IX99Ll7e+Zpf89ChV8+czu1uwiRhozw4JEGyJtPYG/mlg9NpL9n6EnyC5ohyBRgUQ+ KtBQ==
X-Gm-Message-State: ALoCoQmisPtfh8/uKOJHucE29z8F0YPUD+pUMr9sOpglt3xxw6l1TSeyDPor0gK00pP0E4MRu5piBKplwcEZ/aN1ESTiEegwcfVtN+7c5/3CKH306I6sO1X92OhM/MqvUeLGSgaW2/L7
X-Received: by 10.43.98.2 with SMTP id cm2mr8584496icc.75.1424384897061; Thu, 19 Feb 2015 14:28:17 -0800 (PST)
X-Received: by 10.43.98.2 with SMTP id cm2mr8584487icc.75.1424384896963; Thu, 19 Feb 2015 14:28:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.107.105 with HTTP; Thu, 19 Feb 2015 14:27:46 -0800 (PST)
In-Reply-To: <54E4CCDD.6010709@gmx.net>
References: <54C7BBA4.4030702@gmx.net>  <2E3D2EE7-8F5F-452D-880A-D62A513AC853@lodderstedt.net> <54E370F9.8060209@gmx.net> <17faabb6e724fb54f3cb8060a3d9cb08@lodderstedt.net> <54E4B0AD.10801@gmx.net>  <54E4CCDD.6010709@gmx.net>
From: Brian Campbell 
Date: Thu, 19 Feb 2015 15:27:46 -0700
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=bcaec517c890ceb158050f78731b
Archived-At: 
Cc: oauth , "naa@google.com >> Naveen Agarwal" 
Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Feb 2015 22:28:23 -0000

--bcaec517c890ceb158050f78731b
Content-Type: text/plain; charset=UTF-8

I can't comment with any authority on product road-map (that's above my
pay-grade) but I can speculate that we probably would support "S256"
eventually.

On Wed, Feb 18, 2015 at 10:33 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Thanks Brian for pointing me to Section 4.4.1 and to the MTI for "S256".
> While this is good from a security point of view I am wondering whether
> anyone is actually compliant to the specification. Neither PingIdentity
> nor DT implements the S256 transform, if I understood that correctly.
> Are you guys going planning to update your implementations?
>
> Ciao
> Hannes
>
> On 02/18/2015 05:45 PM, Brian Campbell wrote:
> > There's a bit of MTI talk tucked into
> > https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 that
> > perhaps needs to be expanded and/or placed somewhere else.
> >
> > On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig
> > > wrote:
> >
> >     Thanks for the info, Torsten.
> >
> >     Your feedback raises an interesting question, namely what
> functionality
> >     the parties have to implement to claim conformance to the
> specification.
> >
> >     Quickly scanning through the specification didn't tell me whether it
> is
> >     OK to just implement the plain mode or whether both modes are
> >     mandatory-to-implement. We have to say something about this.
> >
> >     Ciao
> >     Hannes
> >
> >
> >     On 02/18/2015 02:16 PM, torsten@lodderstedt.net
> >      wrote:
> >     > Hi Hannes,
> >     >
> >     > our implementation supports the "plain" mode only. We just verified
> >     > compliance of our implementation with the current spec. As the only
> >     > deviation, we do not enforce the minimum length of 43 characters
> >     of the
> >     > code verifier.
> >     >
> >     > kind regards,
> >     > Torsten.
> >     >
> >     > Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
> >     >> Hi Torsten,
> >     >>
> >     >> does this mean that your implementation is not compliant with the
> >     >> current version anymore or that you haven't had time to verify
> >     whether
> >     >> there are differences to the earlier version?
> >     >>
> >     >> Ciao
> >     >> Hannes
> >     >>
> >     >>
> >     >> On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
> >     >>> Deutsche Telekom also implemented an early version of the draft
> last
> >     >>> year.
> >     >>>
> >     >>>
> >     >>>
> >     >>> Am 30.01.2015 um 18:50 schrieb Brian Campbell
> >     >>> 
> >      >     >>:
> >     >>>
> >     >>>>
> >     >>>> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
> >     >>>> 
> >      >     >> wrote:
> >     >>>>
> >     >>>>
> >     >>>>     1) What implementations of the spec are you aware of?
> >     >>>>
> >     >>>>
> >     >>>> We have an AS side implementation of an earlier draft that was
> >     >>>> released in June of last year:
> >     >>>>
> >
> http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844
> >     >>>>
> >     >>>> _______________________________________________
> >     >>>> OAuth mailing list
> >     >>>> OAuth@ietf.org   >     >
> >     >>>> https://www.ietf.org/mailman/listinfo/oauth
> >
> >
>
>

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


I can't comment with any authority on product roa=
d-map (that's above my pay-grade) but I can speculate that we probably =
would support "S256" eventually. 

On Wed, Feb 18, 2015 at 10:33 AM,=
 Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote=
:
Thanks Brian for pointing me to Section=
 4.4.1 and to the MTI for "S256".

While this is good from a security point of view I am wondering whether

anyone is actually compliant to the specification. Neither PingIdentity

nor DT implements the S256 transform, if I understood that correctly.

Are you guys going planning to update your implementations?



Ciao

Hannes



On 02/18/2015 05:45 PM, Brian Campbell wrote:

> There's a bit of MTI talk tucked into

> https://tools.ietf.org/html/draft-ietf-oauth-spo=
p-10#section-4.4.1 that

> perhaps needs to be expanded and/or placed somewhere else.

>

> On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig

> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:

>

>=C2=A0 =C2=A0 =C2=A0Thanks for the info, Torsten.

>

>=C2=A0 =C2=A0 =C2=A0Your feedback raises an interesting question, namel=
y what functionality

>=C2=A0 =C2=A0 =C2=A0the parties have to implement to claim conformance =
to the specification.

>

>=C2=A0 =C2=A0 =C2=A0Quickly scanning through the specification didn'=
;t tell me whether it is

>=C2=A0 =C2=A0 =C2=A0OK to just implement the plain mode or whether both=
 modes are

>=C2=A0 =C2=A0 =C2=A0mandatory-to-implement. We have to say something ab=
out this.

>

>=C2=A0 =C2=A0 =C2=A0Ciao

>=C2=A0 =C2=A0 =C2=A0Hannes

>

>

>=C2=A0 =C2=A0 =C2=A0On 02/18/2015 02:16 PM, torsten@lodderstedt.net

>=C2=A0 =C2=A0 =C2=A0<mailto:torsten@lodderstedt.net> wrote:

>=C2=A0 =C2=A0 =C2=A0> Hi Hannes,

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> our implementation supports the "plain&qu=
ot; mode only. We just verified

>=C2=A0 =C2=A0 =C2=A0> compliance of our implementation with the curr=
ent spec. As the only

>=C2=A0 =C2=A0 =C2=A0> deviation, we do not enforce the minimum lengt=
h of 43 characters

>=C2=A0 =C2=A0 =C2=A0of the

>=C2=A0 =C2=A0 =C2=A0> code verifier.

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> kind regards,

>=C2=A0 =C2=A0 =C2=A0> Torsten.

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> Am 17.02.2015 17:48, schrieb Hannes Tschofenig=
:

>=C2=A0 =C2=A0 =C2=A0>> Hi Torsten,

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> does this mean that your implementation is=
 not compliant with the

>=C2=A0 =C2=A0 =C2=A0>> current version anymore or that you haven&=
#39;t had time to verify

>=C2=A0 =C2=A0 =C2=A0whether

>=C2=A0 =C2=A0 =C2=A0>> there are differences to the earlier versi=
on?

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> Ciao

>=C2=A0 =C2=A0 =C2=A0>> Hannes

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> On 01/31/2015 05:34 PM, Torsten Loddersted=
t wrote:

>=C2=A0 =C2=A0 =C2=A0>>> Deutsche Telekom also implemented an e=
arly version of the draft last

>=C2=A0 =C2=A0 =C2=A0>>> year.

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> Am 30.01.2015 um 18:50 schrieb Brian C=
ampbell

>=C2=A0 =C2=A0 =C2=A0>>> <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>

>=C2=A0 =C2=A0 =C2=A0<mailto:bcampbell@pingidentity.com

>=C2=A0 =C2=A0 =C2=A0<mailto:bcampbell@pingidentity.com>>>:

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> On Tue, Jan 27, 2015 at 9:24 AM, H=
annes Tschofenig

>=C2=A0 =C2=A0 =C2=A0>>>> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>

>=C2=A0 =C2=A0 =C2=A0<mailto:hannes.tschofenig@gmx.net

>=C2=A0 =C2=A0 =C2=A0<mailto:hannes.tschofenig@gmx.net>>> wrote:

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A01) What impleme=
ntations of the spec are you aware of?

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> We have an AS side implementation =
of an earlier draft that was

>=C2=A0 =C2=A0 =C2=A0>>>> released in June of last year:

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0http://documentati=
on.pingidentity.com/pages/viewpage.action?pageId=3D26706844

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> __________________________________=
_____________

>=C2=A0 =C2=A0 =C2=A0>>>> OAuth mailing list

>=C2=A0 =C2=A0 =C2=A0>>>> OAuth@ietf.org <mailto:OAut=
h@ietf.org> <mailto:OAuth@ietf.=
org

>=C2=A0 =C2=A0 =C2=A0<mailto:OAuth@=
ietf.org>>

>=C2=A0 =C2=A0 =C2=A0>>>> https://www.ietf.org/mailman/listin=
fo/oauth

>

>







--bcaec517c890ceb158050f78731b--


From nobody Thu Feb 19 15:48:27 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CDD1A1A50 for ; Thu, 19 Feb 2015 15:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level: 
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rOJVaJqIUH2 for ; Thu, 19 Feb 2015 15:48:23 -0800 (PST)
Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB05F1A1A5A for ; Thu, 19 Feb 2015 15:48:21 -0800 (PST)
Received: from mail-ie0-f173.google.com ([209.85.223.173]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKVOZ2RYttjR70Yglo7UNLcULVyn4xZYAb@postini.com; Thu, 19 Feb 2015 15:48:21 PST
Received: by iecrd18 with SMTP id rd18so4047927iec.8 for ; Thu, 19 Feb 2015 15:48:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=QHnnCqXDWlFugDAxaHPmWsD8w5ZJq1Lqy8LMa4wwYho=; b=Hun4f0dK5BITE0cLpkosLmn4Hd6N6I1LbNqj1OeqghDJmO+q13yW6BEG4gZjhlG2Xg Zxlj24ji/nxfokMxqzQWPHlEnGUz+vakP9xRdlhoz64FRDKfnXGjVud2btpKLmNcOpEf K/2w6T/UwVxnUk9zkKL8JXlEh5YB9iTsFsQhlXT1h0DLOC5GQNji15Rn8gtyfD85SR64 hXxwCNrWDZtBXpu/rnrxN+RB/gLi3fNycnrGe7M5lybL3/JUK4wGfW4S+fbdB/CNt+cw cOOukjMa55KHacGpyuZnE0L0lZTalOj8iUhearoR4YhVRuCm7FZLttQJ8Dhh9AiLgEEL Gi4A==
X-Gm-Message-State: ALoCoQnns0G8AEmkzuzy7ueAYJ4p+q5NDGw/6Bn/hrsyv3SE+uDKgmy9+MeV1sY8l5aX6+ih93PYv4H304wz9X777IvYiQe8tcQh0O71eB4Wj2QGL15gSjLGEJr5Fu868hjk+jnb4paJ
X-Received: by 10.42.196.199 with SMTP id eh7mr8933853icb.1.1424389701126; Thu, 19 Feb 2015 15:48:21 -0800 (PST)
X-Received: by 10.42.196.199 with SMTP id eh7mr8933836icb.1.1424389700826; Thu, 19 Feb 2015 15:48:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.107.105 with HTTP; Thu, 19 Feb 2015 15:47:50 -0800 (PST)
From: Brian Campbell 
Date: Thu, 19 Feb 2015 16:47:50 -0700
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=485b397dd0cd23d3c0050f79928a
Archived-At: 
Subject: [OAUTH-WG] Improper use of 'Pragma: no-cache' response header in OAuth 2.0 RFCs?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Feb 2015 23:48:25 -0000

--485b397dd0cd23d3c0050f79928a
Content-Type: text/plain; charset=UTF-8

Examples in RFC 6750  and RFC 6749
 as well as some normative text in section
5.1 of RFC 6749  use a
"Pragma: no-cache" HTTP response header. However, both RFC 2616
 and the shiny new RFC
7234  make special note
along the lines of the following to say that it doesn't work as response
header:

   'Note: Because the meaning of "Pragma: no-cache" in responses is
    not specified, it does not provide a reliable replacement for
    "Cache-Control: no-cache" in them.'


The header doesn't hurt anything, I don't think, so having it in these
documents isn't really a problem. But it seems like it'd be better to not
further perpetuate the "Pragma: no-cache" response header myth in actual
published RFCs.

So with that said, two questions:

1) Do folks agree that 6747/6750 are using the "Pragma: no-cache" response
header inappropriately?

2) If so, does this qualify as errata?

--485b397dd0cd23d3c0050f79928a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Examples in RFC 6750 and RFC 6749 as well as some normative text in section 5.1 of RFC 6749 use a "=
;Pragma: no-cache" HTTP response header. However, both RFC 2616 and the shiny new RFC 7234 make special note along the lines of th=
e following to say that it doesn't work as response header:

   'Note: Because the meaning of "Pragma: no-cac=
he" in responses is
    not specified, it does not provide a reliable replacement for
    "Cache-Control: no-cache" in them.'
The header d=
oesn't=20
hurt anything, I don't think, so having it in these documents isn't=
 really a problem. But it seems like it'd be better to not further perp=
etuate the "Pragma: no-cache"
 response header myth in actual published RFCs.

So with that s=
aid, two questions:

1) Do folks agree that 6747/6750 are using=
 the "Pragma: no-cache" response header inappropriately? 

=

2) If so, does this qualify as errata?


--485b397dd0cd23d3c0050f79928a--


From nobody Fri Feb 20 09:33:27 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F321A3BA2; Fri, 20 Feb 2015 09:33:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioYT5Y8grvJv; Fri, 20 Feb 2015 09:33:21 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6EA1A8834; Fri, 20 Feb 2015 09:33:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.11.0.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150220173320.16488.94731.idtracker@ietfa.amsl.com>
Date: Fri, 20 Feb 2015 09:33:20 -0800
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-24.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Feb 2015 17:33:24 -0000

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

        Title           : OAuth 2.0 Dynamic Client Registration Protocol
        Authors         : Justin Richer
                          Michael B. Jones
                          John Bradley
                          Maciej Machulak
                          Phil Hunt
	Filename        : draft-ietf-oauth-dyn-reg-24.txt
	Pages           : 40
	Date            : 2015-02-20

Abstract:
   This specification defines mechanisms for dynamically registering
   OAuth 2.0 clients with authorization servers.  Registration requests
   send a set of desired client metadata values to the authorization
   server.  The resulting registration responses return a client
   identifier to use at the authorization server and the client metadata
   values registered for the client.  The client can then use this
   registration information to communicate with the authorization server
   using the OAuth 2.0 protocol.  This specification also defines a set
   of common client metadata fields and values for clients to use during
   registration.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-24


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

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


From nobody Fri Feb 20 10:02:42 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1181A8BB2 for ; Fri, 20 Feb 2015 10:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFeWAsUbf_or for ; Fri, 20 Feb 2015 10:02:39 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D241A8F49 for ; Fri, 20 Feb 2015 09:59:47 -0800 (PST)
X-AuditID: 12074424-f79356d000004839-3e-54e77611e755
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 55.6A.18489.11677E45; Fri, 20 Feb 2015 12:59:45 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t1KHxjnT012508 for ; Fri, 20 Feb 2015 12:59:45 -0500
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1KHxgHT002314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 20 Feb 2015 12:59:44 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Justin Richer 
In-Reply-To: <20150220173320.16488.94731.idtracker@ietfa.amsl.com>
Date: Fri, 20 Feb 2015 12:59:42 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <397802A6-285C-46B1-8B6E-76ECBBBA0563@mit.edu>
References: <20150220173320.16488.94731.idtracker@ietfa.amsl.com>
To: "" 
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixG6noitY9jzEoPGnucXJt6/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8eb6EtaCuYIVZ55tYG1gbOHtYuTgkBAwkfi0R7CLkRPIFJO4 cG89WxcjF4eQwGImieN7LzFCOMcYJR5/PAuV+cYksbBjKytIC7OAusSfeZeYQWxeAQOJuae+ MIHYwgLOErvePQSLswmoSkxf0wIW5xRwkljTcYAdxGYBim9ecpUdYo62xLKFr6HmWEk8XTYH LC4k4Cjx7tM0sF0iQLvWnP/JBHG1vETPpvQJjAKzkFwxC8kVs5BMXcDIvIpRNiW3Sjc3MTOn ODVZtzg5MS8vtUjXXC83s0QvNaV0EyM4JF1UdjA2H1I6xCjAwajEw1sx/VmIEGtiWXFl7iFG SQ4mJVHe2MLnIUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeO0zgHK8KYmVValF+TApaQ4WJXHe TT/4QoQE0hNLUrNTUwtSi2CyMhwcShK88iVAjYJFqempFWmZOSUIaSYOTpDhPEDDTUFqeIsL EnOLM9Mh8qcYFaXEeRNBEgIgiYzSPLheWMp4xSgO9Iowbw5IFQ8w3cB1vwIazAQ0+MDXZyCD SxIRUlINjIn2xy30/V+ICyqnyjUdKTYvOvBE/XvrB1bncNcSu3M5tsk+i/fZSDnLOzw/I8j7 Ie7JskWvLW3WRDUYip25YMb7osbzvMsu451vVplkJAofPCyQNs/79zdnvRaVBF3u94lPt6TN CrzvPPHcfcnv/8IK95t17r+t2Rxtckk8QklonvL3T7nhSizFGYmGWsxFxYkAGeCadfQCAAA=
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-24.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Feb 2015 18:02:41 -0000

New draft addressing AD comments.=20

 =E2=80=94 Justin

> On Feb 20, 2015, at 12:33 PM, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Web Authorization Protocol Working =
Group of the IETF.
>=20
>        Title           : OAuth 2.0 Dynamic Client Registration =
Protocol
>        Authors         : Justin Richer
>                          Michael B. Jones
>                          John Bradley
>                          Maciej Machulak
>                          Phil Hunt
> 	Filename        : draft-ietf-oauth-dyn-reg-24.txt
> 	Pages           : 40
> 	Date            : 2015-02-20
>=20
> Abstract:
>   This specification defines mechanisms for dynamically registering
>   OAuth 2.0 clients with authorization servers.  Registration requests
>   send a set of desired client metadata values to the authorization
>   server.  The resulting registration responses return a client
>   identifier to use at the authorization server and the client =
metadata
>   values registered for the client.  The client can then use this
>   registration information to communicate with the authorization =
server
>   using the OAuth 2.0 protocol.  This specification also defines a set
>   of common client metadata fields and values for clients to use =
during
>   registration.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-24
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Mon Feb 23 08:46:19 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7874B1A1BA3; Mon, 23 Feb 2015 08:46:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0rVI0rTv5_R; Mon, 23 Feb 2015 08:46:14 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4D11A1BA5; Mon, 23 Feb 2015 08:46:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.11.0.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150223164614.3412.88950.idtracker@ietfa.amsl.com>
Date: Mon, 23 Feb 2015 08:46:14 -0800
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Feb 2015 16:46:17 -0000

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

        Title           : OAuth 2.0 Token Exchange
        Authors         : Michael B. Jones
                          Anthony Nadalin
	Filename        : draft-ietf-oauth-token-exchange-01.txt
	Pages           : 10
	Date            : 2015-02-23

Abstract:
   This specification defines how to request and obtain Security Tokens
   from OAuth Authorization Servers, including enabling one party to act
   on behalf of another or enabling one party to delegate authority to
   another.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-01


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

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


From nobody Tue Feb 24 10:00:27 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DDF1A1BFA for ; Tue, 24 Feb 2015 10:00:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_24=1.618, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9lC2342-FxQ for ; Tue, 24 Feb 2015 10:00:24 -0800 (PST)
Received: from na3sys009aog133.obsmtp.com (na3sys009aog133.obsmtp.com [74.125.149.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4F71A1B9E for ; Tue, 24 Feb 2015 10:00:23 -0800 (PST)
Received: from mail-ie0-f173.google.com ([209.85.223.173]) (using TLSv1) by na3sys009aob133.postini.com ([74.125.148.12]) with SMTP ID DSNKVOy8N/6/ycUcc6fqitfPGEQ0QUHMMiPD@postini.com; Tue, 24 Feb 2015 10:00:23 PST
Received: by iecar1 with SMTP id ar1so34189690iec.11 for ; Tue, 24 Feb 2015 10:00:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=pBvdEcDYONyd8MyElsUAk44nA/K95Z3h/tjt2ydivXM=; b=KYylEXszDapzUzfm3umjdtBY+EQ/LYx7tWRQ9ztzgyhV+h9OScGwZZnttWPg3uQNX1 pzMbzVNJ3fyt7WJCeu9VgcT/rF9kvo11qiZF91rjH+g42fe5sKTznLyI4iBugt5gGzkg lSmwWDwFuq9GooV47Hlo2EZjONG3nZ9NrQH0w4FcZkZAEFG/7cGZQfrNqHxMAGNspTp8 zNSKNAh85PhPHea/EwyzO6EhDa1tIICceRUs0jjZvp6J7Zb7Ue78cYP/yYbMa6PXc24l tGhM3HLfgxM22dLHNbnC7rGR4tz4ixL3TuA+OF8lqxKfmF3n7/2CjsJZEeNqM/ZPuTCK ifmA==
X-Gm-Message-State: ALoCoQm5ruAVF4U34JasW1KX4nlrXCzieFjJnq63/O9H2lv2iYRaFSff+KbMAjgGPa8jXsbnlYMDcKzJfdi6RBQYQXrc6afu5I610/V7mJMUcdsDhRV9yUfLALK4AHJSdAAekB20IphW
X-Received: by 10.42.113.2 with SMTP id a2mr18977373icq.30.1424800822673; Tue, 24 Feb 2015 10:00:22 -0800 (PST)
X-Received: by 10.42.113.2 with SMTP id a2mr18977359icq.30.1424800822531; Tue, 24 Feb 2015 10:00:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.54.98 with HTTP; Tue, 24 Feb 2015 09:59:52 -0800 (PST)
In-Reply-To: 
References: 
From: Brian Campbell 
Date: Tue, 24 Feb 2015 10:59:52 -0700
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=001a11c3e82ae75954050fd94a43
Archived-At: 
Subject: Re: [OAUTH-WG] Improper use of 'Pragma: no-cache' response header in OAuth 2.0 RFCs?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Feb 2015 18:00:26 -0000

--001a11c3e82ae75954050fd94a43
Content-Type: text/plain; charset=UTF-8

I know it's kind of a trivial issue but I was hoping that at least a couple
people would either agree with me or explain why I'm wrong.


On Thu, Feb 19, 2015 at 4:47 PM, Brian Campbell 
wrote:

> Examples in RFC 6750  and RFC 6749
>  as well as some normative text in section
> 5.1 of RFC 6749  use a
> "Pragma: no-cache" HTTP response header. However, both RFC 2616
>  and the shiny new RFC
> 7234  make special note
> along the lines of the following to say that it doesn't work as response
> header:
>
>    'Note: Because the meaning of "Pragma: no-cache" in responses is
>     not specified, it does not provide a reliable replacement for
>     "Cache-Control: no-cache" in them.'
>
>
> The header doesn't hurt anything, I don't think, so having it in these
> documents isn't really a problem. But it seems like it'd be better to not
> further perpetuate the "Pragma: no-cache" response header myth in actual
> published RFCs.
>
> So with that said, two questions:
>
> 1) Do folks agree that 6747/6750 are using the "Pragma: no-cache" response
> header inappropriately?
>
> 2) If so, does this qualify as errata?
>

--001a11c3e82ae75954050fd94a43
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




I know it's kind of a trivial iss=
ue but I was hoping that at least a couple people would either agree with m=
e or explain why I'm wrong. 


On Thu, Feb 19, 2015 at 4:47 PM, Br=
ian Campbell <bcampbell@pingidentity.com> wrote:
Examples in=
 RFC 6750<=
/a> and RF=
C 6749 as well as some normative text in section 5.1 of RFC 6749 =
use a "Pragma: no-cache" HTTP response header. However, both =
RFC 2616 and the shiny new RFC 7234 make special note along the =
lines of the following to say that it doesn't work as response header:<=
br>
   'Note: Because the meaning of "Pra=
gma: no-cache" in responses is
    not specified, it does not provide a reliable replacement for
    "Cache-Control: no-cache" in them.'

The header d=
oesn't=20
hurt anything, I don't think, so having it in these documents isn't=
 really a problem. But it seems like it'd be better to not further perp=
etuate the "Pragma: no-cache"
 response header myth in actual published RFCs.

So with that s=
aid, two questions:

1) Do folks agree that 6747/6750 are using=
 the "Pragma: no-cache" response header inappropriately? 

=

2) If so, does this qualify as errata?





--001a11c3e82ae75954050fd94a43--


From nobody Tue Feb 24 10:15:21 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E441A876E for ; Tue, 24 Feb 2015 10:15:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne0R6WJiRlh0 for ; Tue, 24 Feb 2015 10:15:18 -0800 (PST)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B6C1A1B59 for ; Tue, 24 Feb 2015 10:15:17 -0800 (PST)
Received: by mail-qa0-f46.google.com with SMTP id n4so28450652qaq.5 for ; Tue, 24 Feb 2015 10:15:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=zJsOWdxQUfOAy9JY2e+1JhYjzsxP0lg/C6hGHdHqFHk=; b=Dp75Nn4l7orC5NKhG1Q6FXJgNKnWN855MYMBQtcfyNf8LFkA7JsbNB8L+Bi7qXhygg pb+RYD7wklbKV9d901rcCjb6uvh0h6jjU2wngHMOvxnhxnxcoqV9EpwKfMguG1X2pIGa dtI0CE/H+psDzoyvZGs4RX56czGul+uBLo/wBCSyMH7EsAZlsEZMqFII0it7VzERZU98 6wDLvC3uw+0YB4e/Vx1NporFM2DxB4+W/uG/XADoL68dFIRX5BpTMmbmDbGusooxMIqo zXgAa7Zl5lxL6+KEMEXyFm7vF5vYR4QvziJ+RsM8I+51irpbAD1vIyhn/FTKDKJZVyEB ILDA==
X-Gm-Message-State: ALoCoQmV0zerVpdnM6Nns+Tl7QcoClPvwltu9okyC41fW9FswwWZPCit9us/O4naEXOcFbH0mkrJ
X-Received: by 10.140.151.65 with SMTP id 62mr38443589qhx.73.1424801717094; Tue, 24 Feb 2015 10:15:17 -0800 (PST)
Received: from [10.2.2.171] (PING-IDENTI.bar1.Boston1.Level3.net. [4.31.154.18]) by mx.google.com with ESMTPSA id j94sm29924052qgd.47.2015.02.24.10.15.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 10:15:16 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_E7FC654D-F796-4D18-B7BC-FA2B516F087A"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: 
Date: Tue, 24 Feb 2015 13:15:15 -0500
Message-Id: 
References: 
To: Brian Campbell 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Improper use of 'Pragma: no-cache' response header in OAuth 2.0 RFCs?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Feb 2015 18:15:20 -0000

--Apple-Mail=_E7FC654D-F796-4D18-B7BC-FA2B516F087A
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_AB4C0D30-EF1B-4DCB-BA6D-192B1BFA47D8"


--Apple-Mail=_AB4C0D30-EF1B-4DCB-BA6D-192B1BFA47D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes, so we should track it but I don=E2=80=99t think it rises to the =
level of an errata on its own.=20
> On Feb 19, 2015, at 6:47 PM, Brian Campbell =
 wrote:
>=20
> Examples in RFC 6750  and RFC 6749 =
 as well as some normative text in =
section 5.1 of RFC 6749  =
use a "Pragma: no-cache" HTTP response header. However, both RFC 2616 =
 and the shiny new RFC =
7234  make special note =
along the lines of the following to say that it doesn't work as response =
header:
>=20
>    'Note: Because the meaning of "Pragma: no-cache" in responses is
>     not specified, it does not provide a reliable replacement for
>     "Cache-Control: no-cache" in them.'
>=20
> The header doesn't hurt anything, I don't think, so having it in these =
documents isn't really a problem. But it seems like it'd be better to =
not further perpetuate the "Pragma: no-cache" response header myth in =
actual published RFCs.
>=20
> So with that said, two questions:
>=20
> 1) Do folks agree that 6747/6750 are using the "Pragma: no-cache" =
response header inappropriately?=20
>=20
> 2) If so, does this qualify as errata?
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_AB4C0D30-EF1B-4DCB-BA6D-192B1BFA47D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes, so we should track it but I don=E2=80=99t think it rises =
to the level of an errata on its own. 
On Feb 19, 2015, at 6:47 PM, =
Brian Campbell <bcampbell@pingidentity.com> wrote:

Examples in =
RFC 6750 =
and RFC =
6749 as well as some normative text in section=
 5.1 of RFC 6749 use a "Pragma: no-cache" HTTP response header. =
However, both RFC 2616 and the shiny new RFC 7234 make special note along the lines of the =
following to say that it doesn't work as response header:

   'Note: Because the meaning of "Pragma: no-cache" in =
responses is
    not specified, it does not provide a reliable replacement for
    "Cache-Control: no-cache" in them.'

The header =
doesn't=20
hurt anything, I don't think, so having it in these documents isn't =
really a problem. But it seems like it'd be better to not further =
perpetuate the "Pragma: no-cache"
 response header myth in actual published RFCs.

So with that said, two questions:

1) Do folks agree that 6747/6750 are using the "Pragma: =
no-cache" response header inappropriately? 

2) If so, does this qualify as errata?

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

=

--Apple-Mail=_AB4C0D30-EF1B-4DCB-BA6D-192B1BFA47D8--

--Apple-Mail=_E7FC654D-F796-4D18-B7BC-FA2B516F087A
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMjQxODE1MTVaMCMGCSqGSIb3DQEJBDEWBBRmeRzjdRug+6oSQVog+Mvc
szy+HzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBbu58zxEk2PYifMEL/DquA93f/63x/w8LAvXUYyzx3N2H+tuduKTCz
d5s1UaDeKvOvly58dun17/Q0IMBhoG6mI0jf+5cwOWd9Y4Mu96f8oh9AqWfd2SALynyTj779bwc6
3kcsiKPp+RUzV7/B//YMLnLJCEEi0jaVZd3mQ0TN2Tt7WUEoZ6Xx/h8YEovbSvBJ/7dYJjddgz3z
tv4AFoRG+wByIJp1MBZ2vDUhr0Zgl14TesAca9SD8okE3Zw7lHD8wOHgarlqCvkR44dCL25K1Hgo
8P7MMd7XXTb4qi8GJJYJ0xE3JBz5/O/o0DJI2lpdgnS3q0jyUNLLqfbH/sL7AAAAAAAA
--Apple-Mail=_E7FC654D-F796-4D18-B7BC-FA2B516F087A--


From nobody Tue Feb 24 15:07:49 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700AF1A0070 for ; Tue, 24 Feb 2015 15:07:48 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lMk7aBgw-f3 for ; Tue, 24 Feb 2015 15:07:46 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F6C1A9069 for ; Tue, 24 Feb 2015 15:07:46 -0800 (PST)
Received: by lbiz11 with SMTP id z11so190858lbi.5 for ; Tue, 24 Feb 2015 15:07:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d/HRCRdAd5ErcHaa7C/SnAFTSH2mrinBsp5WPbz00jE=; b=ZbcDE+VPUz5y8FnGyHMEvUqyICdKmN9mO5D2DEvOdKe5OuthzPVfqE2M1/OkrZSuDC IUdIc8ySspbqw7fd4Jn0MqztH8ilgyskqP4nhOGCQ+vBjzUbiicZJuRdK8BF3YjaI2V5 gPtXLV19HiXZsZq39zhOEC/YiKUbdqZIRCg+jJhwTHxUxXobePYLrMI79HdY7Qpw5zu9 m7mnp6PXGgcx4X6aYtaZjqkxy3OZpXWMsM0r6nz/EfBtoapS6FfiBezJ2Ewvl9Ay+d6Y DZefTxqCNKD/Pck/BaQCgLzFm+gsLz559WMh0VUGc9CsMvaQCivCG0ENkCOanD4R1nYs UvRA==
MIME-Version: 1.0
X-Received: by 10.112.97.106 with SMTP id dz10mr311903lbb.4.1424819264531; Tue, 24 Feb 2015 15:07:44 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Tue, 24 Feb 2015 15:07:44 -0800 (PST)
In-Reply-To: <54E4D2A5.5030705@gmx.net>
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>   <54E4D2A5.5030705@gmx.net>
Date: Tue, 24 Feb 2015 18:07:44 -0500
Message-ID: 
From: Kathleen Moriarty 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a11345b1221b1b4050fdd96d6
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Feb 2015 23:07:48 -0000

--001a11345b1221b1b4050fdd96d6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

Thanks for updating the draft.  I just want to confirm that Hannes is okay
with the updated definitions and updates the shepherd report to reflect
that.

This is getting held up a bit while we sort through copyright of text from
UMA and OpenID.  The text from UMA went into an IETF draft, so that should
be the reference as it clears up any possible issues as they provided that
text in an IETF draft.

The chairs will be helping to sort out the requirements with OpenID, per
our discussions the IETF trustees.  I'm not sure how long this will take,
but wanted to provide a status so no one thought this had been dropped.

Thanks.

On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi Justin, Hi John,
>
> I believe that provisioning a client with a unique id (which is what a
> client id/client secret is) allows some form of linkability. While it
> may be possible to associate the client to a specific user I could very
> well imagine that the correlation between activities from a user and
> those from the client (particularly when the client is running on the
> user's device) is quite possible.
>
> Ciao
> Hannes
>
> On 02/18/2015 06:37 PM, Justin Richer wrote:
> > I=E2=80=99ll incorporate this feedback into another draft, to be posted=
 by the
> > end of the week. Thanks everyone!
> >
> >  =E2=80=94 Justin
> >
> >> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
> >>  >> > wrote:
> >>
> >>
> >>
> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley  >> > wrote:
> >>
> >>     snip
> >>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
> >>>      >>>     > wrote:
> >>>
> >>>         > The client_id *could* be short lived, but they usually
> aren't. I don't see any particular logging or tracking concerns using a
> dynamic OAuth client above using any other piece of software, ever. As
> such, I don't think it requires special calling out here.
> >>>
> >>>
> >>>     Help me understand why there should not be text that shows this
> >>>     is not an issue or please propose some text.  This is bound to
> >>>     come up in IESG reviews if not addressed up front.
> >>>
> >>>
> >>
> >>     The client_id is used to communicate to the Authorization server
> >>     to get a code or refresh token.  Those tokens uniquely identify
> >>     the user from a privacy perspective.
> >>     It is the access tokens that are sent to the RS and those can and
> >>     should be rotated, but the client)id is not sent to the RS in
> >>     OAuth as part of the spec.
> >>
> >>     If you did rotate the client_id then the AS would track it across
> >>     rotations, so it wouldn=E2=80=99t really achieve anything.
> >>
> >>     One thing we don=E2=80=99t do is allow the client to specify the
> >>     client_id, that could allow correlation of the client across
> >>     multiple AS and that might be a privacy issue, but we don=E2=80=99=
t allow
> it.
> >>
> >>
> >> Thanks, John.  It may be helpful to add in this explanation unless
> >> there is some reason not to?
> >>
> >>
> >>     John B.
> >>
> >>
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> Kathleen
> >> _______________________________________________
> >> 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

Best regards,
Kathleen

--001a11345b1221b1b4050fdd96d6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello,

Thanks for updating the draft.=
=C2=A0 I just want to confirm that Hannes is okay with the updated definiti=
ons and updates the shepherd report to reflect that.

This is getting held up a bit while we sort through copyright of text fr=
om UMA and OpenID.=C2=A0 The text from UMA went into an IETF draft, so that=
 should be the reference as it clears up any possible issues as they provid=
ed that text in an IETF draft. =C2=A0

The chairs w=
ill be helping to sort out the requirements with OpenID, per our discussion=
s the IETF trustees.=C2=A0 I'm not sure how long this will take, but wa=
nted to provide a status so no one thought this had been dropped.

Thanks.

On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Justin, Hi John,



I believe that provisioning a client with a unique id (which is what a

client id/client secret is) allows some form of linkability. While it

may be possible to associate the client to a specific user I could very

well imagine that the correlation between activities from a user and

those from the client (particularly when the client is running on the

user's device) is quite possible.



Ciao

Hannes



On 02/18/2015 06:37 PM, Justin Richer wrote:

> I=E2=80=99ll incorporate this feedback into an=
other draft, to be posted by the

> end of the week. Thanks everyone!

>

>=C2=A0 =E2=80=94 Justin

>

>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty

>> <kathleen.m=
oriarty.ietf@gmail.com

>> <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
>>

>>

>>

>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <ve7jtb@ve7jtb.com

>> <mailto:ve7jtb@ve7jtb.com>> wrote:

>>

>>=C2=A0 =C2=A0 =C2=A0snip

>>>=C2=A0 =C2=A0 =C2=A0On Feb 18, 2015, at 6:46 AM, Kathleen Moria=
rty

>>>=C2=A0 =C2=A0 =C2=A0<kathleen.moriarty.ietf@gmail.com

>>>=C2=A0 =C2=A0 =C2=A0<mailto:kathleen.moriarty.ietf@gmail.c=
om>> wrote:

>>>

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> The client_id *could* be=
 short lived, but they usually aren't. I don't see any particular l=
ogging or tracking concerns using a dynamic OAuth client above using any ot=
her piece of software, ever. As such, I don't think it requires special=
 calling out here.

>>>

>>>

>>>=C2=A0 =C2=A0 =C2=A0Help me understand why there should not be =
text that shows this

>>>=C2=A0 =C2=A0 =C2=A0is not an issue or please propose some text=
.=C2=A0 This is bound to

>>>=C2=A0 =C2=A0 =C2=A0come up in IESG reviews if not addressed up=
 front.

>>>

>>>

>>

>>=C2=A0 =C2=A0 =C2=A0The client_id is used to communicate to the Aut=
horization server

>>=C2=A0 =C2=A0 =C2=A0to get a code or refresh token.=C2=A0 Those tok=
ens uniquely identify

>>=C2=A0 =C2=A0 =C2=A0the user from a privacy perspective.

>>=C2=A0 =C2=A0 =C2=A0It is the access tokens that are sent to the RS=
 and those can and

>>=C2=A0 =C2=A0 =C2=A0should be rotated, but the client)id is not sen=
t to the RS in

>>=C2=A0 =C2=A0 =C2=A0OAuth as part of the spec.

>>

>>=C2=A0 =C2=A0 =C2=A0If you did rotate the client_id then the AS wou=
ld track it across

>>=C2=A0 =C2=A0 =C2=A0rotations, so it wouldn=E2=80=99t really achiev=
e anything.

>>

>>=C2=A0 =C2=A0 =C2=A0One thing we don=E2=80=99t do is allow the clie=
nt to specify the

>>=C2=A0 =C2=A0 =C2=A0client_id, that could allow correlation of the =
client across

>>=C2=A0 =C2=A0 =C2=A0multiple AS and that might be a privacy issue, =
but we don=E2=80=99t allow it.

>>

>>

>> Thanks, John.=C2=A0 It may be helpful to add in this explanation u=
nless

>> there is some reason not to?

>>

>>

>>=C2=A0 =C2=A0 =C2=A0John B.

>>

>>

>>

>>

>> --

>>

>> Best regards,

>> Kathleen

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org <ma=
ilto:OAuth@ietf.org>

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


>

>

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

>







-- 
=


Best regards,
Kathleen




--001a11345b1221b1b4050fdd96d6--


From nobody Tue Feb 24 15:48:58 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E961A19EF for ; Tue, 24 Feb 2015 15:48:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.598
X-Spam-Level: 
X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-g9efUgDwh6 for ; Tue, 24 Feb 2015 15:48:45 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085F41A03E3 for ; Tue, 24 Feb 2015 15:48:44 -0800 (PST)
Received: from DM2PR03CA0052.namprd03.prod.outlook.com (10.141.96.51) by BY2PR03MB393.namprd03.prod.outlook.com (10.141.141.12) with Microsoft SMTP Server (TLS) id 15.1.93.16; Tue, 24 Feb 2015 23:48:42 +0000
Received: from BL2FFO11FD028.protection.gbl (2a01:111:f400:7c09::194) by DM2PR03CA0052.outlook.office365.com (2a01:111:e400:2428::51) with Microsoft SMTP Server (TLS) id 15.1.99.9 via Frontend Transport; Tue, 24 Feb 2015 23:48:41 +0000
Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD028.mail.protection.outlook.com (10.173.161.107) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Tue, 24 Feb 2015 23:48:40 +0000
Received: from TK5EX14MBXC290.redmond.corp.microsoft.com ([169.254.1.42]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0224.003; Tue, 24 Feb 2015 23:47:55 +0000
From: Mike Jones 
To: Kathleen Moriarty , Hannes Tschofenig 
Thread-Topic: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
Thread-Index: AQHQRk+KdTW6focrw0+qa3R3HLsnGpzsbP6AgAD/rACABoKlgIACl1OAgAAGGYCAAAZBAIAAI6aAgAAFmYCACcSKAIAACNkA
Date: Tue, 24 Feb 2015 23:47:54 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com>
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>   <54E4D2A5.5030705@gmx.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.73]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943A2264EC6TK5EX14MBXC290r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com;  client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; gmail.com; dkim=none (message not signed) header.d=none;
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(164054003)(24454002)(51704005)(377454003)(199003)(189002)(52604005)(479174004)(85806002)(69596002)(19580405001)(93886004)(230783001)(76176999)(19580395003)(84326002)(26826002)(46102003)(87936001)(6806004)(19625215002)(33656002)(50986999)(54356999)(64706001)(66066001)(16236675004)(15395725005)(86362001)(19300405004)(86612001)(512874002)(2920100001)(77156002)(2900100001)(2950100001)(68736005)(97736003)(2656002)(55846006)(102836002)(92566002)(19617315012)(81156004)(15975445007)(106466001)(104016003)(62966003)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB393; H:mail.microsoft.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB393;
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005004); SRVR:BY2PR03MB393; 
X-Forefront-PRVS: 04976078F0
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB393;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2015 23:48:40.9988 (UTC)
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB393
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Feb 2015 23:48:48 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943A2264EC6TK5EX14MBXC290r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzLCBLYXRobGVlbi4gIFRoaXMgaGFkIGJlZW4gZGlzY3Vzc2VkIG9uIHRoZSBPQXV0aCBs
aXN0IGJlZm9yZSwgYnV0IGp1c3QgaW4gY2FzZSB5b3Ugb3IgdGhlIElFVEYgbGVnYWwgY291bnNl
bCB3ZXJlbuKAmXQgYXdhcmUgb2YgaXQg4oCTIHRoZSByZWFzb24gdGhhdCBpdOKAmXMgT0sgdG8g
cHJvZHVjZSBkZXJpdmF0aXZlIHdvcmtzIGZyb20gT3BlbklEIHNwZWNzLCBhcyBkcmFmdC1pZXRm
LW9hdXRoLWR5bi1yZWcgZGlkLCBpcyB0aGF0IGl04oCZcyBleHBsaWNpdGx5IGFsbG93ZWQgYnkg
dGhlIE9wZW5JRCBGb3VuZGF0aW9uLiAgU2VlIHRoaXMgdGV4dCBhdCBodHRwOi8vb3BlbmlkLm5l
dC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLmh0bWwjTm90aWNlcyDigJMg
dGhlIHNwZWMgZnJvbSB3aGljaCB0ZXh0IHdhcyBjb3BpZWQ6DQoNClRoZSBPcGVuSUQgRm91bmRh
dGlvbiAoT0lERikgZ3JhbnRzIHRvIGFueSBDb250cmlidXRvciwgZGV2ZWxvcGVyLCBpbXBsZW1l
bnRlciwgb3Igb3RoZXIgaW50ZXJlc3RlZCBwYXJ0eSBhIG5vbi1leGNsdXNpdmUsIHJveWFsdHkg
ZnJlZSwgd29ybGR3aWRlIGNvcHlyaWdodCBsaWNlbnNlIHRvIHJlcHJvZHVjZSwgcHJlcGFyZSBk
ZXJpdmF0aXZlIHdvcmtzIGZyb20sIGRpc3RyaWJ1dGUsIHBlcmZvcm0gYW5kIGRpc3BsYXksIHRo
aXMgSW1wbGVtZW50ZXJzIERyYWZ0IG9yIEZpbmFsIFNwZWNpZmljYXRpb24gc29sZWx5IGZvciB0
aGUgcHVycG9zZXMgb2YgKGkpIGRldmVsb3Bpbmcgc3BlY2lmaWNhdGlvbnMsIGFuZCAoaWkpIGlt
cGxlbWVudGluZyBJbXBsZW1lbnRlcnMgRHJhZnRzIGFuZCBGaW5hbCBTcGVjaWZpY2F0aW9ucyBi
YXNlZCBvbiBzdWNoIGRvY3VtZW50cywgcHJvdmlkZWQgdGhhdCBhdHRyaWJ1dGlvbiBiZSBtYWRl
IHRvIHRoZSBPSURGIGFzIHRoZSBzb3VyY2Ugb2YgdGhlIG1hdGVyaWFsLCBidXQgdGhhdCBzdWNo
IGF0dHJpYnV0aW9uIGRvZXMgbm90IGluZGljYXRlIGFuIGVuZG9yc2VtZW50IGJ5IHRoZSBPSURG
Lg0KDQpZb3UgY291bGQgcGFzcyB0aGF0IG9uIHRvIHRoZSBhcHByb3ByaWF0ZSBJRVRGIGxlZ2Fs
IGNvdW5zZWwgaWYgdGhleeKAmXJlIG5vdCBhbHJlYWR5IGF3YXJlIG9mIGl0Lg0KDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
LS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBLYXRobGVlbiBNb3JpYXJ0eQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjQs
IDIwMTUgMzowOCBQTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzogb2F1dGhAaWV0Zi5vcmcN
ClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFEIHJldmlldyBvZiBEcmFmdC1pZXRmLWR5bi1yZWcN
Cg0KSGVsbG8sDQoNClRoYW5rcyBmb3IgdXBkYXRpbmcgdGhlIGRyYWZ0LiAgSSBqdXN0IHdhbnQg
dG8gY29uZmlybSB0aGF0IEhhbm5lcyBpcyBva2F5IHdpdGggdGhlIHVwZGF0ZWQgZGVmaW5pdGlv
bnMgYW5kIHVwZGF0ZXMgdGhlIHNoZXBoZXJkIHJlcG9ydCB0byByZWZsZWN0IHRoYXQuDQoNClRo
aXMgaXMgZ2V0dGluZyBoZWxkIHVwIGEgYml0IHdoaWxlIHdlIHNvcnQgdGhyb3VnaCBjb3B5cmln
aHQgb2YgdGV4dCBmcm9tIFVNQSBhbmQgT3BlbklELiAgVGhlIHRleHQgZnJvbSBVTUEgd2VudCBp
bnRvIGFuIElFVEYgZHJhZnQsIHNvIHRoYXQgc2hvdWxkIGJlIHRoZSByZWZlcmVuY2UgYXMgaXQg
Y2xlYXJzIHVwIGFueSBwb3NzaWJsZSBpc3N1ZXMgYXMgdGhleSBwcm92aWRlZCB0aGF0IHRleHQg
aW4gYW4gSUVURiBkcmFmdC4NCg0KVGhlIGNoYWlycyB3aWxsIGJlIGhlbHBpbmcgdG8gc29ydCBv
dXQgdGhlIHJlcXVpcmVtZW50cyB3aXRoIE9wZW5JRCwgcGVyIG91ciBkaXNjdXNzaW9ucyB0aGUg
SUVURiB0cnVzdGVlcy4gIEknbSBub3Qgc3VyZSBob3cgbG9uZyB0aGlzIHdpbGwgdGFrZSwgYnV0
IHdhbnRlZCB0byBwcm92aWRlIGEgc3RhdHVzIHNvIG5vIG9uZSB0aG91Z2h0IHRoaXMgaGFkIGJl
ZW4gZHJvcHBlZC4NCg0KVGhhbmtzLg0KDQpPbiBXZWQsIEZlYiAxOCwgMjAxNSBhdCAxMjo1NyBQ
TSwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOmhh
bm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+PiB3cm90ZToNCkhpIEp1c3RpbiwgSGkgSm9obiwNCg0K
SSBiZWxpZXZlIHRoYXQgcHJvdmlzaW9uaW5nIGEgY2xpZW50IHdpdGggYSB1bmlxdWUgaWQgKHdo
aWNoIGlzIHdoYXQgYQ0KY2xpZW50IGlkL2NsaWVudCBzZWNyZXQgaXMpIGFsbG93cyBzb21lIGZv
cm0gb2YgbGlua2FiaWxpdHkuIFdoaWxlIGl0DQptYXkgYmUgcG9zc2libGUgdG8gYXNzb2NpYXRl
IHRoZSBjbGllbnQgdG8gYSBzcGVjaWZpYyB1c2VyIEkgY291bGQgdmVyeQ0Kd2VsbCBpbWFnaW5l
IHRoYXQgdGhlIGNvcnJlbGF0aW9uIGJldHdlZW4gYWN0aXZpdGllcyBmcm9tIGEgdXNlciBhbmQN
CnRob3NlIGZyb20gdGhlIGNsaWVudCAocGFydGljdWxhcmx5IHdoZW4gdGhlIGNsaWVudCBpcyBy
dW5uaW5nIG9uIHRoZQ0KdXNlcidzIGRldmljZSkgaXMgcXVpdGUgcG9zc2libGUuDQoNCkNpYW8N
Ckhhbm5lcw0KDQpPbiAwMi8xOC8yMDE1IDA2OjM3IFBNLCBKdXN0aW4gUmljaGVyIHdyb3RlOg0K
PiBJ4oCZbGwgaW5jb3Jwb3JhdGUgdGhpcyBmZWVkYmFjayBpbnRvIGFub3RoZXIgZHJhZnQsIHRv
IGJlIHBvc3RlZCBieSB0aGUNCj4gZW5kIG9mIHRoZSB3ZWVrLiBUaGFua3MgZXZlcnlvbmUhDQo+
DQo+ICDigJQgSnVzdGluDQo+DQo+PiBPbiBGZWIgMTgsIDIwMTUsIGF0IDEwOjMwIEFNLCBLYXRo
bGVlbiBNb3JpYXJ0eQ0KPj4gPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPG1haWx0
bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4NCj4+IDxtYWlsdG86a2F0aGxlZW4u
bW9yaWFydHkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21h
aWwuY29tPj4+IHdyb3RlOg0KPj4NCj4+DQo+Pg0KPj4gT24gV2VkLCBGZWIgMTgsIDIwMTUgYXQg
MTA6MDcgQU0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2
ZTdqdGIuY29tPg0KPj4gPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZl
N2p0Yi5jb20+Pj4gd3JvdGU6DQo+Pg0KPj4gICAgIHNuaXANCj4+PiAgICAgT24gRmViIDE4LCAy
MDE1LCBhdCA2OjQ2IEFNLCBLYXRobGVlbiBNb3JpYXJ0eQ0KPj4+ICAgICA8a2F0aGxlZW4ubW9y
aWFydHkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwu
Y29tPg0KPj4+ICAgICA8bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPG1h
aWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4+PiB3cm90ZToNCj4+Pg0KPj4+
ICAgICAgICAgPiBUaGUgY2xpZW50X2lkICpjb3VsZCogYmUgc2hvcnQgbGl2ZWQsIGJ1dCB0aGV5
IHVzdWFsbHkgYXJlbid0LiBJIGRvbid0IHNlZSBhbnkgcGFydGljdWxhciBsb2dnaW5nIG9yIHRy
YWNraW5nIGNvbmNlcm5zIHVzaW5nIGEgZHluYW1pYyBPQXV0aCBjbGllbnQgYWJvdmUgdXNpbmcg
YW55IG90aGVyIHBpZWNlIG9mIHNvZnR3YXJlLCBldmVyLiBBcyBzdWNoLCBJIGRvbid0IHRoaW5r
IGl0IHJlcXVpcmVzIHNwZWNpYWwgY2FsbGluZyBvdXQgaGVyZS4NCj4+Pg0KPj4+DQo+Pj4gICAg
IEhlbHAgbWUgdW5kZXJzdGFuZCB3aHkgdGhlcmUgc2hvdWxkIG5vdCBiZSB0ZXh0IHRoYXQgc2hv
d3MgdGhpcw0KPj4+ICAgICBpcyBub3QgYW4gaXNzdWUgb3IgcGxlYXNlIHByb3Bvc2Ugc29tZSB0
ZXh0LiAgVGhpcyBpcyBib3VuZCB0bw0KPj4+ICAgICBjb21lIHVwIGluIElFU0cgcmV2aWV3cyBp
ZiBub3QgYWRkcmVzc2VkIHVwIGZyb250Lg0KPj4+DQo+Pj4NCj4+DQo+PiAgICAgVGhlIGNsaWVu
dF9pZCBpcyB1c2VkIHRvIGNvbW11bmljYXRlIHRvIHRoZSBBdXRob3JpemF0aW9uIHNlcnZlcg0K
Pj4gICAgIHRvIGdldCBhIGNvZGUgb3IgcmVmcmVzaCB0b2tlbi4gIFRob3NlIHRva2VucyB1bmlx
dWVseSBpZGVudGlmeQ0KPj4gICAgIHRoZSB1c2VyIGZyb20gYSBwcml2YWN5IHBlcnNwZWN0aXZl
Lg0KPj4gICAgIEl0IGlzIHRoZSBhY2Nlc3MgdG9rZW5zIHRoYXQgYXJlIHNlbnQgdG8gdGhlIFJT
IGFuZCB0aG9zZSBjYW4gYW5kDQo+PiAgICAgc2hvdWxkIGJlIHJvdGF0ZWQsIGJ1dCB0aGUgY2xp
ZW50KWlkIGlzIG5vdCBzZW50IHRvIHRoZSBSUyBpbg0KPj4gICAgIE9BdXRoIGFzIHBhcnQgb2Yg
dGhlIHNwZWMuDQo+Pg0KPj4gICAgIElmIHlvdSBkaWQgcm90YXRlIHRoZSBjbGllbnRfaWQgdGhl
biB0aGUgQVMgd291bGQgdHJhY2sgaXQgYWNyb3NzDQo+PiAgICAgcm90YXRpb25zLCBzbyBpdCB3
b3VsZG7igJl0IHJlYWxseSBhY2hpZXZlIGFueXRoaW5nLg0KPj4NCj4+ICAgICBPbmUgdGhpbmcg
d2UgZG9u4oCZdCBkbyBpcyBhbGxvdyB0aGUgY2xpZW50IHRvIHNwZWNpZnkgdGhlDQo+PiAgICAg
Y2xpZW50X2lkLCB0aGF0IGNvdWxkIGFsbG93IGNvcnJlbGF0aW9uIG9mIHRoZSBjbGllbnQgYWNy
b3NzDQo+PiAgICAgbXVsdGlwbGUgQVMgYW5kIHRoYXQgbWlnaHQgYmUgYSBwcml2YWN5IGlzc3Vl
LCBidXQgd2UgZG9u4oCZdCBhbGxvdyBpdC4NCj4+DQo+Pg0KPj4gVGhhbmtzLCBKb2huLiAgSXQg
bWF5IGJlIGhlbHBmdWwgdG8gYWRkIGluIHRoaXMgZXhwbGFuYXRpb24gdW5sZXNzDQo+PiB0aGVy
ZSBpcyBzb21lIHJlYXNvbiBub3QgdG8/DQo+Pg0KPj4NCj4+ICAgICBKb2huIEIuDQo+Pg0KPj4N
Cj4+DQo+Pg0KPj4gLS0NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBLYXRobGVlbg0KPj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IE9BdXRoIG1h
aWxpbmcgbGlzdA0KPj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPiA8bWFp
bHRvOk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4+DQo+PiBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+DQo+DQo+DQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlz
dA0KPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCg0KDQoNCi0tDQoNCkJlc3QgcmVn
YXJkcywNCkthdGhsZWVuDQo=

--_000_4E1F6AAD24975D4BA5B1680429673943A2264EC6TK5EX14MBXC290r_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1
IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O
b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi
c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0
ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT
dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt
YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl
OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu
ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk
aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+
PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1
ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo
YW5rcywgS2F0aGxlZW4uJm5ic3A7IFRoaXMgaGFkIGJlZW4gZGlzY3Vzc2VkIG9uIHRoZSBPQXV0
aCBsaXN0IGJlZm9yZSwgYnV0IGp1c3QgaW4gY2FzZSB5b3Ugb3IgdGhlIElFVEYgbGVnYWwgY291
bnNlbCB3ZXJlbuKAmXQgYXdhcmUgb2YgaXQg4oCTIHRoZSByZWFzb24gdGhhdCBpdOKAmXMNCiBP
SyB0byBwcm9kdWNlIGRlcml2YXRpdmUgd29ya3MgZnJvbSBPcGVuSUQgc3BlY3MsIGFzIGRyYWZ0
LWlldGYtb2F1dGgtZHluLXJlZyBkaWQsIGlzIHRoYXQgaXTigJlzIGV4cGxpY2l0bHkgYWxsb3dl
ZCBieSB0aGUgT3BlbklEIEZvdW5kYXRpb24uJm5ic3A7IFNlZSB0aGlzIHRleHQgYXQNCjxhIGhy
ZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LXJlZ2lzdHJhdGlvbi0x
XzAuaHRtbCNOb3RpY2VzIj5odHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1y
ZWdpc3RyYXRpb24tMV8wLmh0bWwjTm90aWNlczwvYT4g4oCTIHRoZSBzcGVjIGZyb20gd2hpY2gg
dGV4dCB3YXMgY29waWVkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj
ayI+VGhlIE9wZW5JRCBGb3VuZGF0aW9uIChPSURGKSBncmFudHMgdG8gYW55IENvbnRyaWJ1dG9y
LCBkZXZlbG9wZXIsIGltcGxlbWVudGVyLCBvciBvdGhlciBpbnRlcmVzdGVkIHBhcnR5IGEgbm9u
LWV4Y2x1c2l2ZSwNCiByb3lhbHR5IGZyZWUsIHdvcmxkd2lkZSBjb3B5cmlnaHQgbGljZW5zZSB0
byByZXByb2R1Y2UsIHByZXBhcmUgZGVyaXZhdGl2ZSB3b3JrcyBmcm9tLCBkaXN0cmlidXRlLCBw
ZXJmb3JtIGFuZCBkaXNwbGF5LCB0aGlzIEltcGxlbWVudGVycyBEcmFmdCBvciBGaW5hbCBTcGVj
aWZpY2F0aW9uIHNvbGVseSBmb3IgdGhlIHB1cnBvc2VzIG9mIChpKSBkZXZlbG9waW5nIHNwZWNp
ZmljYXRpb25zLCBhbmQgKGlpKSBpbXBsZW1lbnRpbmcgSW1wbGVtZW50ZXJzDQogRHJhZnRzIGFu
ZCBGaW5hbCBTcGVjaWZpY2F0aW9ucyBiYXNlZCBvbiBzdWNoIGRvY3VtZW50cywgcHJvdmlkZWQg
dGhhdCBhdHRyaWJ1dGlvbiBiZSBtYWRlIHRvIHRoZSBPSURGIGFzIHRoZSBzb3VyY2Ugb2YgdGhl
IG1hdGVyaWFsLCBidXQgdGhhdCBzdWNoIGF0dHJpYnV0aW9uIGRvZXMgbm90IGluZGljYXRlIGFu
IGVuZG9yc2VtZW50IGJ5IHRoZSBPSURGLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Zb3UgY291bGQgcGFzcyB0aGF0IG9uIHRvIHRo
ZSBhcHByb3ByaWF0ZSBJRVRGIGxlZ2FsIGNvdW5zZWwgaWYgdGhleeKAmXJlIG5vdCBhbHJlYWR5
IGF3YXJlIG9mIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9B
dXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+
S2F0aGxlZW4gTW9yaWFydHk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMjQs
IDIwMTUgMzowOCBQTTxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWc8YnI+DQo8Yj5D
Yzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0dd
IEFEIHJldmlldyBvZiBEcmFmdC1pZXRmLWR5bi1yZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlRoYW5rcyBmb3IgdXBkYXRpbmcgdGhlIGRyYWZ0LiZuYnNwOyBJIGp1c3Qgd2Fu
dCB0byBjb25maXJtIHRoYXQgSGFubmVzIGlzIG9rYXkgd2l0aCB0aGUgdXBkYXRlZCBkZWZpbml0
aW9ucyBhbmQgdXBkYXRlcyB0aGUgc2hlcGhlcmQgcmVwb3J0IHRvIHJlZmxlY3QgdGhhdC48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBp
cyBnZXR0aW5nIGhlbGQgdXAgYSBiaXQgd2hpbGUgd2Ugc29ydCB0aHJvdWdoIGNvcHlyaWdodCBv
ZiB0ZXh0IGZyb20gVU1BIGFuZCBPcGVuSUQuJm5ic3A7IFRoZSB0ZXh0IGZyb20gVU1BIHdlbnQg
aW50byBhbiBJRVRGIGRyYWZ0LCBzbyB0aGF0IHNob3VsZCBiZSB0aGUgcmVmZXJlbmNlIGFzIGl0
IGNsZWFycyB1cCBhbnkgcG9zc2libGUgaXNzdWVzIGFzIHRoZXkgcHJvdmlkZWQgdGhhdCB0ZXh0
IGluIGFuDQogSUVURiBkcmFmdC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjaGFpcnMgd2lsbCBiZSBoZWxwaW5nIHRvIHNv
cnQgb3V0IHRoZSByZXF1aXJlbWVudHMgd2l0aCBPcGVuSUQsIHBlciBvdXIgZGlzY3Vzc2lvbnMg
dGhlIElFVEYgdHJ1c3RlZXMuJm5ic3A7IEknbSBub3Qgc3VyZSBob3cgbG9uZyB0aGlzIHdpbGwg
dGFrZSwgYnV0IHdhbnRlZCB0byBwcm92aWRlIGEgc3RhdHVzIHNvIG5vIG9uZSB0aG91Z2h0IHRo
aXMgaGFkIGJlZW4gZHJvcHBlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAxOCwgMjAxNSBhdCAxMjo1NyBQTSwg
SGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0Bn
bXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgSnVzdGluLCBI
aSBKb2huLDxicj4NCjxicj4NCkkgYmVsaWV2ZSB0aGF0IHByb3Zpc2lvbmluZyBhIGNsaWVudCB3
aXRoIGEgdW5pcXVlIGlkICh3aGljaCBpcyB3aGF0IGE8YnI+DQpjbGllbnQgaWQvY2xpZW50IHNl
Y3JldCBpcykgYWxsb3dzIHNvbWUgZm9ybSBvZiBsaW5rYWJpbGl0eS4gV2hpbGUgaXQ8YnI+DQpt
YXkgYmUgcG9zc2libGUgdG8gYXNzb2NpYXRlIHRoZSBjbGllbnQgdG8gYSBzcGVjaWZpYyB1c2Vy
IEkgY291bGQgdmVyeTxicj4NCndlbGwgaW1hZ2luZSB0aGF0IHRoZSBjb3JyZWxhdGlvbiBiZXR3
ZWVuIGFjdGl2aXRpZXMgZnJvbSBhIHVzZXIgYW5kPGJyPg0KdGhvc2UgZnJvbSB0aGUgY2xpZW50
IChwYXJ0aWN1bGFybHkgd2hlbiB0aGUgY2xpZW50IGlzIHJ1bm5pbmcgb24gdGhlPGJyPg0KdXNl
cidzIGRldmljZSkgaXMgcXVpdGUgcG9zc2libGUuPGJyPg0KPGJyPg0KQ2lhbzxicj4NCkhhbm5l
czxicj4NCjxicj4NCk9uIDAyLzE4LzIwMTUgMDY6MzcgUE0sIEp1c3RpbiBSaWNoZXIgd3JvdGU6
PGJyPg0KJmd0OyBJ4oCZbGwgaW5jb3Jwb3JhdGUgdGhpcyBmZWVkYmFjayBpbnRvIGFub3RoZXIg
ZHJhZnQsIHRvIGJlIHBvc3RlZCBieSB0aGU8YnI+DQomZ3Q7IGVuZCBvZiB0aGUgd2Vlay4gVGhh
bmtzIGV2ZXJ5b25lITxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7IOKAlCBKdXN0aW48YnI+DQom
Z3Q7PGJyPg0KJmd0OyZndDsgT24gRmViIDE4LCAyMDE1LCBhdCAxMDozMCBBTSwgS2F0aGxlZW4g
TW9yaWFydHk8YnI+DQomZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthdGhsZWVuLm1vcmlh
cnR5LmlldGZAZ21haWwuY29tIj5rYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTwvYT48
YnI+DQomZ3Q7Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0
eS5pZXRmQGdtYWlsLmNvbSI+a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0
OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsgT24gV2VkLCBGZWIgMTgsIDIwMTUgYXQgMTA6MDcgQU0sIEpvaG4gQnJhZGxl
eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNv
bTwvYT48YnI+DQomZ3Q7Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3
anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7c25pcDxicj4NCiZndDsmZ3Q7Jmd0
OyZuYnNwOyAmbmJzcDsgJm5ic3A7T24gRmViIDE4LCAyMDE1LCBhdCA2OjQ2IEFNLCBLYXRobGVl
biBNb3JpYXJ0eTxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhy
ZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSI+a2F0aGxlZW4ubW9y
aWFydHkuaWV0ZkBnbWFpbC5jb208L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm
bmJzcDsmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdt
YWlsLmNvbSI+a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyZndDsgd3Jv
dGU6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyZndDsgVGhlIGNsaWVudF9pZCAqY291bGQqIGJlIHNob3J0IGxpdmVk
LCBidXQgdGhleSB1c3VhbGx5IGFyZW4ndC4gSSBkb24ndCBzZWUgYW55IHBhcnRpY3VsYXIgbG9n
Z2luZyBvciB0cmFja2luZyBjb25jZXJucyB1c2luZyBhIGR5bmFtaWMgT0F1dGggY2xpZW50IGFi
b3ZlIHVzaW5nIGFueSBvdGhlciBwaWVjZSBvZiBzb2Z0d2FyZSwgZXZlci4gQXMgc3VjaCwgSSBk
b24ndCB0aGluayBpdCByZXF1aXJlcyBzcGVjaWFsIGNhbGxpbmcNCiBvdXQgaGVyZS48YnI+DQom
Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i
c3A7ICZuYnNwO0hlbHAgbWUgdW5kZXJzdGFuZCB3aHkgdGhlcmUgc2hvdWxkIG5vdCBiZSB0ZXh0
IHRoYXQgc2hvd3MgdGhpczxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7aXMg
bm90IGFuIGlzc3VlIG9yIHBsZWFzZSBwcm9wb3NlIHNvbWUgdGV4dC4mbmJzcDsgVGhpcyBpcyBi
b3VuZCB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Y29tZSB1cCBpbiBJ
RVNHIHJldmlld3MgaWYgbm90IGFkZHJlc3NlZCB1cCBmcm9udC48YnI+DQomZ3Q7Jmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNw
OyAmbmJzcDtUaGUgY2xpZW50X2lkIGlzIHVzZWQgdG8gY29tbXVuaWNhdGUgdG8gdGhlIEF1dGhv
cml6YXRpb24gc2VydmVyPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3RvIGdldCBh
IGNvZGUgb3IgcmVmcmVzaCB0b2tlbi4mbmJzcDsgVGhvc2UgdG9rZW5zIHVuaXF1ZWx5IGlkZW50
aWZ5PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSB1c2VyIGZyb20gYSBwcml2
YWN5IHBlcnNwZWN0aXZlLjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtJdCBpcyB0
aGUgYWNjZXNzIHRva2VucyB0aGF0IGFyZSBzZW50IHRvIHRoZSBSUyBhbmQgdGhvc2UgY2FuIGFu
ZDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtzaG91bGQgYmUgcm90YXRlZCwgYnV0
IHRoZSBjbGllbnQpaWQgaXMgbm90IHNlbnQgdG8gdGhlIFJTIGluPGJyPg0KJmd0OyZndDsmbmJz
cDsgJm5ic3A7ICZuYnNwO09BdXRoIGFzIHBhcnQgb2YgdGhlIHNwZWMuPGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7SWYgeW91IGRpZCByb3RhdGUgdGhlIGNs
aWVudF9pZCB0aGVuIHRoZSBBUyB3b3VsZCB0cmFjayBpdCBhY3Jvc3M8YnI+DQomZ3Q7Jmd0OyZu
YnNwOyAmbmJzcDsgJm5ic3A7cm90YXRpb25zLCBzbyBpdCB3b3VsZG7igJl0IHJlYWxseSBhY2hp
ZXZlIGFueXRoaW5nLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu
YnNwO09uZSB0aGluZyB3ZSBkb27igJl0IGRvIGlzIGFsbG93IHRoZSBjbGllbnQgdG8gc3BlY2lm
eSB0aGU8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Y2xpZW50X2lkLCB0aGF0IGNv
dWxkIGFsbG93IGNvcnJlbGF0aW9uIG9mIHRoZSBjbGllbnQgYWNyb3NzPGJyPg0KJmd0OyZndDsm
bmJzcDsgJm5ic3A7ICZuYnNwO211bHRpcGxlIEFTIGFuZCB0aGF0IG1pZ2h0IGJlIGEgcHJpdmFj
eSBpc3N1ZSwgYnV0IHdlIGRvbuKAmXQgYWxsb3cgaXQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rcywgSm9obi4mbmJzcDsgSXQgbWF5IGJlIGhlbHBmdWwg
dG8gYWRkIGluIHRoaXMgZXhwbGFuYXRpb24gdW5sZXNzPGJyPg0KJmd0OyZndDsgdGhlcmUgaXMg
c29tZSByZWFzb24gbm90IHRvPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Sm9obiBCLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS08YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7Jmd0OyBLYXRobGVlbjxi
cj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPGJyPg0KJmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJl
Zj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8
YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPiZndDs8YnI+
DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7PGJyPg0KJmd0Ozxicj4N
CiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1h
aWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+
DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkthdGhsZWVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_4E1F6AAD24975D4BA5B1680429673943A2264EC6TK5EX14MBXC290r_--


From nobody Tue Feb 24 15:54:01 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA86F1A036A for ; Tue, 24 Feb 2015 15:53:59 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5fraRj2-WvC for ; Tue, 24 Feb 2015 15:53:57 -0800 (PST)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD821A0058 for ; Tue, 24 Feb 2015 15:53:56 -0800 (PST)
Received: by labgd6 with SMTP id gd6so344297lab.8 for ; Tue, 24 Feb 2015 15:53:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2bPfxkBJbk9Yc4d1pk3izLQOSV5/BLp57rDNLBdmh3Y=; b=c51LpN9bj/XTUaL55xoDiKQ5klNVpZlSqd0r9WHoAxqHDrxyofW/F5bGMGnShXPp3x YeKRyvVX1CKhx/5bFY6C1GHsdakdu0CValXUXkRW5kQpQWaotzorfIbl1+k/1KcE1+Gx Wyync71kH0YlNOepNhBxvVq4Ax7+GwkV4BE9sTvl884tyy0YWsNUDLLK4XYcJNPtQ0VT CrczpqEu212B0CASOOqe6olRuZuB3qqtPPrmuuMZr7RqJ0upoCZnto8FocTcTbu7eCym J7A3i/ATg4ZM6gKBGOhiBuXJOYsBfwarlTEAE9b+CbxmNtdVFiLqcZ/JPENyFEgV5vzQ errQ==
MIME-Version: 1.0
X-Received: by 10.152.8.229 with SMTP id u5mr429518laa.4.1424822035242; Tue, 24 Feb 2015 15:53:55 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Tue, 24 Feb 2015 15:53:55 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com>
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>   <54E4D2A5.5030705@gmx.net>  <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com>
Date: Tue, 24 Feb 2015 18:53:55 -0500
Message-ID: 
From: Kathleen Moriarty 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=089e0158ab60476389050fde3bc4
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Feb 2015 23:54:00 -0000

--089e0158ab60476389050fde3bc4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Mike,

On Tue, Feb 24, 2015 at 6:47 PM, Mike Jones 
wrote:

>  Thanks, Kathleen.  This had been discussed on the OAuth list before, but
> just in case you or the IETF legal counsel weren=E2=80=99t aware of it =
=E2=80=93 the reason
> that it=E2=80=99s OK to produce derivative works from OpenID specs, as
> draft-ietf-oauth-dyn-reg did, is that it=E2=80=99s explicitly allowed by =
the OpenID
> Foundation.  See this text at
> http://openid.net/specs/openid-connect-registration-1_0.html#Notices =E2=
=80=93
> the spec from which text was copied:
>
>
>
> The OpenID Foundation (OIDF) grants to any Contributor, developer,
> implementer, or other interested party a non-exclusive, royalty free,
> worldwide copyright license to reproduce, prepare derivative works from,
> distribute, perform and display, this Implementers Draft or Final
> Specification solely for the purposes of (i) developing specifications, a=
nd
> (ii) implementing Implementers Drafts and Final Specifications based on
> such documents, provided that attribution be made to the OIDF as the sour=
ce
> of the material, but that such attribution does not indicate an endorseme=
nt
> by the OIDF.
>
>
>
> You could pass that on to the appropriate IETF legal counsel if they=E2=
=80=99re
> not already aware of it.
>

Thank you.  This was in Hannes message that I sent to the trust to review
already.  I'll chat with the chairs when they resurface from day
jobs/travel and we will figure this out.

Thanks,
Kathleen

>
>
>                                                                 -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Kathleen
> Moriarty
> *Sent:* Tuesday, February 24, 2015 3:08 PM
> *To:* Hannes Tschofenig
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>
>
>
> Hello,
>
>
>
> Thanks for updating the draft.  I just want to confirm that Hannes is oka=
y
> with the updated definitions and updates the shepherd report to reflect
> that.
>
>
>
> This is getting held up a bit while we sort through copyright of text fro=
m
> UMA and OpenID.  The text from UMA went into an IETF draft, so that shoul=
d
> be the reference as it clears up any possible issues as they provided tha=
t
> text in an IETF draft.
>
>
>
> The chairs will be helping to sort out the requirements with OpenID, per
> our discussions the IETF trustees.  I'm not sure how long this will take,
> but wanted to provide a status so no one thought this had been dropped.
>
>
>
> Thanks.
>
>
>
> On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
>
> Hi Justin, Hi John,
>
> I believe that provisioning a client with a unique id (which is what a
> client id/client secret is) allows some form of linkability. While it
> may be possible to associate the client to a specific user I could very
> well imagine that the correlation between activities from a user and
> those from the client (particularly when the client is running on the
> user's device) is quite possible.
>
> Ciao
> Hannes
>
> On 02/18/2015 06:37 PM, Justin Richer wrote:
> > I=E2=80=99ll incorporate this feedback into another draft, to be posted=
 by the
> > end of the week. Thanks everyone!
> >
> >  =E2=80=94 Justin
> >
> >> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
> >>  >> > wrote:
> >>
> >>
> >>
> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley  >> > wrote:
> >>
> >>     snip
> >>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
> >>>      >>>     > wrote:
> >>>
> >>>         > The client_id *could* be short lived, but they usually
> aren't. I don't see any particular logging or tracking concerns using a
> dynamic OAuth client above using any other piece of software, ever. As
> such, I don't think it requires special calling out here.
> >>>
> >>>
> >>>     Help me understand why there should not be text that shows this
> >>>     is not an issue or please propose some text.  This is bound to
> >>>     come up in IESG reviews if not addressed up front.
> >>>
> >>>
> >>
> >>     The client_id is used to communicate to the Authorization server
> >>     to get a code or refresh token.  Those tokens uniquely identify
> >>     the user from a privacy perspective.
> >>     It is the access tokens that are sent to the RS and those can and
> >>     should be rotated, but the client)id is not sent to the RS in
> >>     OAuth as part of the spec.
> >>
> >>     If you did rotate the client_id then the AS would track it across
> >>     rotations, so it wouldn=E2=80=99t really achieve anything.
> >>
> >>     One thing we don=E2=80=99t do is allow the client to specify the
> >>     client_id, that could allow correlation of the client across
> >>     multiple AS and that might be a privacy issue, but we don=E2=80=99=
t allow
> it.
> >>
> >>
> >> Thanks, John.  It may be helpful to add in this explanation unless
> >> there is some reason not to?
> >>
> >>
> >>     John B.
> >>
> >>
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> Kathleen
> >> _______________________________________________
> >> 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
> >
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>



--=20

Best regards,
Kathleen

--089e0158ab60476389050fde3bc4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Mike,

On Tue, Feb 24, 2015 at 6:47 PM, Mike Jones <<=
a href=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jon=
es@microsoft.com> wrote:











Thanks, Kathleen.=C2=A0 T=
his had been discussed on the OAuth list before, but just in case you or th=
e IETF legal counsel weren=E2=80=99t aware of it =E2=80=93 the reason that =
it=E2=80=99s
 OK to produce derivative works from OpenID specs, as draft-ietf-oauth-dyn-=
reg did, is that it=E2=80=99s explicitly allowed by the OpenID Foundation.=
=C2=A0 See this text at
http://openid.net/specs/openid-connect-registration=
-1_0.html#Notices =E2=80=93 the spec from which text was copied:=



=C2=A0


The OpenID Foundation (OIDF) grants to any Contributor, devel=
oper, implementer, or other interested party a non-exclusive,
 royalty free, worldwide copyright license to reproduce, prepare derivative=
 works from, distribute, perform and display, this Implementers Draft or Fi=
nal Specification solely for the purposes of (i) developing specifications,=
 and (ii) implementing Implementers
 Drafts and Final Specifications based on such documents, provided that att=
ribution be made to the OIDF as the source of the material, but that such a=
ttribution does not indicate an endorsement by the OIDF.


=C2=A0


You could pass that on to=
 the appropriate IETF legal counsel if they=E2=80=99re not already aware of=
 it.

Thank you.=C2=
=A0 This was in Hannes message that I sent to the trust to review already.=
=C2=A0 I'll chat with the chairs when they resurface from day jobs/trav=
el and we will figure this out.

Thanks,
=
Kathleen


=C2=A0


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


=C2=A0


From: OAuth [m=
ailto:oauth-bou=
nces@ietf.org]
On Behalf Of Kathleen Moriarty

Sent: Tuesday, February 24, 2015 3:08 PM

To: Hannes Tschofenig

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg


=C2=A0




Hello,




=C2=A0






Thanks for updating the draft.=C2=A0 I just want to =
confirm that Hannes is okay with the updated definitions and updates the sh=
epherd report to reflect that.






=C2=A0






This is getting held up a bit while we sort through =
copyright of text from UMA and OpenID.=C2=A0 The text from UMA went into an=
 IETF draft, so that should be the reference as it clears up any possible i=
ssues as they provided that text in an
 IETF draft. =C2=A0






=C2=A0






The chairs will be helping to sort out the requireme=
nts with OpenID, per our discussions the IETF trustees.=C2=A0 I'm not s=
ure how long this will take, but wanted to provide a status so no one thoug=
ht this had been dropped.






=C2=A0






Thanks.








=C2=A0




On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig =
<hannes.t=
schofenig@gmx.net> wrote:


Hi Justin, Hi John,



I believe that provisioning a client with a unique id (which is what a

client id/client secret is) allows some form of linkability. While it

may be possible to associate the client to a specific user I could very

well imagine that the correlation between activities from a user and

those from the client (particularly when the client is running on the

user's device) is quite possible.



Ciao

Hannes



On 02/18/2015 06:37 PM, Justin Richer wrote:

> I=E2=80=99ll incorporate this feedback into another draft, to be poste=
d by the

> end of the week. Thanks everyone!

>

>=C2=A0 =E2=80=94 Justin

>

>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty

>> <kathleen.moriarty.ietf@gmail.com

>> <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:

>>

>>

>>

>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <ve7jtb@ve7jtb.com

>> <mailto:=
ve7jtb@ve7jtb.com>> wrote:

>>

>>=C2=A0 =C2=A0 =C2=A0snip

>>>=C2=A0 =C2=A0 =C2=A0On Feb 18, 2015, at 6:46 AM, Kathleen Moria=
rty

>>>=C2=A0 =C2=A0 =C2=A0<kathleen.moriarty.ietf@gmail.com

>>>=C2=A0 =C2=A0 =C2=A0<mailto:kathleen.moriarty.ietf@gmail.com&=
gt;> wrote:

>>>

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> The client_id *could* be=
 short lived, but they usually aren't. I don't see any particular l=
ogging or tracking concerns using a dynamic OAuth client above using any ot=
her piece of software, ever. As such, I don't think it requires special=
 calling
 out here.

>>>

>>>

>>>=C2=A0 =C2=A0 =C2=A0Help me understand why there should not be =
text that shows this

>>>=C2=A0 =C2=A0 =C2=A0is not an issue or please propose some text=
.=C2=A0 This is bound to

>>>=C2=A0 =C2=A0 =C2=A0come up in IESG reviews if not addressed up=
 front.

>>>

>>>

>>

>>=C2=A0 =C2=A0 =C2=A0The client_id is used to communicate to the Aut=
horization server

>>=C2=A0 =C2=A0 =C2=A0to get a code or refresh token.=C2=A0 Those tok=
ens uniquely identify

>>=C2=A0 =C2=A0 =C2=A0the user from a privacy perspective.

>>=C2=A0 =C2=A0 =C2=A0It is the access tokens that are sent to the RS=
 and those can and

>>=C2=A0 =C2=A0 =C2=A0should be rotated, but the client)id is not sen=
t to the RS in

>>=C2=A0 =C2=A0 =C2=A0OAuth as part of the spec.

>>

>>=C2=A0 =C2=A0 =C2=A0If you did rotate the client_id then the AS wou=
ld track it across

>>=C2=A0 =C2=A0 =C2=A0rotations, so it wouldn=E2=80=99t really achiev=
e anything.

>>

>>=C2=A0 =C2=A0 =C2=A0One thing we don=E2=80=99t do is allow the clie=
nt to specify the

>>=C2=A0 =C2=A0 =C2=A0client_id, that could allow correlation of the =
client across

>>=C2=A0 =C2=A0 =C2=A0multiple AS and that might be a privacy issue, =
but we don=E2=80=99t allow it.

>>

>>

>> Thanks, John.=C2=A0 It may be helpful to add in this explanation u=
nless

>> there is some reason not to?

>>

>>

>>=C2=A0 =C2=A0 =C2=A0John B.

>>

>>

>>

>>

>> --

>>

>> Best regards,

>> Kathleen

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org=
 <mailto:OAuth@i=
etf.org>

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






>

>

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

>

















=C2=A0




-- 






=C2=A0




Best regards,






Kathleen


















-- 

Best regards,
Kath=
leen




--089e0158ab60476389050fde3bc4--


From nobody Tue Feb 24 15:59:10 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1071A036A for ; Tue, 24 Feb 2015 15:59:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.312
X-Spam-Level: 
X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVpIiRvLaFQb for ; Tue, 24 Feb 2015 15:59:05 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1A21A0058 for ; Tue, 24 Feb 2015 15:59:05 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1ONx4BG006737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 24 Feb 2015 18:59:04 -0500
Received: from [10.10.51.118] (vpn-51-118.rdu2.redhat.com [10.10.51.118]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1ONx3Fc028086 for ; Tue, 24 Feb 2015 18:59:04 -0500
Message-ID: <54ED1047.2010408@redhat.com>
Date: Tue, 24 Feb 2015 18:59:03 -0500
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: oauth@ietf.org
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>   <54E4D2A5.5030705@gmx.net>  <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Feb 2015 23:59:07 -0000

Is there plans to derive from any other parts of openid connect and 
bring them into IETF/OAuth?

Thanks.

On 2/24/2015 6:47 PM, Mike Jones wrote:
> Thanks, Kathleen.  This had been discussed on the OAuth list before, but
> just in case you or the IETF legal counsel weren’t aware of it – the
> reason that it’s OK to produce derivative works from OpenID specs, as
> draft-ietf-oauth-dyn-reg did, is that it’s explicitly allowed by the
> OpenID Foundation.  See this text at
> http://openid.net/specs/openid-connect-registration-1_0.html#Notices –
> the spec from which text was copied:
>
> The OpenID Foundation (OIDF) grants to any Contributor, developer,
> implementer, or other interested party a non-exclusive, royalty free,
> worldwide copyright license to reproduce, prepare derivative works from,
> distribute, perform and display, this Implementers Draft or Final
> Specification solely for the purposes of (i) developing specifications,
> and (ii) implementing Implementers Drafts and Final Specifications based
> on such documents, provided that attribution be made to the OIDF as the
> source of the material, but that such attribution does not indicate an
> endorsement by the OIDF.
>
> You could pass that on to the appropriate IETF legal counsel if they’re
> not already aware of it.
>
>                                                                  -- Mike
>
> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Kathleen
> Moriarty
> *Sent:* Tuesday, February 24, 2015 3:08 PM
> *To:* Hannes Tschofenig
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>
> Hello,
>
> Thanks for updating the draft.  I just want to confirm that Hannes is
> okay with the updated definitions and updates the shepherd report to
> reflect that.
>
> This is getting held up a bit while we sort through copyright of text
> from UMA and OpenID.  The text from UMA went into an IETF draft, so that
> should be the reference as it clears up any possible issues as they
> provided that text in an IETF draft.
>
> The chairs will be helping to sort out the requirements with OpenID, per
> our discussions the IETF trustees.  I'm not sure how long this will
> take, but wanted to provide a status so no one thought this had been
> dropped.
>
> Thanks.
>
> On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig
> > wrote:
>
> Hi Justin, Hi John,
>
> I believe that provisioning a client with a unique id (which is what a
> client id/client secret is) allows some form of linkability. While it
> may be possible to associate the client to a specific user I could very
> well imagine that the correlation between activities from a user and
> those from the client (particularly when the client is running on the
> user's device) is quite possible.
>
> Ciao
> Hannes
>
> On 02/18/2015 06:37 PM, Justin Richer wrote:
>  > I’ll incorporate this feedback into another draft, to be posted by the
>  > end of the week. Thanks everyone!
>  >
>  >  — Justin
>  >
>  >> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>  >>  
>  >>  >> wrote:
>  >>
>  >>
>  >>
>  >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley  
>  >> >> wrote:
>  >>
>  >>     snip
>  >>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>  >>>      
>  >>>      >> wrote:
>  >>>
>  >>>         > The client_id *could* be short lived, but they usually
> aren't. I don't see any particular logging or tracking concerns using a
> dynamic OAuth client above using any other piece of software, ever. As
> such, I don't think it requires special calling out here.
>  >>>
>  >>>
>  >>>     Help me understand why there should not be text that shows this
>  >>>     is not an issue or please propose some text.  This is bound to
>  >>>     come up in IESG reviews if not addressed up front.
>  >>>
>  >>>
>  >>
>  >>     The client_id is used to communicate to the Authorization server
>  >>     to get a code or refresh token.  Those tokens uniquely identify
>  >>     the user from a privacy perspective.
>  >>     It is the access tokens that are sent to the RS and those can and
>  >>     should be rotated, but the client)id is not sent to the RS in
>  >>     OAuth as part of the spec.
>  >>
>  >>     If you did rotate the client_id then the AS would track it across
>  >>     rotations, so it wouldn’t really achieve anything.
>  >>
>  >>     One thing we don’t do is allow the client to specify the
>  >>     client_id, that could allow correlation of the client across
>  >>     multiple AS and that might be a privacy issue, but we don’t
> allow it.
>  >>
>  >>
>  >> Thanks, John.  It may be helpful to add in this explanation unless
>  >> there is some reason not to?
>  >>
>  >>
>  >>     John B.
>  >>
>  >>
>  >>
>  >>
>  >> --
>  >>
>  >> Best regards,
>  >> Kathleen
>  >> _______________________________________________
>  >> 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
>  >
>
>
>
> --
>
> Best regards,
>
> Kathleen
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Tue Feb 24 16:29:02 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF881A1A28 for ; Tue, 24 Feb 2015 16:29:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrBu0b-2Ixgb for ; Tue, 24 Feb 2015 16:28:59 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1991A0396 for ; Tue, 24 Feb 2015 16:28:59 -0800 (PST)
Received: from DM2PR03CA0033.namprd03.prod.outlook.com (10.141.96.32) by DM2PR03MB397.namprd03.prod.outlook.com (10.141.84.139) with Microsoft SMTP Server (TLS) id 15.1.106.11; Wed, 25 Feb 2015 00:28:56 +0000
Received: from BN1BFFO11FD038.protection.gbl (2a01:111:f400:7c10::1:193) by DM2PR03CA0033.outlook.office365.com (2a01:111:e400:2428::32) with Microsoft SMTP Server (TLS) id 15.1.99.9 via Frontend Transport; Wed, 25 Feb 2015 00:28:56 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD038.mail.protection.outlook.com (10.58.144.101) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Wed, 25 Feb 2015 00:28:55 +0000
Received: from TK5EX14MBXC290.redmond.corp.microsoft.com ([169.254.1.42]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0224.003; Wed, 25 Feb 2015 00:28:25 +0000
From: Mike Jones 
To: Bill Burke , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
Thread-Index: AQHQRk+KdTW6focrw0+qa3R3HLsnGpzsbP6AgAD/rACABoKlgIACl1OAgAAGGYCAAAZBAIAAI6aAgAAFmYCACcSKAIAACNkAgAAFfYCAAAgkAA==
Date: Wed, 25 Feb 2015 00:28:24 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2265169@TK5EX14MBXC290.redmond.corp.microsoft.com>
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>   <54E4D2A5.5030705@gmx.net>  <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com> <54ED1047.2010408@redhat.com>
In-Reply-To: <54ED1047.2010408@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.73]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com;  client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; redhat.com; dkim=none (message not signed) header.d=none;
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(164054003)(479174004)(189002)(51704005)(24454002)(52604005)(199003)(13464003)(377454003)(62966003)(66066001)(55846006)(2501003)(2656002)(16601075003)(77156002)(87936001)(19580405001)(19580395003)(86612001)(46406003)(104016003)(6806004)(23726002)(97736003)(54356999)(85806002)(50986999)(76176999)(26826002)(46102003)(69596002)(33656002)(587094005)(106466001)(92566002)(106116001)(97756001)(81156004)(50466002)(2900100001)(86362001)(64706001)(47776003)(2920100001)(2950100001)(15395725005)(107886001)(93886004)(102836002)(15975445007)(230783001)(68736005)(117326003)(2690400003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB397; H:mail.microsoft.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB397;
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005004); SRVR:DM2PR03MB397; BCL:0; PCL:0; RULEID:; SRVR:DM2PR03MB397; 
X-Forefront-PRVS: 049897979A
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2015 00:28:55.7455 (UTC)
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR03MB397
Archived-At: 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Feb 2015 00:29:01 -0000

Not that I'm aware of.

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Bill Burke
Sent: Tuesday, February 24, 2015 3:59 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

Is there plans to derive from any other parts of openid connect and bring t=
hem into IETF/OAuth?

Thanks.

On 2/24/2015 6:47 PM, Mike Jones wrote:
> Thanks, Kathleen.  This had been discussed on the OAuth list before,=20
> but just in case you or the IETF legal counsel weren't aware of it -=20
> the reason that it's OK to produce derivative works from OpenID specs,=20
> as draft-ietf-oauth-dyn-reg did, is that it's explicitly allowed by=20
> the OpenID Foundation.  See this text at=20
> http://openid.net/specs/openid-connect-registration-1_0.html#Notices -=20
> the spec from which text was copied:
>
> The OpenID Foundation (OIDF) grants to any Contributor, developer,=20
> implementer, or other interested party a non-exclusive, royalty free,=20
> worldwide copyright license to reproduce, prepare derivative works=20
> from, distribute, perform and display, this Implementers Draft or=20
> Final Specification solely for the purposes of (i) developing=20
> specifications, and (ii) implementing Implementers Drafts and Final=20
> Specifications based on such documents, provided that attribution be=20
> made to the OIDF as the source of the material, but that such=20
> attribution does not indicate an endorsement by the OIDF.
>
> You could pass that on to the appropriate IETF legal counsel if=20
> they're not already aware of it.
>
>                                                                  --=20
> Mike
>
> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Kathleen=20
> Moriarty
> *Sent:* Tuesday, February 24, 2015 3:08 PM
> *To:* Hannes Tschofenig
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>
> Hello,
>
> Thanks for updating the draft.  I just want to confirm that Hannes is=20
> okay with the updated definitions and updates the shepherd report to=20
> reflect that.
>
> This is getting held up a bit while we sort through copyright of text=20
> from UMA and OpenID.  The text from UMA went into an IETF draft, so=20
> that should be the reference as it clears up any possible issues as=20
> they provided that text in an IETF draft.
>
> The chairs will be helping to sort out the requirements with OpenID,=20
> per our discussions the IETF trustees.  I'm not sure how long this=20
> will take, but wanted to provide a status so no one thought this had=20
> been dropped.
>
> Thanks.
>
> On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig=20
> > wrote:
>
> Hi Justin, Hi John,
>
> I believe that provisioning a client with a unique id (which is what a=20
> client id/client secret is) allows some form of linkability. While it=20
> may be possible to associate the client to a specific user I could=20
> very well imagine that the correlation between activities from a user=20
> and those from the client (particularly when the client is running on=20
> the user's device) is quite possible.
>
> Ciao
> Hannes
>
> On 02/18/2015 06:37 PM, Justin Richer wrote:
>  > I'll incorporate this feedback into another draft, to be posted by=20
> the  > end of the week. Thanks everyone!
>  >
>  >  - Justin
>  >
>  >> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty  >>=20
>  
>  >>  >> wrote:
>  >>
>  >>
>  >>
>  >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley    >>  >> wrote:
>  >>
>  >>     snip
>  >>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>  >>>      
>  >>>      >> wrote:
>  >>>
>  >>>         > The client_id *could* be short lived, but they usually
> aren't. I don't see any particular logging or tracking concerns using=20
> a dynamic OAuth client above using any other piece of software, ever.=20
> As such, I don't think it requires special calling out here.
>  >>>
>  >>>
>  >>>     Help me understand why there should not be text that shows this
>  >>>     is not an issue or please propose some text.  This is bound to
>  >>>     come up in IESG reviews if not addressed up front.
>  >>>
>  >>>
>  >>
>  >>     The client_id is used to communicate to the Authorization server
>  >>     to get a code or refresh token.  Those tokens uniquely identify
>  >>     the user from a privacy perspective.
>  >>     It is the access tokens that are sent to the RS and those can and
>  >>     should be rotated, but the client)id is not sent to the RS in
>  >>     OAuth as part of the spec.
>  >>
>  >>     If you did rotate the client_id then the AS would track it across
>  >>     rotations, so it wouldn't really achieve anything.
>  >>
>  >>     One thing we don't do is allow the client to specify the
>  >>     client_id, that could allow correlation of the client across
>  >>     multiple AS and that might be a privacy issue, but we don't
> allow it.
>  >>
>  >>
>  >> Thanks, John.  It may be helpful to add in this explanation unless =20
> >> there is some reason not to?
>  >>
>  >>
>  >>     John B.
>  >>
>  >>
>  >>
>  >>
>  >> --
>  >>
>  >> Best regards,
>  >> Kathleen
>  >> _______________________________________________
>  >> OAuth mailing list
>  >> OAuth@ietf.org   >  >>=20
> https://www.ietf.org/mailman/listinfo/oauth
>
>  >
>  >
>  >
>  > _______________________________________________
>  > OAuth mailing list
>  > OAuth@ietf.org   >=20
> https://www.ietf.org/mailman/listinfo/oauth
>  >
>
>
>
> --
>
> Best regards,
>
> Kathleen
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

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


From nobody Tue Feb 24 17:02:11 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBB51A1A36 for ; Tue, 24 Feb 2015 17:02:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level: 
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUg5gGP8vdna for ; Tue, 24 Feb 2015 17:02:07 -0800 (PST)
Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4732F1A1A0B for ; Tue, 24 Feb 2015 17:02:07 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id v10so522873qac.6 for ; Tue, 24 Feb 2015 17:02:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5rwPwPQdhuDHpbHRyEB0Z5/TqsbrBhSCNUf0eootb+Q=; b=VkxLpGHpg0OgP6bbeqHNWySnrDH1C5q9VjWkX+qJdaFixo1ssudKt29NSTMcnyRV0s IknlIe0Z7AsaRaMG4l+1kPVD9YplybqAHhvmgWQqUDw0EcudW0dlYte0NaSW4w6fH0yY FQ2pNhmqJMLuqurnZiYy3vpBGaCTgecvTAv4mla2guFjdHBTxUYKoB52sm/vfXV4WVI3 +3QlCN1ZzOjfculaWKVK8HU/4Sy7DjOQ9ZbRZgIUKmfG9/dHX57qLG0HD50h8UNouVEv XOR2A8aEpN+dREALnFevnxVbzYT6q4N0JqWAVQVfzwvlz2w3c8Ef9gLTLj9qRGDCDhke RfLA==
X-Received: by 10.140.233.148 with SMTP id e142mr1530377qhc.15.1424826126486;  Tue, 24 Feb 2015 17:02:06 -0800 (PST)
Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id 8sm426634qgk.33.2015.02.24.17.02.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 17:02:05 -0800 (PST)
From: Kathleen Moriarty 
X-Google-Original-From: Kathleen Moriarty 
Content-Type: multipart/alternative; boundary=Apple-Mail-2D5E1D14-044E-4180-9C88-839B97A7E821
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (11D257)
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com>
Date: Tue, 24 Feb 2015 20:02:01 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <3AAFF7CB-1C84-4BD5-B8BF-9162660BD57D@gmail.com>
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>   <54E4D2A5.5030705@gmx.net>  <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com>
To: Mike Jones 
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Feb 2015 01:02:10 -0000

--Apple-Mail-2D5E1D14-044E-4180-9C88-839B97A7E821
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I was able to get a response, I'm guessing the question got too buried in th=
e thread over the past few days.

Essentially, it is the contributors responsibility to ensure it's ok to incl=
ude text.  If this was Mike or someone else that believe it is fine, then we=
 can proceed.

Hannes may need to update the shepherd report and I'll read through the upda=
ted version tomorrow.  I'll try to get a review out if the accompanying mana=
gement draft tomorrow too.

Thanks,
Kathleen=20

Sent from my iPhone

> On Feb 24, 2015, at 6:47 PM, Mike Jones  wrot=
e:
>=20
> Thanks, Kathleen.  This had been discussed on the OAuth list before, but j=
ust in case you or the IETF legal counsel weren=E2=80=99t aware of it =E2=80=
=93 the reason that it=E2=80=99s OK to produce derivative works from OpenID s=
pecs, as draft-ietf-oauth-dyn-reg did, is that it=E2=80=99s explicitly allow=
ed by the OpenID Foundation.  See this text at http://openid.net/specs/openi=
d-connect-registration-1_0.html#Notices =E2=80=93 the spec from which text w=
as copied:
> =20
> The OpenID Foundation (OIDF) grants to any Contributor, developer, impleme=
nter, or other interested party a non-exclusive, royalty free, worldwide cop=
yright license to reproduce, prepare derivative works from, distribute, perf=
orm and display, this Implementers Draft or Final Specification solely for t=
he purposes of (i) developing specifications, and (ii) implementing Implemen=
ters Drafts and Final Specifications based on such documents, provided that a=
ttribution be made to the OIDF as the source of the material, but that such a=
ttribution does not indicate an endorsement by the OIDF.
> =20
> You could pass that on to the appropriate IETF legal counsel if they=E2=80=
=99re not already aware of it.
> =20
>                                                                 -- Mike
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen Moriarty=

> Sent: Tuesday, February 24, 2015 3:08 PM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
> =20
> Hello,
> =20
> Thanks for updating the draft.  I just want to confirm that Hannes is okay=
 with the updated definitions and updates the shepherd report to reflect tha=
t.
> =20
> This is getting held up a bit while we sort through copyright of text from=
 UMA and OpenID.  The text from UMA went into an IETF draft, so that should b=
e the reference as it clears up any possible issues as they provided that te=
xt in an IETF draft. =20
> =20
> The chairs will be helping to sort out the requirements with OpenID, per o=
ur discussions the IETF trustees.  I'm not sure how long this will take, but=
 wanted to provide a status so no one thought this had been dropped.
> =20
> Thanks.
> =20
> On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig  wrote:
> Hi Justin, Hi John,
>=20
> I believe that provisioning a client with a unique id (which is what a
> client id/client secret is) allows some form of linkability. While it
> may be possible to associate the client to a specific user I could very
> well imagine that the correlation between activities from a user and
> those from the client (particularly when the client is running on the
> user's device) is quite possible.
>=20
> Ciao
> Hannes
>=20
> On 02/18/2015 06:37 PM, Justin Richer wrote:
> > I=E2=80=99ll incorporate this feedback into another draft, to be posted b=
y the
> > end of the week. Thanks everyone!
> >
> >  =E2=80=94 Justin
> >
> >> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
> >>  >> > wrote:
> >>
> >>
> >>
> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley  >> > wrote:
> >>
> >>     snip
> >>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
> >>>      >>>     > wrote:
> >>>
> >>>         > The client_id *could* be short lived, but they usually aren'=
t. I don't see any particular logging or tracking concerns using a dynamic O=
Auth client above using any other piece of software, ever. As such, I don't t=
hink it requires special calling out here.
> >>>
> >>>
> >>>     Help me understand why there should not be text that shows this
> >>>     is not an issue or please propose some text.  This is bound to
> >>>     come up in IESG reviews if not addressed up front.
> >>>
> >>>
> >>
> >>     The client_id is used to communicate to the Authorization server
> >>     to get a code or refresh token.  Those tokens uniquely identify
> >>     the user from a privacy perspective.
> >>     It is the access tokens that are sent to the RS and those can and
> >>     should be rotated, but the client)id is not sent to the RS in
> >>     OAuth as part of the spec.
> >>
> >>     If you did rotate the client_id then the AS would track it across
> >>     rotations, so it wouldn=E2=80=99t really achieve anything.
> >>
> >>     One thing we don=E2=80=99t do is allow the client to specify the
> >>     client_id, that could allow correlation of the client across
> >>     multiple AS and that might be a privacy issue, but we don=E2=80=99t=
 allow it.
> >>
> >>
> >> Thanks, John.  It may be helpful to add in this explanation unless
> >> there is some reason not to?
> >>
> >>
> >>     John B.
> >>
> >>
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> Kathleen
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org 
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>=20
>=20
>=20
> =20
> --
> =20
> Best regards,
> Kathleen

--Apple-Mail-2D5E1D14-044E-4180-9C88-839B97A7E821
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I was able to get a response, I'm gues=
sing the question got too buried in the thread over the past few days.
=


Essentially, it is the contributors responsibility to en=
sure it's ok to include text.  If this was Mike or someone else that be=
lieve it is fine, then we can proceed.

Hannes may n=
eed to update the shepherd report and I'll read through the updated version t=
omorrow.  I'll try to get a review out if the accompanying management d=
raft tomorrow too.

Thanks,
Kathleen =


Sent from my iPhone

On Feb 24, 2015, at 6:47 PM, Mike J=
ones <Michael.Jones@micros=
oft.com> wrote:











Thanks, Kathleen.  Thi=
s had been discussed on the OAuth list before, but just in case you or the I=
ETF legal counsel weren=E2=80=99t aware of it =E2=80=93 the reason that it=E2=
=80=99s
 OK to produce derivative works from OpenID specs, as draft-ietf-oauth-dyn-r=
eg did, is that it=E2=80=99s explicitly allowed by the OpenID Foundation.&nb=
sp; See this text at
http://openid.net/specs/openid-connect-registration-1_0.html#Notices =E2=80=93 the spec from which text was copied:


 

The OpenID Foundation (OIDF) grants to any Contributor, developer,=
 implementer, or other interested party a non-exclusive,
 royalty free, worldwide copyright license to reproduce, prepare derivative w=
orks from, distribute, perform and display, this Implementers Draft or Final=
 Specification solely for the purposes of (i) developing specifications, and=
 (ii) implementing Implementers
 Drafts and Final Specifications based on such documents, provided that attr=
ibution be made to the OIDF as the source of the material, but that such att=
ribution does not indicate an endorsement by the OIDF.


 

You could pass that on to t=
he appropriate IETF legal counsel if they=E2=80=99re not already aware of it=
.


 

    &nb=
sp;            &=
nbsp;            =
;            &nb=
sp;            &=
nbsp;        -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Kathleen Moriarty

Sent: Tuesday, February 24, 2015 3:08 PM

To: Hannes Tschofenig

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg


 




Hello,




 






Thanks for updating the draft.  I just want to c=
onfirm that Hannes is okay with the updated definitions and updates the shep=
herd report to reflect that.






 






This is getting held up a bit while we sort through c=
opyright of text from UMA and OpenID.  The text from UMA went into an I=
ETF draft, so that should be the reference as it clears up any possible issu=
es as they provided that text in an
 IETF draft.  






 






The chairs will be helping to sort out the requiremen=
ts with OpenID, per our discussions the IETF trustees.  I'm not sure ho=
w long this will take, but wanted to provide a status so no one thought this=
 had been dropped.






 






Thanks.








 




On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig &=
lt;hannes.tsc=
hofenig@gmx.net> wrote:


Hi Justin, Hi John,



I believe that provisioning a client with a unique id (which is what a

client id/client secret is) allows some form of linkability. While it

may be possible to associate the client to a specific user I could very

well imagine that the correlation between activities from a user and

those from the client (particularly when the client is running on the

user's device) is quite possible.



Ciao

Hannes



On 02/18/2015 06:37 PM, Justin Richer wrote:

> I=E2=80=99ll incorporate this feedback into another draft, to be posted=
 by the

> end of the week. Thanks everyone!

>

>  =E2=80=94 Justin

>

>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty

>> <kathleen.mo=
riarty.ietf@gmail.com

>> <mailto:kath=
leen.moriarty.ietf@gmail.com>> wrote:

>>

>>

>>

>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <ve7jtb@ve7jtb.com

>> <mailto:ve7jtb@ve7jtb.com>> wrote:

>>

>>     snip

>>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriar=
ty

>>>     <kathleen.moriarty.ietf@gmail.com

>>>     <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:

>>>

>>>         > The client_id *could* be s=
hort lived, but they usually aren't. I don't see any particular logging or t=
racking concerns using a dynamic OAuth client above using any other piece of=
 software, ever. As such, I don't think it requires special calling
 out here.

>>>

>>>

>>>     Help me understand why there should not be t=
ext that shows this

>>>     is not an issue or please propose some text.=
  This is bound to

>>>     come up in IESG reviews if not addressed up f=
ront.

>>>

>>>

>>

>>     The client_id is used to communicate to the Auth=
orization server

>>     to get a code or refresh token.  Those toke=
ns uniquely identify

>>     the user from a privacy perspective.

>>     It is the access tokens that are sent to the RS a=
nd those can and

>>     should be rotated, but the client)id is not sent=
 to the RS in

>>     OAuth as part of the spec.

>>

>>     If you did rotate the client_id then the AS woul=
d track it across

>>     rotations, so it wouldn=E2=80=99t really achieve=
 anything.

>>

>>     One thing we don=E2=80=99t do is allow the clien=
t to specify the

>>     client_id, that could allow correlation of the c=
lient across

>>     multiple AS and that might be a privacy issue, b=
ut we don=E2=80=99t allow it.

>>

>>

>> Thanks, John.  It may be helpful to add in this explanation un=
less

>> there is some reason not to?

>>

>>

>>     John B.

>>

>>

>>

>>

>> --

>>

>> Best regards,

>> Kathleen

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org <mailto:OAuth@ietf.org>

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






>

>

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

>

















 




-- 






 




Best regards,






Kathleen














=

--Apple-Mail-2D5E1D14-044E-4180-9C88-839B97A7E821--


From nobody Tue Feb 24 17:55:12 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0433C1A8871 for ; Tue, 24 Feb 2015 17:55:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkJSKDx49Tek for ; Tue, 24 Feb 2015 17:55:08 -0800 (PST)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B301A884E for ; Tue, 24 Feb 2015 17:55:08 -0800 (PST)
Received: by qcwb13 with SMTP id b13so729452qcw.7 for ; Tue, 24 Feb 2015 17:55:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Wo/6JADk6fq2fLQ7VHpSqDI5nL7qTKhmpYSx8geDufc=; b=K4rxjo3FgUD/rkg8jTyCs5VsGhvQnpDzDeGA/TQd/FDcrDpW6+PBryY3Md0BW8cFHU 6V7x6+IKwsbDEA5hXz06oWxJ23vQzuq8Jv6LXAjIgEIOVkmhdixu1kdBp/anRulUMgPe MNlcp5yOuh3WX4yJ9I9T8xNATcdjnL2THn5GRgeL6bXRymuiW5ATCdApq8jTyDRu8Z+r zIGYzOgm/Hsn8WGOo4EE0us2hKoHscT/lD2XKUro0S4vqGUtlvOAn3vCWdTruQnnjyh4 1Er9lt8Hx9p37n3PGjC2x1i4JFtaBIkDHJfHqqo70PYTOyqgsWRVoTeg+lTlJ/YeSk64 f2aw==
X-Gm-Message-State: ALoCoQkL/LStZEv/sWIp0CcwCr8x0xUj8xIOqRv5hPv1tuyD+GpP0VWCK7zn1WfLlSz5P+A8NEfp
X-Received: by 10.140.152.72 with SMTP id 69mr1828369qhy.53.1424829307821; Tue, 24 Feb 2015 17:55:07 -0800 (PST)
Received: from [192.168.4.129] (ip-64-134-240-44.public.wayport.net. [64.134.240.44]) by mx.google.com with ESMTPSA id y8sm30671785qal.14.2015.02.24.17.55.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 17:55:07 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_D14F7387-7690-4074-A211-59E51993B3DB"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: <54E4D2A5.5030705@gmx.net>
Date: Tue, 24 Feb 2015 20:55:04 -0500
Message-Id: 
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>   <54E4D2A5.5030705@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Feb 2015 01:55:11 -0000

--Apple-Mail=_D14F7387-7690-4074-A211-59E51993B3DB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Yes but it is authenticating the client to the AS as part of the =
resource owners consent.  =20

Ther eis a one to one mapping of resource owner to client in that case.=20=


The client ID is no more identifying than the refresh token that maps to =
the RO by design.

Yes the grant identifies the RO in some way.  The client_id and secret =
prevent that from being used in a different client if the bearer token =
leaks.

Remember the client_id is going to be different at different AS as each =
will have a separate registration.
If the client_id was fixed across multiple AS then it would be a =
correlation issue, but that is not the case.

Perhaps I am not understanding the concern?

John B.

> On Feb 18, 2015, at 12:57 PM, Hannes Tschofenig =
 wrote:
>=20
> Hi Justin, Hi John,
>=20
> I believe that provisioning a client with a unique id (which is what a
> client id/client secret is) allows some form of linkability. While it
> may be possible to associate the client to a specific user I could =
very
> well imagine that the correlation between activities from a user and
> those from the client (particularly when the client is running on the
> user's device) is quite possible.
>=20
> Ciao
> Hannes
>=20
> On 02/18/2015 06:37 PM, Justin Richer wrote:
>> I=92ll incorporate this feedback into another draft, to be posted by =
the
>> end of the week. Thanks everyone!
>>=20
>> =97 Justin
>>=20
>>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>>> >> > wrote:
>>>=20
>>>=20
>>>=20
>>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley >> > wrote:
>>>=20
>>>    snip
>>>>    On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>>>    >>>    > wrote:
>>>>=20
>>>>> The client_id *could* be short lived, but they usually aren't. I =
don't see any particular logging or tracking concerns using a dynamic =
OAuth client above using any other piece of software, ever. As such, I =
don't think it requires special calling out here.
>>>>=20
>>>>=20
>>>>    Help me understand why there should not be text that shows this
>>>>    is not an issue or please propose some text.  This is bound to
>>>>    come up in IESG reviews if not addressed up front.=20
>>>>=20
>>>>=20
>>>=20
>>>    The client_id is used to communicate to the Authorization server
>>>    to get a code or refresh token.  Those tokens uniquely identify
>>>    the user from a privacy perspective.=20
>>>    It is the access tokens that are sent to the RS and those can and
>>>    should be rotated, but the client)id is not sent to the RS in
>>>    OAuth as part of the spec.=20
>>>=20
>>>    If you did rotate the client_id then the AS would track it across
>>>    rotations, so it wouldn=92t really achieve anything.
>>>=20
>>>    One thing we don=92t do is allow the client to specify the
>>>    client_id, that could allow correlation of the client across
>>>    multiple AS and that might be a privacy issue, but we don=92t =
allow it.
>>>=20
>>>=20
>>> Thanks, John.  It may be helpful to add in this explanation unless
>>> there is some reason not to?=20
>>>=20
>>>=20
>>>    John B.
>>>=20
>>>=20
>>>=20
>>>=20
>>> --=20
>>>=20
>>> Best regards,
>>> Kathleen
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_D14F7387-7690-4074-A211-59E51993B3DB
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMjUwMTU1MDVaMCMGCSqGSIb3DQEJBDEWBBSCaKs8DYGS5CkZAwCf6fDh
9S+NWTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCk3eA6sskvI6b66SId3411qx3/6bXx9YG2kOGLAQgnO+2pAzHfhDgW
ORj5nVo/QmdPiJxgizfbT4P1f7qKArL6WZAy9+GkGozGTRXqknkAD/QSohhBEPPL3B8d8G7VHVzB
C7mSthdjr2WMzBh7unBqUYNLNQA0ItqTrow6fLnWo8sNm0goxrOVC58gzEnv6ygefCK1rt2+HM0a
PN+qUkuAR4VPXYkirRlhuu7iRyAbM6iYj+X5nF/32YJSYq9mDgHYKBr98uMpFivBZODiVACaYQt5
y5kCU5iqYiuJbr2AzZikmV6Vm0vISRkru1LzWmF2uidIy1bGDOXDXZ1XKtOVAAAAAAAA
--Apple-Mail=_D14F7387-7690-4074-A211-59E51993B3DB--


From nobody Tue Feb 24 18:04:07 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0C21A9073 for ; Tue, 24 Feb 2015 18:04:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PURgwCli-S9t for ; Tue, 24 Feb 2015 18:04:02 -0800 (PST)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487EF1A039F for ; Tue, 24 Feb 2015 18:04:02 -0800 (PST)
Received: by mail-qg0-f48.google.com with SMTP id a108so775351qge.7 for ; Tue, 24 Feb 2015 18:04:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=snJPUANi14XnphyE8GamMoE4hIZUqy8A4qm79QcYFww=; b=VPhObGD0Pt8MUaPMam0LKbBVVWSQSHZFgvHMPAY5rQkZAWH+ulXNinSwCirZo8dVt1 /QsLZMUYxYjCJIIWdpN6fOPYpGjQvd+pbaDULtv2NsseBupyAvDimi6L7HN9CHDpzs8F U6YcCV0sS7W1mDEKqrd13AM0N8R9yUCy+woUugLI/EeICjRdBIGB7K13xHgXUnxjcI7d OaT72sFmldSE7M9OzI+KgdYxR4VEk2jAWziEqfme+1QJ4IshsgE88fDvqXB2pmyg7Qg2 C0awkneivbTrPupqG7qILh/vHUUu4Z+DvrN5kkMjiZs1TmdsZkJvDqONYSy/d5ZwtlSo vk5A==
X-Gm-Message-State: ALoCoQliVyyj+UVSnn0yD9px6avQHptiGcraka5G7FuUW8n//S+8aIGH32Y6mYacios894wLc2XL
X-Received: by 10.140.192.15 with SMTP id n15mr2165145qha.28.1424829841344; Tue, 24 Feb 2015 18:04:01 -0800 (PST)
Received: from [192.168.4.129] (ip-64-134-240-44.public.wayport.net. [64.134.240.44]) by mx.google.com with ESMTPSA id 201sm20687545qhb.32.2015.02.24.18.03.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 18:04:00 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_4E15337C-1843-4560-ACE8-5340F49A130A"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: <3AAFF7CB-1C84-4BD5-B8BF-9162660BD57D@gmail.com>
Date: Tue, 24 Feb 2015 21:03:27 -0500
Message-Id: <8C0D57C9-3E4C-4384-A10B-8A0D57F2F75B@ve7jtb.com>
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>   <54E4D2A5.5030705@gmx.net>  <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com> <3AAFF7CB-1C84-4BD5-B8BF-9162660BD57D@gmail.com>
To: Kathleen Moriarty 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Feb 2015 02:04:06 -0000

--Apple-Mail=_4E15337C-1843-4560-ACE8-5340F49A130A
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_03BAF2AC-421A-4A9D-82DD-15FBF635CAEA"


--Apple-Mail=_03BAF2AC-421A-4A9D-82DD-15FBF635CAEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes as one of the Authors and a officer of the OpenID Foundation the =
text was contributed in accordance with the OIDF copyright, allowing =
derivative works.

The OIDF is well aware of this specification and is pleased to =
contribute parts of the connect specification that have broader =
applicability in the OAuth community for inclusion in IETF =
specifications.

John B.

> On Feb 24, 2015, at 8:02 PM, Kathleen Moriarty =
 wrote:
>=20
> I was able to get a response, I'm guessing the question got too buried =
in the thread over the past few days.
>=20
> Essentially, it is the contributors responsibility to ensure it's ok =
to include text.  If this was Mike or someone else that believe it is =
fine, then we can proceed.
>=20
> Hannes may need to update the shepherd report and I'll read through =
the updated version tomorrow.  I'll try to get a review out if the =
accompanying management draft tomorrow too.
>=20
> Thanks,
> Kathleen=20
>=20
> Sent from my iPhone
>=20
> On Feb 24, 2015, at 6:47 PM, Mike Jones > wrote:
>=20
>> Thanks, Kathleen.  This had been discussed on the OAuth list before, =
but just in case you or the IETF legal counsel weren=E2=80=99t aware of =
it =E2=80=93 the reason that it=E2=80=99s OK to produce derivative works =
from OpenID specs, as draft-ietf-oauth-dyn-reg did, is that it=E2=80=99s =
explicitly allowed by the OpenID Foundation.  See this text =
athttp://openid.net/specs/openid-connect-registration-1_0.html#Notices =
 =
=E2=80=93 the spec from which text was copied:
>> =20
>> The OpenID Foundation (OIDF) grants to any Contributor, developer, =
implementer, or other interested party a non-exclusive, royalty free, =
worldwide copyright license to reproduce, prepare derivative works from, =
distribute, perform and display, this Implementers Draft or Final =
Specification solely for the purposes of (i) developing specifications, =
and (ii) implementing Implementers Drafts and Final Specifications based =
on such documents, provided that attribution be made to the OIDF as the =
source of the material, but that such attribution does not indicate an =
endorsement by the OIDF.
>> =20
>> You could pass that on to the appropriate IETF legal counsel if =
they=E2=80=99re not already aware of it.
>> =20
>>                                                                 -- =
Mike
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Kathleen Moriarty
>> Sent: Tuesday, February 24, 2015 3:08 PM
>> To: Hannes Tschofenig
>> Cc: oauth@ietf.org 
>> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>> =20
>> Hello,
>> =20
>> Thanks for updating the draft.  I just want to confirm that Hannes is =
okay with the updated definitions and updates the shepherd report to =
reflect that.
>> =20
>> This is getting held up a bit while we sort through copyright of text =
from UMA and OpenID.  The text from UMA went into an IETF draft, so that =
should be the reference as it clears up any possible issues as they =
provided that text in an IETF draft. =20
>> =20
>> The chairs will be helping to sort out the requirements with OpenID, =
per our discussions the IETF trustees.  I'm not sure how long this will =
take, but wanted to provide a status so no one thought this had been =
dropped.
>> =20
>> Thanks.
>> =20
>> On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig =
> wrote:
>> Hi Justin, Hi John,
>>=20
>> I believe that provisioning a client with a unique id (which is what =
a
>> client id/client secret is) allows some form of linkability. While it
>> may be possible to associate the client to a specific user I could =
very
>> well imagine that the correlation between activities from a user and
>> those from the client (particularly when the client is running on the
>> user's device) is quite possible.
>>=20
>> Ciao
>> Hannes
>>=20
>> On 02/18/2015 06:37 PM, Justin Richer wrote:
>> > I=E2=80=99ll incorporate this feedback into another draft, to be =
posted by the
>> > end of the week. Thanks everyone!
>> >
>> >  =E2=80=94 Justin
>> >
>> >> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>> >> 
>> >> >> wrote:
>> >>
>> >>
>> >>
>> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley 
>> >> >> wrote:
>> >>
>> >>     snip
>> >>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>> >>>     
>> >>>     >> wrote:
>> >>>
>> >>>         > The client_id *could* be short lived, but they usually =
aren't. I don't see any particular logging or tracking concerns using a =
dynamic OAuth client above using any other piece of software, ever. As =
such, I don't think it requires special calling out here.
>> >>>
>> >>>
>> >>>     Help me understand why there should not be text that shows =
this
>> >>>     is not an issue or please propose some text.  This is bound =
to
>> >>>     come up in IESG reviews if not addressed up front.
>> >>>
>> >>>
>> >>
>> >>     The client_id is used to communicate to the Authorization =
server
>> >>     to get a code or refresh token.  Those tokens uniquely =
identify
>> >>     the user from a privacy perspective.
>> >>     It is the access tokens that are sent to the RS and those can =
and
>> >>     should be rotated, but the client)id is not sent to the RS in
>> >>     OAuth as part of the spec.
>> >>
>> >>     If you did rotate the client_id then the AS would track it =
across
>> >>     rotations, so it wouldn=E2=80=99t really achieve anything.
>> >>
>> >>     One thing we don=E2=80=99t do is allow the client to specify =
the
>> >>     client_id, that could allow correlation of the client across
>> >>     multiple AS and that might be a privacy issue, but we don=E2=80=99=
t allow it.
>> >>
>> >>
>> >> Thanks, John.  It may be helpful to add in this explanation unless
>> >> there is some reason not to?
>> >>
>> >>
>> >>     John B.
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Best regards,
>> >> Kathleen
>> >> _______________________________________________
>> >> OAuth mailing list
>> >> OAuth@ietf.org  >
>> >> https://www.ietf.org/mailman/listinfo/oauth =

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

>> >
>>=20
>>=20
>>=20
>> =20
>> --=20
>> =20
>> Best regards,
>> Kathleen
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_03BAF2AC-421A-4A9D-82DD-15FBF635CAEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes as one of the Authors and a officer of the OpenID =
Foundation the text was contributed in accordance with the OIDF =
copyright, allowing derivative works.

The OIDF is well aware of this =
specification and is pleased to contribute parts of the connect =
specification that have broader applicability in the OAuth community for =
inclusion in IETF specifications.

John B.

On =
Feb 24, 2015, at 8:02 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

I was able to get a =
response, I'm guessing the question got too buried in the thread over =
the past few days.

Essentially, it is the contributors responsibility to =
ensure it's ok to include text.  If this was Mike or someone else =
that believe it is fine, then we can proceed.

Hannes may need to =
update the shepherd report and I'll read through the updated version =
tomorrow.  I'll try to get a review out if the accompanying =
management draft tomorrow too.

Thanks,
Kathleen 

Sent from my iPhone

On Feb =
24, 2015, at 6:47 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks, Kathleen.  =
This had been discussed on the OAuth list before, but just in case you =
or the IETF legal counsel weren=E2=80=99t aware of it =E2=80=93 the =
reason that it=E2=80=99s OK to produce derivative works from OpenID =
specs, as draft-ietf-oauth-dyn-reg did, is that it=E2=80=99s explicitly =
allowed by the OpenID Foundation.  See this text athttp://openid.net/specs/openid-connect-registration-1_0.html#No=
tices =E2=80=93 =
the spec from which text was copied:
 
The OpenID Foundation =
(OIDF) grants to any Contributor, developer, implementer, or other =
interested party a non-exclusive, royalty free, worldwide copyright =
license to reproduce, prepare derivative works from, distribute, perform =
and display, this Implementers Draft or Final Specification solely for =
the purposes of (i) developing specifications, and (ii) implementing =
Implementers Drafts and Final Specifications based on such documents, =
provided that attribution be made to the OIDF as the source of the =
material, but that such attribution does not indicate an endorsement by =
the OIDF.
 
You could pass that on =
to the appropriate IETF legal counsel if they=E2=80=99re not already =
aware of it.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            =
;    -- Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of Kathleen =
Moriarty
Sent: Tuesday, February 24, 2015 =
3:08 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] AD review of =
Draft-ietf-dyn-reg
 
Hello,
 
Thanks for updating the draft.  I just want to =
confirm that Hannes is okay with the updated definitions and updates the =
shepherd report to reflect that.
 
This is getting held up a bit while we sort through =
copyright of text from UMA and OpenID.  The text from UMA went into =
an IETF draft, so that should be the reference as it clears up any =
possible issues as they provided that text in an IETF draft.  
 
The chairs will be helping to sort out =
the requirements with OpenID, per our discussions the IETF =
trustees.  I'm not sure how long this will take, but wanted to =
provide a status so no one thought this had been dropped.
 
Thanks.
 
On Wed, Feb 18, 2015 at 12:57 PM, Hannes =
Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi =
Justin, Hi John,

I believe that =
provisioning a client with a unique id (which is what a
client id/client secret is) allows some form of linkability. =
While it
may be possible to associate the client to a =
specific user I could very
well imagine that the =
correlation between activities from a user and
those from =
the client (particularly when the client is running on the
user's device) is quite possible.

Ciao
Hannes

On =
02/18/2015 06:37 PM, Justin Richer wrote:
> I=E2=80=99ll =
incorporate this feedback into another draft, to be posted by the
> end of the week. Thanks everyone!
>
>  =E2=80=94 Justin
>
>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>> <kathleen.moriarty.ietf@gmail.com
>> =
<mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
>>
>>
>>
>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley =
<ve7jtb@ve7jtb.com
>> <mailto:ve7jtb@ve7jtb.com>> wrote:
>>
>>     snip
>>>     On Feb 18, 2015, at 6:46 AM, =
Kathleen Moriarty
>>>     <kathleen.moriarty.ietf@gmail.com
>>>     <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
>>>
>>>      =
   > The client_id *could* be short lived, but they usually =
aren't. I don't see any particular logging or tracking concerns using a =
dynamic OAuth client above using any other piece of software, ever. As =
such, I don't think it requires special calling out here.
>>>
>>>
>>>     Help me understand why there =
should not be text that shows this
>>>  =
   is not an issue or please propose some text.  This is =
bound to
>>>     come up in IESG =
reviews if not addressed up front.
>>>
>>>
>>
>>     The client_id is used to =
communicate to the Authorization server
>>  =
   to get a code or refresh token.  Those tokens uniquely =
identify
>>     the user from a =
privacy perspective.
>>     It is the =
access tokens that are sent to the RS and those can and
>>     should be rotated, but the =
client)id is not sent to the RS in
>>    =
 OAuth as part of the spec.
>>
>>     If you did rotate the client_id =
then the AS would track it across
>>    =
 rotations, so it wouldn=E2=80=99t really achieve anything.
>>
>>     One thing =
we don=E2=80=99t do is allow the client to specify the
>>     client_id, that could allow =
correlation of the client across
>>    =
 multiple AS and that might be a privacy issue, but we don=E2=80=99t =
allow it.
>>
>>
>> Thanks, John.  It may be helpful to add in this =
explanation unless
>> there is some reason not =
to?
>>
>>
>>     John B.
>>
>>
>>
>>
>> --
>>
>> =
Best regards,
>> Kathleen
>> =
_______________________________________________
>> =
OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> =
_______________________________________________
> OAuth =
mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


 
-- 
 
Best regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_03BAF2AC-421A-4A9D-82DD-15FBF635CAEA--

--Apple-Mail=_4E15337C-1843-4560-ACE8-5340F49A130A
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAyMjUwMjAzMjhaMCMGCSqGSIb3DQEJBDEWBBSvDwStRNdMI+H153yeAR4l
c6oxbTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAU/nxhp/h6MWAmmPLyolDL/QlXjNwBBhnxEueVGwLXUCAH3S9JmGV7
Ac6nBRy5hWzkmvZAUPqmP/mYgFCPGgXA7jL+/gXr7OyHSvk7Roe9qMrnlCsE+NswYdgAWwyxuUiE
ul/lk932OjNj0ar4iiaEod5bAypgoBkNFGQEA49h8fNhhqK4mnKWG4JIartZGcQz7TzAKbVMnEsH
ziFkLrNKm4vGwrYUsCVuPwcOlc4QdU8xFl65zSdwTvO1o2d/usLoX8aLl6BS7q6DOuZUtTu5Osxt
Mvbi0k3J96kSVVmLoVuBW02HHbIpXnBKzNMZqvYoSav4uyHCKjBz1wiaj8IJAAAAAAAA
--Apple-Mail=_4E15337C-1843-4560-ACE8-5340F49A130A--


From nobody Tue Feb 24 19:20:58 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86F11A1A86 for ; Tue, 24 Feb 2015 19:20:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level: 
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpaBovaDJIfG for ; Tue, 24 Feb 2015 19:20:54 -0800 (PST)
Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AFD1A009B for ; Tue, 24 Feb 2015 19:20:53 -0800 (PST)
Received: by qcvx3 with SMTP id x3so996833qcv.5 for ; Tue, 24 Feb 2015 19:20:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zhtY97csf/BJr9nSMsFbEtf6E7SuIC3qd+xhB+AAIMQ=; b=DhCd5ZODRgitRFxp0RNC6pR6oZgXZE+FDHVqPQcgjT04FB1M/TNUvCC1pZ9dYLtogI pmOTgcrR4oYktYboKV8idoXz7vMPoqZ0O6KcGSvT1nzZ3bGF/zj/5fqapQ0qfgCy5gcc jEDC3FXotU6e1F+5fDUtLsUBd/PVv/UJsbkg2WO4g4lCJD/a1rfN5PZW4oqBxOhvNJ5Y L8snLCIRCtonNh4KMNXwSGjYEd14BYQYdX576tcloewUk12SO0U6917sNvOTLeW0aZ0h 33WvEuCDN7SLc/rF/6yCPfUvuCZPJHoujcnJIPEr633owIm10Krsrv5gwHJbpxZwvyT+ BIUw==
X-Received: by 10.229.70.201 with SMTP id e9mr2787028qcj.6.1424834452922; Tue, 24 Feb 2015 19:20:52 -0800 (PST)
Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id w8sm1992673qge.25.2015.02.24.19.20.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 19:20:51 -0800 (PST)
From: Kathleen Moriarty 
X-Google-Original-From: Kathleen Moriarty 
Content-Type: multipart/alternative; boundary=Apple-Mail-57459CB3-7D19-4771-8BB2-2D09C12A1ADC
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (11D257)
In-Reply-To: <8C0D57C9-3E4C-4384-A10B-8A0D57F2F75B@ve7jtb.com>
Date: Tue, 24 Feb 2015 22:20:51 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <39E3C9AE-0A87-44F6-AA4B-0B30B785333F@gmail.com>
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>   <54E4D2A5.5030705@gmx.net>  <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com> <3AAFF7CB-1C84-4BD5-B8BF-9162660BD57D@gmail.com> <8C0D57C9-3E4C-4384-A10B-8A0D57F2F75B@ve7jtb.com>
To: John Bradley 
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Feb 2015 03:20:57 -0000

--Apple-Mail-57459CB3-7D19-4771-8BB2-2D09C12A1ADC
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thanks, John!

Sent from my iPhone

> On Feb 24, 2015, at 9:03 PM, John Bradley  wrote:
>=20
> Yes as one of the Authors and a officer of the OpenID Foundation the text w=
as contributed in accordance with the OIDF copyright, allowing derivative wo=
rks.
>=20
> The OIDF is well aware of this specification and is pleased to contribute p=
arts of the connect specification that have broader applicability in the OAu=
th community for inclusion in IETF specifications.
>=20
> John B.
>=20
>> On Feb 24, 2015, at 8:02 PM, Kathleen Moriarty  wrote:
>>=20
>> I was able to get a response, I'm guessing the question got too buried in=
 the thread over the past few days.
>>=20
>> Essentially, it is the contributors responsibility to ensure it's ok to i=
nclude text.  If this was Mike or someone else that believe it is fine, then=
 we can proceed.
>>=20
>> Hannes may need to update the shepherd report and I'll read through the u=
pdated version tomorrow.  I'll try to get a review out if the accompanying m=
anagement draft tomorrow too.
>>=20
>> Thanks,
>> Kathleen=20
>>=20
>> Sent from my iPhone
>>=20
>>> On Feb 24, 2015, at 6:47 PM, Mike Jones  wr=
ote:
>>>=20
>>> Thanks, Kathleen.  This had been discussed on the OAuth list before, but=
 just in case you or the IETF legal counsel weren=E2=80=99t aware of it =E2=80=
=93 the reason that it=E2=80=99s OK to produce derivative works from OpenID s=
pecs, as draft-ietf-oauth-dyn-reg did, is that it=E2=80=99s explicitly allow=
ed by the OpenID Foundation.  See this text athttp://openid.net/specs/openid=
-connect-registration-1_0.html#Notices =E2=80=93 the spec from which text wa=
s copied:
>>> =20
>>> The OpenID Foundation (OIDF) grants to any Contributor, developer, imple=
menter, or other interested party a non-exclusive, royalty free, worldwide c=
opyright license to reproduce, prepare derivative works from, distribute, pe=
rform and display, this Implementers Draft or Final Specification solely for=
 the purposes of (i) developing specifications, and (ii) implementing Implem=
enters Drafts and Final Specifications based on such documents, provided tha=
t attribution be made to the OIDF as the source of the material, but that su=
ch attribution does not indicate an endorsement by the OIDF.
>>> =20
>>> You could pass that on to the appropriate IETF legal counsel if they=E2=80=
=99re not already aware of it.
>>> =20
>>>                                                                 -- Mike
>>> =20
>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen Moriar=
ty
>>> Sent: Tuesday, February 24, 2015 3:08 PM
>>> To: Hannes Tschofenig
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>>> =20
>>> Hello,
>>> =20
>>> Thanks for updating the draft.  I just want to confirm that Hannes is ok=
ay with the updated definitions and updates the shepherd report to reflect t=
hat.
>>> =20
>>> This is getting held up a bit while we sort through copyright of text fr=
om UMA and OpenID.  The text from UMA went into an IETF draft, so that shoul=
d be the reference as it clears up any possible issues as they provided that=
 text in an IETF draft. =20
>>> =20
>>> The chairs will be helping to sort out the requirements with OpenID, per=
 our discussions the IETF trustees.  I'm not sure how long this will take, b=
ut wanted to provide a status so no one thought this had been dropped.
>>> =20
>>> Thanks.
>>> =20
>>> On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig  wrote:
>>> Hi Justin, Hi John,
>>>=20
>>> I believe that provisioning a client with a unique id (which is what a
>>> client id/client secret is) allows some form of linkability. While it
>>> may be possible to associate the client to a specific user I could very
>>> well imagine that the correlation between activities from a user and
>>> those from the client (particularly when the client is running on the
>>> user's device) is quite possible.
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>> On 02/18/2015 06:37 PM, Justin Richer wrote:
>>> > I=E2=80=99ll incorporate this feedback into another draft, to be poste=
d by the
>>> > end of the week. Thanks everyone!
>>> >
>>> >  =E2=80=94 Justin
>>> >
>>> >> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>>> >> >> >> > wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley >> >> > wrote:
>>> >>
>>> >>     snip
>>> >>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>> >>>     >> >>>     > wrote:
>>> >>>
>>> >>>         > The client_id *could* be short lived, but they usually are=
n't. I don't see any particular logging or tracking concerns using a dynamic=
 OAuth client above using any other piece of software, ever. As such, I don'=
t think it requires special calling out here.
>>> >>>
>>> >>>
>>> >>>     Help me understand why there should not be text that shows this
>>> >>>     is not an issue or please propose some text.  This is bound to
>>> >>>     come up in IESG reviews if not addressed up front.
>>> >>>
>>> >>>
>>> >>
>>> >>     The client_id is used to communicate to the Authorization server
>>> >>     to get a code or refresh token.  Those tokens uniquely identify
>>> >>     the user from a privacy perspective.
>>> >>     It is the access tokens that are sent to the RS and those can and=

>>> >>     should be rotated, but the client)id is not sent to the RS in
>>> >>     OAuth as part of the spec.
>>> >>
>>> >>     If you did rotate the client_id then the AS would track it across=

>>> >>     rotations, so it wouldn=E2=80=99t really achieve anything.
>>> >>
>>> >>     One thing we don=E2=80=99t do is allow the client to specify the
>>> >>     client_id, that could allow correlation of the client across
>>> >>     multiple AS and that might be a privacy issue, but we don=E2=80=99=
t allow it.
>>> >>
>>> >>
>>> >> Thanks, John.  It may be helpful to add in this explanation unless
>>> >> there is some reason not to?
>>> >>
>>> >>
>>> >>     John B.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> Best regards,
>>> >> Kathleen
>>> >> _______________________________________________
>>> >> OAuth mailing list
>>> >> OAuth@ietf.org 
>>> >> https://www.ietf.org/mailman/listinfo/oauth
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > OAuth@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>> >
>>>=20
>>>=20
>>>=20
>>> =20
>>> --=20
>>> =20
>>> Best regards,
>>> Kathleen
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20

--Apple-Mail-57459CB3-7D19-4771-8BB2-2D09C12A1ADC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Thanks, John!

Sent from my iPho=
ne

On Feb 24, 2015, at 9:03 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes as one of the Authors and a officer of the OpenID Fo=
undation the text was contributed in accordance with the OIDF copyright, all=
owing derivative works.

=
The OIDF is well aware of this specification and is pleased to contribute pa=
rts of the connect specification that have broader applicability in the OAut=
h community for inclusion in IETF specifications.

John B.

=

On Feb 24, 2015, a=
t 8:02 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
I was able to get a response, I'm guessing the question got too buri=
ed in the thread over the past few days.
=

Essentially, it is the co=
ntributors responsibility to ensure it's ok to include text.  If this w=
as Mike or someone else that believe it is fine, then we can proceed.
<=
div style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform=
: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-s=
troke-width: 0px;" class=3D"">
Hannes may need to update the shepherd report and I'll read through th=
e updated version tomorrow.  I'll try to get a review out if the accomp=
anying management draft tomorrow too.
Thanks,
Kathleen 

Sent from my iPh=
one

On Feb 24, 2015, at 6:=
47 PM, Mike Jones <Michael.Jones@micros=
oft.com> wrote:

Thanks, Kathleen.  This had been discussed on the OAuth li=
st before, but just in case you or the IETF legal counsel weren=E2=80=99t aw=
are of it =E2=80=93 the reason that it=E2=80=99s OK to produce derivative wo=
rks from OpenID specs, as draft-ietf-oauth-dyn-reg did, is that it=E2=80=99s=
 explicitly allowed by the OpenID Foundation.  See this text athttp://openid.net=
/specs/openid-connect-registration-1_0.html#Notices =E2=80=93 the spec from which text was copied:=

 
The OpenID Foundation (OIDF) grants to any Contributor, develope=
r, implementer, or other interested party a non-exclusive, royalty free, wor=
ldwide copyright license to reproduce, prepare derivative works from, distri=
bute, perform and display, this Implementers Draft or Final Specification so=
lely for the purposes of (i) developing specifications, and (ii) implementin=
g Implementers Drafts and Final Specifications based on such documents, prov=
ided that attribution be made to the OIDF as the source of the material, but=
 that such attribution does not indicate an endorsement by the OIDF.<=
span style=3D"font-size: 10pt; font-family: Calibri, sans-serif; color: rgb(=
31, 73, 125);" class=3D"">
 
You could pass that on to the a=
ppropriate IETF legal counsel if they=E2=80=99re not already aware of it.
 
          &nb=
sp;            &=
nbsp;            =
;            &nb=
sp;            &=
nbsp;  -- Mike
 
From: OAuth [mailto:oauth-bounces@i=
etf.org] On Behalf Of Kathleen=
 Moriarty
Sent: Tuesday, February 24, 2015 3:08 PM
To: Hannes Ts=
chofenig
Cc: oauth@ietf.org
Subject: R=
e: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
 
Hello,
=

 =

Thanks for updat=
ing the draft.  I just want to confirm that Hannes is okay with the upd=
ated definitions and updates the shepherd report to reflect that.
 
This is getting held up a bit while we sort through copyright of text fro=
m UMA and OpenID.  The text from UMA went into an IETF draft, so that s=
hould be the reference as it clears up any possible issues as they provided t=
hat text in an IETF draft.  
 
The chairs will be helping=
 to sort out the requirements with OpenID, per our discussions the IETF trus=
tees.  I'm not sure how long this will take, but wanted to provide a st=
atus so no one thought this had been dropped.
 
Thanks.
 
On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wro=
te:
Hi Justin, Hi=
 John,

I believe that provisioning a client wit=
h a unique id (which is what a
client id/client secret is) all=
ows some form of linkability. While it
may be possible to asso=
ciate the client to a specific user I could very
well imagine t=
hat the correlation between activities from a user and
those f=
rom the client (particularly when the client is running on the
user's device) is quite possible.

Ciao
Hannes

On 02/18/2015 06:37 PM, Justin Ri=
cher wrote:
> I=E2=80=99ll incorporate this feedback into a=
nother draft, to be posted by the
> end of the week. Thanks=
 everyone!
>
>  =E2=80=94 Justin
>
>> On Feb 18, 2015, at 10:30 AM, Kathleen=
 Moriarty
>> <kathleen.moriarty.ietf@gmail.com
>> <mailto:kathleen.moriarty.ietf@gmail.com>=
> wrote:
>>
>>
>=
>
>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley &=
lt;ve7jtb@ve7jtb.com
>> <=
;mailto:ve7jtb@ve7jtb.com>> wrote:
>>
>>     snip
>>>     On Feb 18, 2015, at 6:46 AM, Kathleen Mori=
arty
>>>     <kathleen.moriarty.ietf@gmail.com
>&g=
t;>     <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
>>&=
gt;
>>>         > The cli=
ent_id *could* be short lived, but they usually aren't. I don't see any part=
icular logging or tracking concerns using a dynamic OAuth client above using=
 any other piece of software, ever. As such, I don't think it requires speci=
al calling out here.
>>>
>>>>>>     Help me understand why there sh=
ould not be text that shows this
>>>    &nb=
sp;is not an issue or please propose some text.  This is bound to
>>>     come up in IESG reviews if not addr=
essed up front.
>>>
>>>
>>
>>     The client_id is u=
sed to communicate to the Authorization server
>>  &=
nbsp;  to get a code or refresh token.  Those tokens uniquely iden=
tify
>>     the user from a privacy persp=
ective.
>>     It is the access tokens th=
at are sent to the RS and those can and
>>    &=
nbsp;should be rotated, but the client)id is not sent to the RS in
>>     OAuth as part of the spec.
>=
>
>>     If you did rotate the client_=
id then the AS would track it across
>>    &nb=
sp;rotations, so it wouldn=E2=80=99t really achieve anything.
=
>>
>>     One thing we don=E2=80=99=
t do is allow the client to specify the
>>    &=
nbsp;client_id, that could allow correlation of the client across
>>     multiple AS and that might be a privacy issue=
, but we don=E2=80=99t allow it.
>>
>&g=
t;
>> Thanks, John.  It may be helpful to add in th=
is explanation unless
>> there is some reason not to?>>
>>
>>  &nb=
sp;  John B.
>>
>>
>>
>>
>> --
&g=
t;>
>> Best regards,
>> Kathleen<=
br class=3D"">>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth<=
/o:p>
>
>
> ____________=
___________________________________
> OAuth mailing list> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=

=


 
-- 
 
Best regards,
Kathleen
____________=
___________________________________
OAuth ma=
iling list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth

=

--Apple-Mail-57459CB3-7D19-4771-8BB2-2D09C12A1ADC--


From nobody Wed Feb 25 08:25:23 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD2F1A90FC for ; Wed, 25 Feb 2015 08:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Level: 
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjdnGWg75HO4 for ; Wed, 25 Feb 2015 08:25:20 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A461A8828 for ; Wed, 25 Feb 2015 08:23:50 -0800 (PST)
X-AuditID: 1209190e-f79bb6d0000030e8-a6-54edf71445a7
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 76.C2.12520.517FDE45; Wed, 25 Feb 2015 11:23:49 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t1PGNmov026651; Wed, 25 Feb 2015 11:23:48 -0500
Received: from [192.168.0.109] (c-66-30-197-6.hsd1.ma.comcast.net [66.30.197.6]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1PGNkWf008384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Feb 2015 11:23:47 -0500
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Justin Richer 
In-Reply-To: 
Date: Wed, 25 Feb 2015 11:23:45 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <54DC2CB1.8090400@mit.edu>  <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com>  <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com>   <54E4D2A5.5030705@gmx.net> 
To: John Bradley 
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixCmqrSv6/W2IweceToulO++xWjTszLc4 +fYVm8Xqu3/ZHFg8ds66y+6xeNN+No8lS34yedy+vZElgCWKyyYlNSezLLVI3y6BK+Pigi/M BQ0GFW+fv2NvYNym1sXIySEhYCJxr289G4QtJnHhHojNxSEksJhJYv2LTawQzkZGiYNnH7JA OGeZJLb3/WcEaWEW0JPYcf0XK4jNK2AgMffUFyYQW1jAXOL/gztgNpuAqsT0NS1gNqeAncSE w/PB6lmA4q3nTzOBDGUWmMco8fTvJXaIodoSyxa+ZoYYaiUxf3cX1BmrWCTO/tsJdqyIgIrE vn2PgK7gADpcXqJnU/oERsFZSG6aheSmWUjGLmBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRr rJebWaKXmlK6iREc6pJ8Oxi/HlQ6xCjAwajEw3tA5k2IEGtiWXFl7iFGSQ4mJVHepPdvQ4T4 kvJTKjMSizPii0pzUosPMUpwMCuJ8La9AsrxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1O TS1ILYLJynBwKEnwCnwDahQsSk1PrUjLzClBSDNxcIIM5wEafuMryPDigsTc4sx0iPwpRl2O LQf2z2QSYsnLz0uVEue9CVIkAFKUUZoHNweWol4xigO9JcyrBLKOB5je4Ca9AlrCBLRkz+NX IEtKEhFSUg2MHEXHw3skn72X90ueFtca2Jt79aH6RFZR5p/PnF7tPt86g1/ud1TprDJZk6ba 67L6zvtyfi+pWDalIyWhPbpswiUx61t71D8GzeTeIMc23z9l+18Fr53rTx+d7mJ7+Tzn3z85 Iu+eC75c+DDGs/HdV4e0gnoZjkkp72MX1O/rqPpdq2LEtjBYiaU4I9FQi7moOBEAv6PT0iwD AAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Feb 2015 16:25:22 -0000

John=92s assessment is correct and this is what we=92ve tried to capture =
in the privacy considerations section of the latest draft:

   In general, the metadata for a client, such as the client name and
   software identifier, are common across all instances of a piece of
   client software and therefore pose no privacy issues for end-users.
   Client identifiers, on the other hand, are often unique to a specific
   instance of a client.  For clients such as web sites that are used by
   many users, there may not be significant privacy concerns regarding
   the client identifier, but for clients such as native applications
   that are installed on a single end-user's device, the client
   identifier could be uniquely tracked during OAuth 2.0 transactions
   and its use tied to that single end-user.  However, as the client
   software still needs to be authorized by a resource owner through an
   OAuth 2.0 authorization grant, this type of tracking can occur
   whether or not the client identifier is unique by correlating the
   authenticated resource owner with the requesting client identifier.

   Note that clients are forbidden by this specification from creating
   their own client identifier.  If the client were able to do so, an
   individual client instance could be tracked across multiple colluding
   authorization servers, leading to privacy and security issues.
   Additionally, client identifiers are generally issued uniquely per
   registration request, even for the same instance of software.  In
   this way, an application could marginally improve privacy by
   registering multiple times and appearing to be completely separate
   applications.  However, this technique does incur significant
   usability cost in the form of requiring multiple authorizations per
   resource owner and is therefore unlikely to be used in practice.


Hopefully this is more clear now.

Thanks for the feedback and close review,
 =97 Justin

> On Feb 24, 2015, at 8:55 PM, John Bradley  wrote:
>=20
> Yes but it is authenticating the client to the AS as part of the =
resource owners consent.  =20
>=20
> Ther eis a one to one mapping of resource owner to client in that =
case.=20
>=20
> The client ID is no more identifying than the refresh token that maps =
to the RO by design.
>=20
> Yes the grant identifies the RO in some way.  The client_id and secret =
prevent that from being used in a different client if the bearer token =
leaks.
>=20
> Remember the client_id is going to be different at different AS as =
each will have a separate registration.
> If the client_id was fixed across multiple AS then it would be a =
correlation issue, but that is not the case.
>=20
> Perhaps I am not understanding the concern?
>=20
> John B.
>=20
>> On Feb 18, 2015, at 12:57 PM, Hannes Tschofenig =
 wrote:
>>=20
>> Hi Justin, Hi John,
>>=20
>> I believe that provisioning a client with a unique id (which is what =
a
>> client id/client secret is) allows some form of linkability. While it
>> may be possible to associate the client to a specific user I could =
very
>> well imagine that the correlation between activities from a user and
>> those from the client (particularly when the client is running on the
>> user's device) is quite possible.
>>=20
>> Ciao
>> Hannes
>>=20
>> On 02/18/2015 06:37 PM, Justin Richer wrote:
>>> I=92ll incorporate this feedback into another draft, to be posted by =
the
>>> end of the week. Thanks everyone!
>>>=20
>>> =97 Justin
>>>=20
>>>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>>>> >>> > wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley >>> > wrote:
>>>>=20
>>>>   snip
>>>>>   On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>>>>   >>>>   > wrote:
>>>>>=20
>>>>>> The client_id *could* be short lived, but they usually aren't. I =
don't see any particular logging or tracking concerns using a dynamic =
OAuth client above using any other piece of software, ever. As such, I =
don't think it requires special calling out here.
>>>>>=20
>>>>>=20
>>>>>   Help me understand why there should not be text that shows this
>>>>>   is not an issue or please propose some text.  This is bound to
>>>>>   come up in IESG reviews if not addressed up front.=20
>>>>>=20
>>>>>=20
>>>>=20
>>>>   The client_id is used to communicate to the Authorization server
>>>>   to get a code or refresh token.  Those tokens uniquely identify
>>>>   the user from a privacy perspective.=20
>>>>   It is the access tokens that are sent to the RS and those can and
>>>>   should be rotated, but the client)id is not sent to the RS in
>>>>   OAuth as part of the spec.=20
>>>>=20
>>>>   If you did rotate the client_id then the AS would track it across
>>>>   rotations, so it wouldn=92t really achieve anything.
>>>>=20
>>>>   One thing we don=92t do is allow the client to specify the
>>>>   client_id, that could allow correlation of the client across
>>>>   multiple AS and that might be a privacy issue, but we don=92t =
allow it.
>>>>=20
>>>>=20
>>>> Thanks, John.  It may be helpful to add in this explanation unless
>>>> there is some reason not to?=20
>>>>=20
>>>>=20
>>>>   John B.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> --=20
>>>>=20
>>>> Best regards,
>>>> Kathleen
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


From nobody Thu Feb 26 08:04:28 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430BB1A8752 for ; Thu, 26 Feb 2015 08:04:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B__KWx6h-mXa for ; Thu, 26 Feb 2015 08:04:25 -0800 (PST)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83AA91A871A for ; Thu, 26 Feb 2015 08:04:25 -0800 (PST)
Received: by mail-oi0-f49.google.com with SMTP id v63so10062445oia.8 for ; Thu, 26 Feb 2015 08:04:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=jo5gtvUavRxCZM5IBTQAFEIA/MyAEDfUGUIPyJ0Y1ro=; b=Fo1rjPI6a7F7Z/+sDXjZ8vEX139GpaWclpU8pQ1mEne7Hw2dDJQrC9BTh1iq1evmtU o5JSQtGV63MCs1fjM1xFZU24PvKqArKUE55lxxqf94dhc+yNFaHJA7TG4Fb8LhpPJ5zz m5MToL0Sv5g4stX+Um8M93EJFkBj1Fh52f3ObOhFWhoXDjyzYl8kYd9Ei0xv+U9c+3WO TSbvJZQP+Jd9GXDDs08GNTxIIKvLSOw0Koc3pU3HqEB0jfStPUvlcg0myIclNFE2zjpP 5gTy3m+BirLLJHnV/3JogG6BbeYkHew/zHTnnzlnG2z6MzsBJfJeWdvmCOVsxaNfrDG2 uuxw==
MIME-Version: 1.0
X-Received: by 10.107.46.230 with SMTP id u99mr12292840iou.21.1424966664633; Thu, 26 Feb 2015 08:04:24 -0800 (PST)
Received: by 10.107.12.34 with HTTP; Thu, 26 Feb 2015 08:04:24 -0800 (PST)
Date: Thu, 26 Feb 2015 11:04:24 -0500
Message-ID: 
From: Kathleen Moriarty 
To: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c16a96dccba6050fffe71d
Archived-At: 
Subject: [OAUTH-WG] AD review of draft-ietf-oauth-dyn-reg-management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Feb 2015 16:04:27 -0000

--001a11c16a96dccba6050fffe71d
Content-Type: text/plain; charset=UTF-8

Hello,

I reviewed draft-ietf-oauth-dyn-reg-management, which reads well and I just
have a few questions and suggestions below that would be good to address
prior to IETF last call.

Section 1.3
Bullet D might be easier to read as a list within the bullet.

Section 2
This is something I don't recall offhand and may be in place in another
draft, so a pointer would be great.  Is there an MTI set for one of the
recommended cipher suites in the TLS & DTLS BCP to ensure interoperability
(but also allow for algorithm agility)?  If not and there is a reason,
please explain.
See section 4: https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
This is not the right draft to add this content, but I'd like to know if it
is covered somewhere or doesn't need to be for some reason.  TLS
requirements should point to that draft (assuming one exists) so there is
only one place to update if needed for any specific requirements to OAuth.

IANA Considerations:
The shepherd report says that there are no actions for IANA, so this needs
to be updated as the draft is the specification required to add two new
entries to an existing registry, established by the parent document.  It
does require DE review on the mailing list: oauth-ext-review@ietf.org
If that has been done, then a pointer to the archive would be helpful.

Thank you.

-- 

Best regards,
Kathleen

--001a11c16a96dccba6050fffe71d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello,

I reviewed=C2=A0draft=
-ietf-oauth-dyn-reg-management, which reads well and I just have a few ques=
tions and suggestions below that would be good to address prior to IETF las=
t call.

Section 1.3
Bullet D might be easier to rea=
d as a list within the bullet.

Section 2
This is something I don't recall offhand and may be in place in anothe=
r draft, so a pointer would be great.=C2=A0 Is there an MTI set for one of =
the recommended cipher suites in the TLS & DTLS BCP to ensure interoper=
ability (but also allow for algorithm agility)?=C2=A0 If not and there is a=
 reason, please explain.
This is not the right draft to=
 add this content, but I'd like to know if it is covered somewhere or d=
oesn't need to be for some reason.=C2=A0 TLS requirements should point =
to that draft (assuming one exists) so there is only one place to update if=
 needed for any specific requirements to OAuth.

IA=
NA Considerations:
The shepherd report says that there are no act=
ions for IANA, so this needs to be updated as the draft is the specificatio=
n required to add two new entries to an existing registry, established by t=
he parent document.=C2=A0 It does require DE review on the mailing list:=C2=
=A0oauth-ext-review@ietf.=
org
If that has been done, then a pointer to the archive wou=
ld be helpful.

Thank you.

-- 

Best regards,
Kathleen




--001a11c16a96dccba6050fffe71d--


From nobody Thu Feb 26 08:40:40 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF041A1BB9 for ; Thu, 26 Feb 2015 08:40:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IM0-GDp28zP9 for ; Thu, 26 Feb 2015 08:40:36 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928BB1A0218 for ; Thu, 26 Feb 2015 08:40:36 -0800 (PST)
X-AuditID: 1209190e-f79bb6d0000030e8-fa-54ef4c823807
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id A3.B0.12520.38C4FE45; Thu, 26 Feb 2015 11:40:35 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t1QGeYPn024769; Thu, 26 Feb 2015 11:40:34 -0500
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1QGeVQH018445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Feb 2015 11:40:33 -0500
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_736388E3-3177-4937-B63F-47F24D740F65"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b5
From: Justin Richer 
In-Reply-To: 
Date: Thu, 26 Feb 2015 11:40:30 -0500
Message-Id: 
References: 
To: Kathleen Moriarty 
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMKsWRmVeSWpSXmKPExsUixG6nrtvs8z7E4NMdDouGnfkWJ9++YnNg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4MqbdNi747loxe8Ua1gbGazZdjJwcEgImEg0T rrND2GISF+6tZ+ti5OIQEljMJPHrZCsrhLORUWL79jssEM5DJombyw6zgbQIC3hILH51hgnE 5hUwkJh76gsTSBGzwCRGiWOzZrFAzJWSeHB7DSOIzSagKjF9TQtYA6dAoMTW9evBbBag+NqJ h4HWcQA1q0u0n3SBmGkl8e7FRbBWIYEAiR8314LZIgIWEmuav7GBlEsIyEv0bEqfwCg4C8kV s5BdAZJgFkiSuP+4gQnC1pZYtvA1M4StKbG/ezkLpriGROe3iawQtrzE9rdzoOKWEotn3oCq t5W41bcAaqadxKNpi1gXMHKvYpRNya3SzU3MzClOTdYtTk7My0st0jXWy80s0UtNKd3ECIo/ Tkm+HYxfDyodYhTgYFTi4d2R+y5EiDWxrLgy9xCjJAeTkiivrtf7ECG+pPyUyozE4oz4otKc 1OJDjCpAux5tWH2BUYolLz8vVUmEV98aqI43JbGyKrUoH6ZMmoNFSZx30w++ECGB9MSS1OzU 1ILUIpisDAeHkgRvrDdQo2BRanpqRVpmTglCmomD8xCjBAcP0HA2kBre4oLE3OLMdIj8KUZF KXHedyDXCYAkMkrz4HphafMVozjQW8K8SiDtPMCUC9f9CmgwE9DgA3ffgQwuSURISTUwMulM NK85Ojek3I/hzHz9RYf1301n2Zj++FjZ7FqOjZOEDnTqndd7n8Z26NPzpdtsj+fMEXvVYHty t1Dur1+f6u1u2OfnpfxnjlwX1u7b8WCFAPOnv6efM010uZBnX+WodcfURt5f45vvXIapq11/ 1MtJ/p15YE/7Wjvrhh0b1LWZ7Hf9/ftYX4mlOCPRUIu5qDgRAMxfGCJ2AwAA
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-dyn-reg-management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Feb 2015 16:40:39 -0000

--Apple-Mail=_736388E3-3177-4937-B63F-47F24D740F65
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_9D8FE10C-067F-480C-A070-63F1EDC75CA0"


--Apple-Mail=_9D8FE10C-067F-480C-A070-63F1EDC75CA0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Feb 26, 2015, at 11:04 AM, Kathleen Moriarty =
 wrote:
>=20
> Hello,
>=20
> I reviewed draft-ietf-oauth-dyn-reg-management, which reads well and I =
just have a few questions and suggestions below that would be good to =
address prior to IETF last call.
>=20
> Section 1.3
> Bullet D might be easier to read as a list within the bullet.

OK, I=E2=80=99ll try that and see how it renders in the various output =
formats. Lists-within-lists don=E2=80=99t always play nice in my =
experience, hence the paragraph format, but we=E2=80=99ll see what it =
looks like. I agree that it=E2=80=99s an intimidating block of =
information there. :)

>=20
> Section 2
> This is something I don't recall offhand and may be in place in =
another draft, so a pointer would be great.  Is there an MTI set for one =
of the recommended cipher suites in the TLS & DTLS BCP to ensure =
interoperability (but also allow for algorithm agility)?  If not and =
there is a reason, please explain.
> See section 4: =
https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ =

> This is not the right draft to add this content, but I'd like to know =
if it is covered somewhere or doesn't need to be for some reason.  TLS =
requirements should point to that draft (assuming one exists) so there =
is only one place to update if needed for any specific requirements to =
OAuth.

This is a copy of the text found in =
https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#section-5

We basically just want to say =E2=80=9Cuse an encrypted channel=E2=80=9D =
and point to the best guidance there is out there at the time. There =
shouldn=E2=80=99t be any specific requirements for OAuth. Maybe in the =
future the IETF could have a standard single reference for transport =
protection that can be included a-la the 2119 definitions?

>=20
> IANA Considerations:
> The shepherd report says that there are no actions for IANA, so this =
needs to be updated as the draft is the specification required to add =
two new entries to an existing registry, established by the parent =
document.  It does require DE review on the mailing list: =
oauth-ext-review@ietf.org 
> If that has been done, then a pointer to the archive would be helpful.
>=20
> Thank you.
>=20
> --
>=20
> Best regards,
> Kathleen

Thanks for the review,
 =E2=80=94 Justin

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


--Apple-Mail=_9D8FE10C-067F-480C-A070-63F1EDC75CA0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Feb 26, 2015, at 11:04 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

=

--Apple-Mail=_9D8FE10C-067F-480C-A070-63F1EDC75CA0--

--Apple-Mail=_736388E3-3177-4937-B63F-47F24D740F65
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJU70x/AAoJEDPAngkbd+w9YmQIAKOKCbps/vxbY2bJb+h2Bh1K
V60fp5BDEdzLtV2Qk2GBSAiCBSCnpMQ37OeCHsW/06oLRXZvpS9V/W8alUh0Z6UN
//EZAsCottwsylVxExMoLlTnBjWaDVKRNL84PziFRoEXgTzPMNuFk2SZRgSG+nZ8
Z2xSajXshxABXmgqW+6377hTu0/BvliKdnI5iU+7ICEegqqcj2HUhCy7Q9szZS9o
VW8zVTd/YDEPqw2kyZ54BdmYY43rPhTKssqLu+2rt2/GwZv1bJpT9zx8OhZNWaoI
f7k5owwkSvqcXastACOZFZkyDIY3x+C58GY5Tqv9ZDjPQrQ829LlGQ+73scAaBM=
=klPM
-----END PGP SIGNATURE-----

--Apple-Mail=_736388E3-3177-4937-B63F-47F24D740F65--


From nobody Thu Feb 26 08:55:05 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F382C1A90C1 for ; Thu, 26 Feb 2015 08:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9cR7YKnzlIe for ; Thu, 26 Feb 2015 08:54:47 -0800 (PST)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5061A893F for ; Thu, 26 Feb 2015 08:54:47 -0800 (PST)
Received: by labgd6 with SMTP id gd6so12218474lab.8 for ; Thu, 26 Feb 2015 08:54:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ckztwbm04I7C8l9RKe+G4/g4a4UZ3nB7Q89+S7Edh1c=; b=qgFmn2A4IAIvdCLvqVlwWLVatU4r3Sv0ldRBQtchubI81Hy41PFPmF63eZS3/MVTlW YQY6Gnj7zawATUerZcfw8igQZ/GOC4UldggdX2a7GHLQ03gLKxpSo8xChtuZKIOotwwv SIhxd27zUn/kUUrAwPQzK+cnh2+SROm+TGjqcCNe9Y1pt5Mh1twZxR6VFmfCBfrKHLww ONImobL80UeMzLYqUThdiyUlz5y+eJun/VfLXUK4dk5GFM0rqQF/Th37VBHTLPgsuo1H 65ClEgrhmqCYzLqQ3MV7aehvGznTqHaOVDGMI/Tt+lQ/qzudHJLsIC0Kn23jYTzE/dQK CuZw==
MIME-Version: 1.0
X-Received: by 10.112.181.41 with SMTP id dt9mr8813495lbc.56.1424969685565; Thu, 26 Feb 2015 08:54:45 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Thu, 26 Feb 2015 08:54:45 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 26 Feb 2015 11:54:45 -0500
Message-ID: 
From: Kathleen Moriarty 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=001a11c36986ec861a0510009b16
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-dyn-reg-management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Feb 2015 16:54:53 -0000

--001a11c36986ec861a0510009b16
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Justin,

Thanks for the quick response.

On Thu, Feb 26, 2015 at 11:40 AM, Justin Richer  wrote:

> On Feb 26, 2015, at 11:04 AM, Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
>
> Hello,
>
> I reviewed draft-ietf-oauth-dyn-reg-management, which reads well and I
> just have a few questions and suggestions below that would be good to
> address prior to IETF last call.
>
> Section 1.3
> Bullet D might be easier to read as a list within the bullet.
>
>
> OK, I=E2=80=99ll try that and see how it renders in the various output fo=
rmats.
> Lists-within-lists don=E2=80=99t always play nice in my experience, hence=
 the
> paragraph format, but we=E2=80=99ll see what it looks like. I agree that =
it=E2=80=99s an
> intimidating block of information there. :)
>
>
Thanks for playing with this, it might help.

>
> Section 2
> This is something I don't recall offhand and may be in place in another
> draft, so a pointer would be great.  Is there an MTI set for one of the
> recommended cipher suites in the TLS & DTLS BCP to ensure interoperabilit=
y
> (but also allow for algorithm agility)?  If not and there is a reason,
> please explain.
> See section 4: https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
> This is not the right draft to add this content, but I'd like to know if
> it is covered somewhere or doesn't need to be for some reason.  TLS
> requirements should point to that draft (assuming one exists) so there is
> only one place to update if needed for any specific requirements to OAuth=
.
>
>
> This is a copy of the text found in
> https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#section-5
>

Yes, I realized that when I read it, thanks.

>
> We basically just want to say =E2=80=9Cuse an encrypted channel=E2=80=9D =
and point to the
> best guidance there is out there at the time. There shouldn=E2=80=99t be =
any
> specific requirements for OAuth. Maybe in the future the IETF could have =
a
> standard single reference for transport protection that can be included
> a-la the 2119 definitions?
>

I brought this up as I read a few drafts for last week's telechat, one was
the BCP for TLS.  As a result, it got me digging into a few drafts to see
how it is getting used.  Hence, me noticing this possible issue in this
review.

The TLS protocol itself defines a large number of cipher suites for use
that are registered with IANA (defined per version, but you have to dig
into the referenced specs to see when each was added).

Then a number of protocols that use TLS define an MTI to ensure interop
between implementations, but typically have an explicit statement to allow
for algorithm agility.  The recent drafts seem to select one of the
recommended cipher suites from the list int he new TLS BCP.

Does use of TLS show up in an earlier draft or published OAuth RFC where
this would be appropriate to define?  How do implementations ensure interop
now? Maybe that will help answer this question.


> IANA Considerations:
> The shepherd report says that there are no actions for IANA, so this need=
s
> to be updated as the draft is the specification required to add two new
> entries to an existing registry, established by the parent document.  It
> does require DE review on the mailing list: oauth-ext-review@ietf.org
> If that has been done, then a pointer to the archive would be helpful.
>
> Thank you.
>
> --
>
> Best regards,
> Kathleen
>
>
> Thanks for the review,
>  =E2=80=94 Justin
>
>  _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>


--=20

Best regards,
Kathleen

--001a11c36986ec861a0510009b16
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Justin,

Thanks for the quick respons=
e.

On Thu, F=
eb 26, 2015 at 11:40 AM, Justin Richer <jricher@mit.edu> wrote=
:
On Feb 26, 2015, at 11:04 AM, Kathleen Moriarty <kathleen.mor=
iarty.ietf@gmail.com> wrote:

Hello,

I reviewed=C2=A0draft-ietf-oauth-dyn-reg-management, which reads wel=
l and I just have a few questions and suggestions below that would be good =
to address prior to IETF last call.

Section 1.3
Bul=
let D might be easier to read as a list within the bullet.

OK, I=E2=80=99ll try that and see =
how it renders in the various output formats. Lists-within-lists don=E2=80=
=99t always play nice in my experience, hence the paragraph format, but we=
=E2=80=99ll see what it looks like. I agree that it=E2=80=99s an intimidati=
ng block of information there. :)


Thanks for playing with this, it might=
 help.=C2=A0

Section 2
This is something I don't =
recall offhand and may be in place in another draft, so a pointer would be =
great.=C2=A0 Is there an MTI set for one of the recommended cipher suites i=
n the TLS & DTLS BCP to ensure interoperability (but also allow for alg=
orithm agility)?=C2=A0 If not and there is a reason, please explain.
<=
div>See section 4:=C2=A0https://datatracker.ietf.org/doc/draft-=
ietf-uta-tls-bcp/
This is not the right draft to add this con=
tent, but I'd like to know if it is covered somewhere or doesn't ne=
ed to be for some reason.=C2=A0 TLS requirements should point to that draft=
 (assuming one exists) so there is only one place to update if needed for a=
ny specific requirements to OAuth.

<=
/div><=
/div>

Yes, I realized that when I read it, thank=
s.=C2=A0

We basically just want to say =E2=80=9Cuse a=
n encrypted channel=E2=80=9D and point to the best guidance there is out th=
ere at the time. There shouldn=E2=80=99t be any specific requirements for O=
Auth. Maybe in the future the IETF could have a standard single reference f=
or transport protection that can be included a-la the 2119 definitions?=C2=
=A0
=C2=A0
I brought this up a=
s I read a few drafts for last week's telechat, one was the BCP for TLS=
.=C2=A0 As a result, it got me digging into a few drafts to see how it is g=
etting used.=C2=A0 Hence, me noticing this possible issue in this review.

The TLS protocol itself defines a large number of c=
ipher suites for use that are registered with IANA (defined per version, bu=
t you have to dig into the referenced specs to see when each was added).

Then a number of protocols that use TLS define an MT=
I to ensure interop between implementations, but typically have an explicit=
 statement to allow for algorithm agility.=C2=A0 The recent drafts seem to =
select one of the recommended cipher suites from the list int he new TLS BC=
P.=C2=A0

Does use of TLS show up in an earlier dra=
ft or published OAuth RFC where this would be appropriate to define?=C2=A0 =
How do implementations ensure interop now? Maybe that will help answer this=
 question.
=C2=A0
<=
div>
IANA Considerations:
The she=
pherd report says that there are no actions for IANA, so this needs to be u=
pdated as the draft is the specification required to add two new entries to=
 an existing registry, established by the parent document.=C2=A0 It does re=
quire DE review on the mailing list:=C2=A0oauth-ext-review@ietf.org
If that has been done, then a poin=
ter to the archive would be helpful.
Thank you.

-- 

Best regards,
Kathleen
<=
/div>

Thanks for the review,
=C2=A0=E2=80=94 Justin




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



-- 

Best regards,
Kathleen



Hello,

I =
reviewed draft-ietf-oauth-dyn-reg-management, which reads well and =
I just have a few questions and suggestions below that would be good to =
address prior to IETF last call.

Section 1.3
Bullet D might be easier to =
read as a list within the bullet.

OK, I=E2=80=99ll try that and see how it renders =
in the various output formats. Lists-within-lists don=E2=80=99t always =
play nice in my experience, hence the paragraph format, but we=E2=80=99ll =
see what it looks like. I agree that it=E2=80=99s an intimidating block =
of information there. :)

Section 2
This is =
something I don't recall offhand and may be in place in another draft, =
so a pointer would be great.  Is there an MTI set for one of the =
recommended cipher suites in the TLS & DTLS BCP to ensure =
interoperability (but also allow for algorithm agility)?  If not =
and there is a reason, please explain.
See section =
4: https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
This is not the right draft to add this content, but =
I'd like to know if it is covered somewhere or doesn't need to be for =
some reason.  TLS requirements should point to that draft (assuming =
one exists) so there is only one place to update if needed for any =
specific requirements to OAuth.


We basically just want to say =
=E2=80=9Cuse an encrypted channel=E2=80=9D and point to the best =
guidance there is out there at the time. There shouldn=E2=80=99t be any =
specific requirements for OAuth. Maybe in the future the IETF could have =
a standard single reference for transport protection that can be =
included a-la the 2119 definitions? 


IANA =
Considerations:
The shepherd report says that there =
are no actions for IANA, so this needs to be updated as the draft is the =
specification required to add two new entries to an existing registry, =
established by the parent document.  It does require DE review on =
the mailing list: oauth-ext-review@ietf.org
If =
that has been done, then a pointer to the archive would be =
helpful.

Thank you.

-- 

Best regards,
Kathleen
<=
br class=3D"">
Thanks for the review,
 =E2=80=94 =
Justin




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


--001a11c36986ec861a0510009b16--


From nobody Fri Feb 27 17:35:23 2015
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2515E1A1B2C for ; Fri, 27 Feb 2015 17:35:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPyFLHxFXwlX for ; Fri, 27 Feb 2015 17:35:20 -0800 (PST)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E4C1A1B27 for ; Fri, 27 Feb 2015 17:35:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 545D6E2036 for ; Fri, 27 Feb 2015 20:35:19 -0500 (EST)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16606-09 for ; Fri, 27 Feb 2015 20:35:17 -0500 (EST)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id 7224AE2039; Fri, 27 Feb 2015 20:35:17 -0500 (EST)
Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Fri, 27 Feb 2015 20:35:17 -0500
Message-ID: <03a80733f60f2cb1ef69b03a4187692e.squirrel@mail2.ihtfp.org>
Date: Fri, 27 Feb 2015 20:35:17 -0500
From: "Derek Atkins" 
To: oauth@ietf.org
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Subject: [OAUTH-WG] [Fwd: oauth - Requested session has been scheduled for IETF 92]
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Feb 2015 01:35:22 -0000

FYI,

-derek

---------------------------- Original Message ----------------------------
Subject: oauth - Requested session has been scheduled for IETF 92
From:    "\"IETF Secretariat\"" 
Date:    Fri, February 27, 2015 5:27 pm
To:      Hannes.Tschofenig@gmx.net
Cc:      oauth-ads@tools.ietf.org
         Hannes.Tschofenig@gmx.net
         derek@ihtfp.com
--------------------------------------------------------------------------

Dear Hannes Tschofenig,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

oauth Session 1 (2:00:00)
    Monday, Afternoon Session I 1300-1500
    Room Name: Continental size: 90
    ---------------------------------------------



Request Information:


---------------------------------------------------------
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Hannes Tschofenig

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 50
Conflicts to Avoid:
 First Priority: tls ace saag cfrg dice
 Second Priority: radext dime



Special Requests:
  Please avoid conflict with sec area BoFs.
---------------------------------------------------------



-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant