Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717F5126B7F for ; Mon, 1 May 2017 22:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hhasu6WErl-E for ; Mon, 1 May 2017 22:35:08 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) (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 CB4E7128B88 for ; Mon, 1 May 2017 22:32:50 -0700 (PDT) Received: from [80.187.107.84] (helo=[10.155.141.93]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1d5QQZ-0007DW-00; Tue, 02 May 2017 07:32:47 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-5B14A1E0-B12E-4243-BBF1-7129B13D8D98; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (14E304) In-Reply-To: <22d06952-94ab-e6a9-d2b2-f96f8252bf5e@mit.edu> Date: Tue, 2 May 2017 07:32:42 +0200 Cc: John Bradley , William Denniss , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <4107AB98-25D8-4542-B932-CD6F921D0D1D@lodderstedt.net> References: <77856AF4-9B2E-4478-9509-1459037C24E4@ve7jtb.com> <22d06952-94ab-e6a9-d2b2-f96f8252bf5e@mit.edu> To: Justin Richer X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 05:35:11 -0000 --Apple-Mail-5B14A1E0-B12E-4243-BBF1-7129B13D8D98 Content-Type: multipart/alternative; boundary=Apple-Mail-D85031C7-97EB-4E48-BC38-97F862D46BCA Content-Transfer-Encoding: 7bit --Apple-Mail-D85031C7-97EB-4E48-BC38-97F862D46BCA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 to keep the optional parameter along with clear wording regarding securit= y risk and interoperability=20 > Am 29.04.2017 um 15:12 schrieb Justin Richer : >=20 > +1, documentation is better. Though we also need to keep in mind that this= was the justification for the password flow in 6749, which has been abused a= ll over the place (and continues to this day). Still, it would be arguably w= orse without that so I'm good with keeping the parameter in there as long as= we're careful. > Namely: So long as the user code is *also* delivered separately to the use= r, we would have interoperability between the two. What I don't think w= e want is some systems that *require* the URI parameter on the approval URL a= nd other implementations that *forbid* it. That case could end up with somet= hing like: I've got a set-top system that's incapable of displaying a separa= te user code because it always assumes it's baked into the URL, and then I t= ry to put it on a server that requires the code be entered separately.=20 > The resulting spec needs to be clear that the box MUST be able to display b= oth the URL and the code separately, in case the URL does not include the co= de. In fact, maybe we'd even want to introduce a new parameter from the endp= oint for the pre-composed URL: >=20 > user_code > REQUIRED. The end-user verification code. >=20 > verification_uri > REQUIRED. The end-user verification URI on the authorization > server. The URI should be short and easy to remember as end- > users will be asked to manually type it into their user-agent. > composite_verification_uri > OPTIONAL. The end-user verification URI with the end-user=20 > verification code already included. See discussion in [blah] > for its use. >=20 > -- Justin >=20 >> On 4/28/2017 6:38 PM, John Bradley wrote: >> I would like to keep the optional parameter. It is useful enough that i= f we don=E2=80=99t have it people will add it on there own as a custom param= eter. =20 >> Better to document any issues.=20 >>=20 >> John B. >>> On Apr 28, 2017, at 5:39 PM, William Denniss wrote= : >>>=20 >>> Thanks all who joined us in Chicago in person and remotely last month fo= r the discussion on the device flow. [recording here, presentation starts at= about 7min in]. =20 >>>=20 >>> The most contentious topic was addition of the user_code URI param exten= sion (introduced in version 05, documented in Section 3.3). >>>=20 >>> I'd like to close out that discussion with a decision soon so we can adv= ance to a WG last call on the draft. >>>=20 >>> To summarise my thoughts on the param: >>> It can be can be used to improve usability =E2=80=93 QR codes and NFC ca= n be used with this feature to create a more delightful user authorization e= xperience. >>> It may increase the potential phishing risk (which= we can document), as the user has less typing. This risk assessment is like= ly not one-size-fits-all, it may vary widely due to different the different p= otential applications of this standard. >>> The way it's worded makes it completely optional, leaving it up to the d= iscretion of the authorization server on whether to offer the optimisation, a= llowing them to secure it as best they see it. >>> I do believe it is possible to design a secure user experiance that incl= udes this optimization. >>> I think on the balance, it's worthwhile feature to include, and one that= benefits interop. The authorization server has complete control over whethe= r to enable this feature =E2=80=93 as Justin pointed out in the meeting, it d= egrades really nicely =E2=80=93 and should they enable it, they have control= over the user experiance and can add whatever phishing mitigations their us= e-case warrants. Rarely is there a one-size-fits-all risk profile, use-case= s of this flow range widely from mass-market TV apps to internal-only device= bootstrapping by employees, so I don't think we should be overly prescripti= ve. >>>=20 >>> Mitigating phishing is already something that is in the domain of the au= thorization server with OAuth generally, and I know that this is an extremel= y important consideration when designing user authorization flows. This spec= will be no exception to that, with or without this optimization. >>>=20 >>> That's my opinion. I'm keen to continue the discussion from Chicago and r= each rough consensus so we can progress forward. >>>=20 >>> Best, >>> William >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-D85031C7-97EB-4E48-BC38-97F862D46BCA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 to keep the optional par= ameter along with clear wording regarding security risk and interoperability=  

Am 29.04.2017 um 15:12 schrieb Justin Richer <jricher@mit.edu>:

=20 =20 =20

+1, documentation is better. Though we also need to keep in mind that this was the justification for the password flow in 6749, which has been abused all over the place (and continues to this day). Still, it would be arguably worse without that so I'm good with keeping the parameter in there as long as we're careful.

Namely: So long as the user code is *also* delivered separately to the user, we would have interoperability between the two. What I don't think we want is some systems that *require* the URI parameter on the approval URL and other implementations that *forbid* it. That case could end up with something like: I've got a set-top system that's incapable of displaying a separate user code because it always assumes it's baked into the URL, and then I try to put it on a server that requires the code be entered separately.

The resulting spec needs to be clear that the box MUST be able to display both the URL and the code separately, in case the URL does not include the code. In fact, maybe we'd even want to introduce a new parameter from the endpoint for the pre-composed URL:

   user_code
      REQUIRED.  The end-user verification code.

   verification_uri
      REQUIRED.  The end-user verification URI on the authorization
      server.  The URI should be short and easy to remember as end-
      users will be asked to manually type it into their user-agent.

   composite_verification_uri
      OPTIONAL.  The end-user verification URI with the end-user=20
      verification code already included. See discussion in [blah]
      for its use.

 -- Justin
On 4/28/2017 6:38 PM, John Bradley wrote:
I would like to keep the optional parameter.   It is useful enoug= h that if we don=E2=80=99t have it people will add it on there own as a custom parameter.  
Better to document any issues. 

John B.
On Apr 28, 2017, at 5:39 PM, William Denniss <wdenniss@google.com> wrote:

Thanks all who joined us in Chicago in person and remotely last month for the discussion on the device flow. [recording here, presentation starts at about 7min in].

The most contentious topic was addition of the user_code URI param extension (introduced in version 05, documented in Section 3.3).

I'd like to close out that discussion with a decision soon so we can advance to a WG last call on the draft.

To summarise my thoughts on the param:
=
  1. It can be can be used to improve usability =E2=80=93 QR codes and NFC can be used with t= his feature to create a more delightful user authorization experience.
  2. It may increase the potential phishing risk (which we can document), as the user has less typing. This risk assessment is likely not one-size-fits-all, it may vary widely due to different the different potential applications of this standard.
  3. The way it's worded makes it completely optional, leaving it up to the discretion of the authorization server on whether to offer the optimisation, allowing them to secure it as best they see it.
  4. I do believe it is possible to design a secure user experiance that includes this optimization.
I think on the balance, it's worthwhile feature to include, and one that benefits interop. The authorization server has complete control over whether to enable this feature =E2=80=93 as Justin point= ed out in the meeting, it degrades really nicely =E2=80=93 a= nd should they enable it, they have control over the user experiance and can add whatever phishing mitigations their use-case warrants.  Rarely is there a one-size-fits-all risk profile, use-cases of this flow range widely from mass-market TV apps to internal-only device bootstrapping by employees, so I don't think we should be overly prescriptive.

Mitigating phishing is already something that is in the domain of the authorization server with OAuth generally, and I know that this is an extremely important consideration when designing user authorization flows. This spec will be no exception to that, with or without this optimization.

That's my opinion. I'm keen to continue the discussion from Chicago and reach rough consensus so we can progress forward.

Best,
William




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

=20
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-D85031C7-97EB-4E48-BC38-97F862D46BCA-- --Apple-Mail-5B14A1E0-B12E-4243-BBF1-7129B13D8D98 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw ggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkF FZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8 El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9v XloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/ HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB 9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7G Sji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYD VR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYI KwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0B AQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3 pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXo IarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvN VmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7 JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3PxA3uZ8LQw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcwNTAyMDUzMjQyWjAjBgkqhkiG9w0BCQQxFgQUuDE02chcD1M1SEMNck8GOsjap04wgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEB AQUABIIBAGdpCGvskyV0+VQHEZlpCjVwnKgFGD+kc66E4k9aQvtyMaGtc8TzFyqwpTUf4c5jmJjq Vgqa2sCX/JHFmL7SJTQdZQQRJ4N6Qf0YepzJB5xBHvWyPU0NaDKyH/rFuOyHx5hKuB8kkaKq7r83 irad+ZzxHX+zFsF7AEvYtP7GpuJsWO4tFyY2RbrZK6NBKZukLRfoJUPtdei6WMaEzhPhrWea+K+U hEKmQvCFTFhWFaQO2isO6fx7cTK2TNreMXTJSo4S1q8OaTe4f7AR8dwqSzf8ShIuowe34rYpSnFu evmYveKHcJvIJVYjE0r9XVmStSQEUNxjUTFlo/J4rtdKJOMAAAAAAAA= --Apple-Mail-5B14A1E0-B12E-4243-BBF1-7129B13D8D98--