Dynamic client registration makes provisioning secrets much easier on
devices like this. When it was originally written, the target was a
public native application, where every copy would've gotten the same
secret at manufacture time rendering it not as secret. We've got good
ways around that restriction now, managing instances separately.
-- Justin
On 2/6/2016 6:41 AM, Torsten Lodderstedt wrote:
I support adoption of this draft as starting point.
I would like to note the following:
- this flow is vulnerable to session fixation - A discussion of this
threat along with a reasonable mitigation needs to be added.
- I dont't understand why this particular flow precludes use of client
secrets. The application rendered on a device with limited input
capabilities could be a web application as well. For exampe, we run
such apps on our IP TV platform.
kind regards,
Torsten.
Am 04.02.2016 um 20:17 schrieb Hannes Tschofenig:
Hi all,
On January 19th I posted a call for adoption of the OAuth 2.0 Device
Flow specification, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15403.html
The feedback at the Yokohama IETF meeting was very positive and also the
response on the mailing list was positive.
To conclude, based on the call <draft-denniss-oauth-device-flow-00> will
become the starting point for work in the OAuth working group. Please
submit the document as draft-ietf-oauth-device-flow-00.txt.
Ciao
Hannes & Derek
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
