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

[Simon Moffatt <[e-mail]>]

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

-- 
ForgeRock <http://www.forgerock.com/> 	*Simon Moffatt*
Product Management  |  ForgeRock
*tel* [phone]  | *e* [e-mail] 
<mailto:[e-mail]>
*skype* simon.moffatt  | *web* www.forgerock.com 
<http://www.forgerock.com/>  | *twitter* @simonmoffatt


ForgeRock Live 2017 <https://summits.forgerock.com/>