+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
+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 :
>
> +1, documentation is better. Though we also need to keep in mind that this
> was the justification for the password flow in 6749, which h
+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
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 wrote:
>
> Thanks all who joined us in Chicago in person an
I think the spec is better with the (optional) user_code in it.
-- Mike
From: William Denniss [mailto:wdenn...@google.com]
Sent: Friday, April 28, 2017 1:39 PM
To: oauth@ietf.org; John Bradley ; Hannes Tschofenig
; Mike Jones
Subject: OA
