I think the spec is better with the (optional) user_code in it.
-- Mike
From: William Denniss [mailto:[email protected]]
Sent: Friday, April 28, 2017 1:39 PM
To: [email protected]; John Bradley <[email protected]>; Hannes Tschofenig
<[email protected]>; Mike Jones <[email protected]>
Subject: OAuth 2.0 Device Flow: IETF98 Follow-up
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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
