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 <[email protected]> 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: > 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. > 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. > 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. > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
