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

From: Mike Jones <[email-masked]>
Date: Sun, 8 May 2016 05:27:51 +0000

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

---

From: Alex Bilbie <[email-masked]>
Date: Tue, 10 May 2016 07:25:38 +0000

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 <[email-masked]> 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.
>
>
>
> 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 implementations currently use verification_url instead of
> verification_uri.  This should be changed to verification_uri to match IETF
> naming practices.
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>