+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 <jric...@mit.edu>: > > +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 <wdenn...@google.com> wrote: >>> >>> Thanks all who joined us in Chicago in person and remotely last month for >>> the discussion on the device flow. [recording here, 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). >>> >>> 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 >>> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
