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

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.

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.

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”

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?

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

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