Re: [OAUTH-WG] OAuth Device Flow data from Microsoft implementations

[Alex Bilbie <[e-mail]>]

Hi Mike,

Some interesting feedback.


> One of the two implementations has an optional “message” parameter
> containing text that is to be shown to the user.  This one also uses a
> “mkt” parameter to indicate the locale of the message (as opposed to, for
> instance, ui_locales).  The developers want to know what the working group
> thinks of the possibility of supporting some kind of a “message” parameter.


In our test implementation we're serving a localised message parameter by
interpreting the Accept-Language request header.

I agree that an optional message parameter should be part of the
specification.

Alex

On Sun, 8 May 2016 at 06:27 Mike Jones <[e-mail]> wrote:

> I sat down with the two Microsoft teams that have implementations of the
> OAuth Device Flow and compared what they currently have built to
> draft-ietf-oauth-device-flow.  Here’s some data that we assembled…
>
>
>
> One of the two implementations has an optional “message” parameter
> containing text that is to be shown to the user.  This one also uses a
> “mkt” parameter to indicate the locale of the message (as opposed to, for
> instance, ui_locales).  The developers want to know what the working group
> thinks of the possibility of supporting some kind of a “message” parameter.
>
>
>
> The developers would like an example in the spec that shows the use of
> simple polling.
>
>
>
> We are using the “device_code” grant type.  The token request is missing
> from the spec, including the grant type being missing from the spec.
>
>
>
> One implementation adds two new errors: auth_pending and
> expired_device_code.  (The spec uses authorization_pending.)  This
> implementation also uses the access_denied error defined by RFC 6749.
>
>
>
> The other uses authorization_pending, code_expired, and
> authorization_declined.  The developers agreed that authorization_declined
> should become access_denied.  That implementation hasn’t implemented
> slow_down.
>
>
>
> The developers wanted to ask what the right code expiration error code
> is.  They felt that invalid_grant may be a bit too broad.
>
>
>
> Our requests in both implementations do match the specification.
>
>
>
> Our implementations currently use verification_url instead of
> verification_uri.  This should be changed to verification_uri to match IETF
> naming practices.
>
>
>
> Our default expires_in is 900 (15 minutes).  Our default interval is 5
> seconds.
>
>
>
> Both implementations do intend to migrate to the syntax in the eventual
> final specification.
>
>
>
>                                                           -- Mike
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>