1. Device Flow <draft-ietf-oauth-device-flow-03>
W. Denniss, S. Myrseth/S. Moffatt, J. Bradley, M. Jones, H. Tschofenig

2. Scope
Use case when an OAuth interaction gets "outsourced" to a separate device in order to allow user authentication and collecting the consent.
Useful for devices that have limited user interface capabilities.

3. Issue#1: Polling The AS polls the device for the authorization code.
This is not a problem when the user completes the authentication and consent step quickly.

4. Do we need more than polling?
Aaron Parecki : “beauty of the current device flow spec is that it's so simple”
William Denniss:
“I like the idea of adding HTTP/2 based long-poll as an optional enhancement”
“the polling gets the job done”
Simon Moffatt:
“ForgeRock implemented the AS part of the device flow in January. “
“Simplicity is key here.”
“running an HTTP stack on the device, is maybe overkill for some deployments though”
Torsten Lodderstedt: “OpenID MODRNA working group, we are working on specs facing similar challenges and decided to offer both pull and push style communication”

5. Issue#2: User Interface
Authorization server provides User Code & Verification URI to the user.
User enters these on separate device.
What guidance can be given to improve user interaction and improve experience?

6. Issue#3: Alternative Contact Mechanisms
Current mechanism
User Code
Verification URI
Device
Client
Authorization
Server
User
Browser
User Code
Verification URI

7. Alternative Contact Mechanisms
Example alternative
SMS with User Code
Phone #
User
Device
Client
User Code
User Code
Authorization
Server