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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
