Hi Brian,
On Wed, May 30, 2018 at 12:56 PM, Brian Campbell <bcampbell@xxxxxxxxxxxxxxxx> wrote:
In reading the draft (again) I noticed a couple of things that, while maybe not substantive, seemed like they were worth raising here in last call:1:In Section 3.5 a new 'expired_token' error code is defined for when the 'device_code' has expired and the client will need to start the flow over. Shortly after the new error code definition there is text in that section that says 'If the verification codes have expired, the server SHOULD respond with the standard OAuth error "invalid_grant". Clients MAY then choose to start a new device authorization session.'This reads to me like: here's a new error for expired device code but this other code SHOULD be used for expired device code. Am I confused or otherwise missing something?I kinda suspect that the intent is that expired_token can be returned for codes that are known to be expired while invalid_grant is more of a catch all for codes that may have expired long enough ago that they have been purged from server memory/persistence or are otherwise unknown. That's my guess anyway. But the current text seems somewhat contradictory, which I think could be clarified/fixed.
I agree that the way it's documented "expired_token" would be for when you know it's expired, whereas "invalid_grant" is a more generic catch all. I think this section needs to be revisited to clear up this ambiguity. Before proposing a solution, I want to investigate a little what the existing implementations are doing around this case.
2:In section 5 about security considerations for Non-confidential Clients there's a pointer to recommendations from Section 8.9 of [RFC8252], which is about using the "state" parameter in the authorization request to protect against cross-app request forgery. That doesn't seem right or relevant to the device flow, does it? Was it intended to point to section 8.5 in RFC8252? Or something else?
Good catch.
That text was introduced in 04, https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04#section-5.4 and Section 8.9 of the 07 draft version of native apps at the time was "Client Authentication", which is now Section 8.5 of RFC8252. I will update this draft to point to Section 8.5, per the original intent.
On Tue, May 29, 2018 at 4:20 PM, The IESG <iesg-secretary@xxxxxxxx> wrote:______________________________
The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Device Flow for
Browserless and Input Constrained Devices'
<draft-ietf-oauth-device-flow-09.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2018-06-12. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.
Abstract
This OAuth 2.0 authorization flow for browserless and input
constrained devices, often referred to as the device flow, enables
OAuth clients to request user authorization from devices that have an
Internet connection, but don't have an easy input method (such as a
smart TV, media console, picture frame, or printer), or lack a
suitable browser for a more traditional OAuth flow. This
authorization flow instructs the user to perform the authorization
request on a secondary device, such as a smartphone. There is no
requirement for communication between the constrained device and the
user's secondary device.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flo w/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flo w/ballot/
No IPR declarations have been submitted directly on this I-D.
The document contains these normative downward references.
See RFC 3967 for additional information:
rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream)
draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile
(None - )
rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IETF stream)
_________________
OAuth mailing list
OAuth@xxxxxxxx
https://www.ietf.org/mailman/listinfo/oauth
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
