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

[William Denniss <[e-mail]>]

Rifaat and Hannes,

Thank you for your review, and for the consensus judgement.  Version v06
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06> has been
posted that actions this feedback.

I would also like to see a WGLC issued on the document.

Best,
William

On Mon, May 8, 2017 at 6:02 AM, Rifaat Shekh-Yusef <[e-mail]>
wrote:

> 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
>>
>>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>