Subject: [OAUTH-WG] OAuth 2.0 Device Flow: Call for Adoption Finalized

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 4 Feb 2016 20:17:58 +0100

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 6 Feb 2016 12:41:26 +0100

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:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Sat, 6 Feb 2016 09:21:49 -0500

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:
> capabilities could be a web application as well. For exampe, we run 
> such apps on our IP TV platform.
>
> kind regards,
> Torsten.
>