[OAUTH-WG] Device flow feedback

[Chris Needham]

Hi,

I'm one of the contributors to the ETSI Cross Platform Authentication spec [1], which was based on an early draft of the OAuth 2.0 Device Flow.

One of the things we found useful, and not included in the current OAuth 2.0 Device Flow [2, section 3.5], is a return code for the case where the authorization server decides to cancel the pairing process. This may be due to a user interaction, such as declining the presented terms and conditions, for example. Such a return code allows the client to stop polling and to display an appropriate message to the user. (I didn't find a suitable error code in RFC6749.)

In the ETSI spec we used the error code 'cancelled' for this purpose:

cancelled

The authorization server has cancelled the pairing process. This can occur,
for example, if the user declined to authorize the client, e.g., by not
accepting terms and conditions presented to them by the authorization server.

Best regards,

Chris

[1] http://www.etsi.org/deliver/etsi_ts/103400_103499/103407/01.01.01_60/ts_103407v010101p.pdf
[2] https://tools.ietf.org/id/draft-ietf-oauth-device-flow-06.txt

--
Chris Needham
Principal Software Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London W12 7SB

[Thomas Broyer]

Wouldn't expired_token be appropriate here?

Post by Chris Needham
Hi,
I'm one of the contributors to the ETSI Cross Platform Authentication spec
[1], which was based on an early draft of the OAuth 2.0 Device Flow.
One of the things we found useful, and not included in the current OAuth
2.0 Device Flow [2, section 3.5], is a return code for the case where the
authorization server decides to cancel the pairing process. This may be due
to a user interaction, such as declining the presented terms and
conditions, for example. Such a return code allows the client to stop
polling and to display an appropriate message to the user. (I didn't find a
suitable error code in RFC6749.)
cancelled
The authorization server has cancelled the pairing process. This can occur,
for example, if the user declined to authorize the client, e.g., by not
accepting terms and conditions presented to them by the authorization server.
Best regards,
Chris
[1]
http://www.etsi.org/deliver/etsi_ts/103400_103499/103407/01.01.01_60/ts_103407v010101p.pdf
[2] https://tools.ietf.org/id/draft-ietf-oauth-device-flow-06.txt
--
Chris Needham
Principal Software Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London W12 7SB
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Chris Needham]

It’s useful to be able to distinguish those cases from the client’s point of view.

From: Thomas Broyer [mailto:***@gmail.com]
Sent: 05 July 2017 11:16
To: Chris Needham <***@bbc.co.uk>; ***@ietf.org
Subject: Re: [OAUTH-WG] Device flow feedback

Wouldn't expired_token be appropriate here?

On Wed, Jul 5, 2017 at 12:02 PM Chris Needham <***@bbc.co.uk<mailto:***@bbc.co.uk>> wrote:
Hi,

I'm one of the contributors to the ETSI Cross Platform Authentication spec [1], which was based on an early draft of the OAuth 2.0 Device Flow.

One of the things we found useful, and not included in the current OAuth 2.0 Device Flow [2, section 3.5], is a return code for the case where the authorization server decides to cancel the pairing process. This may be due to a user interaction, such as declining the presented terms and conditions, for example. Such a return code allows the client to stop polling and to display an appropriate message to the user. (I didn't find a suitable error code in RFC6749.)

In the ETSI spec we used the error code 'cancelled' for this purpose:

cancelled

The authorization server has cancelled the pairing process. This can occur,
for example, if the user declined to authorize the client, e.g., by not
accepting terms and conditions presented to them by the authorization server.

Best regards,

Chris

[1] http://www.etsi.org/deliver/etsi_ts/103400_103499/103407/01.01.01_60/ts_103407v010101p.pdf
[2] https://tools.ietf.org/id/draft-ietf-oauth-device-flow-06.txt
--
Chris Needham
Principal Software Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London W12 7SB

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth