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