Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up

[Rifaat Shekh-Yusef <[e-mail]>]

All,

Hannes and I discussed the Device Flow draft. Based on the mailing list
feedback, we see that there is a good support for keeping the "user_code"
parameter in, but there is a need to document the security implication of
this feature. If anyone is against keeping this feature, please speak up
now.


*William,*

Can you please update the document based on the feedback you received so
far?
We would like to start a WGLC after we get the new version of the draft.


We also have few comments on v05 of the draft:

Section 3.3, second paragraph:

   The document should explicitly state that this step must be done over an
   HTTPS channel.

   Also, the paragraph is talking about an "end-user" performing the
   procedure. This could be done by an administrator that has a long list
   of devices, e.g. IoT devices, that support this mechanism. So, maybe the
   document should clearly state that too.


Nits:

Section 3.3, 3rd paragraph, second line:
   Remove the "a" before "the browser"

Section 5.2, 1st paragraph, second line:
   Remove the word "they" after "attacker"

Regards,
 Rifaat & Hannes



On Tue, May 2, 2017 at 4:56 AM, Simon Moffatt <[e-mail]>
wrote:

> +1 for separate. The real world implementations we've seen tend to not
> need the URL at all.  Eg end user out of band is in a web application on
> the their laptop/tablet and that app has a "pair device" area, where they
> just enter the necessary code - so they don't even need to see/use a URL
> from the device.
>
> Having the code augmented in to the URL too opens up the ability for that
> code to be logged on intermediary network devices.
>
> SM
>
> On 02/05/17 06:32, Torsten Lodderstedt wrote:
>
> +1 to keep the optional parameter along with clear wording regarding
> security risk and interoperability
>
> Am 29.04.2017 um 15:12 schrieb Justin Richer <[e-mail]>:
>
> +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
>       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 enough that if
> we don’t 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 <[e-mail]> wrote:
>
> Thanks all who joined us in Chicago in person and remotely last month for
> the discussion on the device flow. [recording here
> <https://play.conf.meetecho.com/Playout/?session=IETF98-OAUTH-20170327-1710>,
> 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
> <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-05#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 – QR codes and NFC can
>    be used with this 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 – as Justin pointed out in the meeting, it
> degrades really nicely – and 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> [image: ForgeRock] <http://www.forgerock.com/> *Simon Moffatt*
> Product Management  |  ForgeRock
> *tel* [phone] <+44%207903%20347240>  |  *e*
> [e-mail] <[e-mail]>
> *skype* simon.moffatt  |  *web* www.forgerock.com  |  *twitter*
> @simonmoffatt
> [image: ForgeRock Live 2017] <https://summits.forgerock.com/>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>