I second the request to enhance the security considerations section to
address any known issues identified with the flow (e.g. phishing, client
impersonation, etc). The polling/state issues are likely not at the same
scale for other providers, as they are for Google, so I think this flow
still has future value.
Thanks,
George
On 5/31/18 2:20 PM, Mike Jones wrote:
Naveen, I have to disagree with your recommendation that we not finish
this work. People have been using variants of the device flow for
years. Standardizing it will improve interoperability. Also,
standardizing it will make the security considerations for using it
commonly available to implementers – whereas currently people are
mostly operating in the dark or based on their own intuitions of
what’s safe and what’s not.
If you believe that there are specific things we should add to the
security considerations, please say what they are, and we can do so.
But saying “stop and wait for something else that isn’t defined yet”
isn’t a helpful or realistic position to take.
-- Mike
*From:* nvn...@gmail.com <nvn...@gmail.com> *On Behalf Of *Naveen Agarwal
*Sent:* Thursday, May 31, 2018 12:39 AM
*To:* William Denniss <wdenniss=40google....@dmarc.ietf.org>
*Cc:* Brian Campbell <bcampb...@pingidentity.com>; i...@ietf.org;
draft-ietf-oauth-device-f...@ietf.org; oauth <oauth@ietf.org>;
oauth-cha...@ietf.org
*Subject:* Re: [OAUTH-WG] Last Call:
<draft-ietf-oauth-device-flow-09.txt> (OAuth 2.0 Device Flow for
Browserless and Input Constrained Devices) to Proposed Standard
I have a general concern on making the device flow a standard as this
suffers from a number of issues that are quite fatal. At Google we
have limited this flow to be used for very basic/limited scopes as
phishing concerns are very real. Also the protocol suffers from
clients polling (overloading the servers) and server having to keep a
large amount of state. I think this protocol is close to its useful
end of life (at Google) and we are working on alternatives with
stronger client attestation that also mitigate other issues.
Separately, we have seen a lot more abusers/hackers use OAuth in
various forms to attack users.
I don't know how many IDPs have implemented this flow but by making it
a standard, a lot more people will implement it and I'm sure they will
not be able to avoid the issues that are highlighted.
Sorry, I know it has taken a lot of work to get the document to his
stage so my comments may feel too harsh and I apologize. Please do
know that I have been quite involved in this protocol from the
beginning and we have gone through a lot of pain and have been
discussing shutting this down fairly regularly. So this is to start
the conversation if we think this protocol is for the future or just
something from our past that we want to see it documented as a standard.
Thanks
Naveen
On Wed, May 30, 2018 at 5:06 PM, William Denniss
<wdenniss=40google....@dmarc.ietf.org
<mailto:wdenniss=40google....@dmarc.ietf.org>> wrote:
On Wed, May 30, 2018 at 3:48 PM, Brian Campbell
<bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com>>
wrote:
I realize this is somewhat pedantic but I don't think
referencing 4.1.2.1
works given how RFC 6749 set things up. Rather I believe that
the device
flow needs to define and register "access_denied" as a valid
token endpoint
response error code (it's not a token endpoint response error
per RFC 6749
sec 5.2 nor has it been registered https://www.iana.org/assignmen
ts/oauth-parameters/oauth-parameters.xhtml#extensions-error
<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error>).
Also
invalid_grant is a a token endpoint response error from RFC
6749 sec 5.2 so
that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1
<https://tools.ietf.org/html/rfc6749#section-4.1.2> defines
errors returned
from the authorization endpoint. But the device flow errors
are from the
token endpoint.
Yes, that's true. It's still the token endpoint, so 5.2 does in
fact apply, it's just we're mixing in authorization-style actions
which were not previously considered/used for that endpoint.
Do you have any proposed text to resolve this?
On Wed, May 30, 2018 at 4:27 PM, William Denniss <
wdenniss=40google....@dmarc.ietf.org
<mailto:40google....@dmarc.ietf.org>> wrote:
> Hi Andrew,
>
> On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <
> andrewsciber...@pingidentity.com
<mailto:andrewsciber...@pingidentity.com>> wrote:
>
>> Hi William
>>
>> You are right that the document explicitly indicates which
error codes
>> may be returned. However I think it's ambiguous as to which
error within
>> Section 5.2 of RFC6749 would apply in the scenario of a
user not granting
>> access.
>>
>> I think that this ambiguity is highlighted further by the
Google
>> implementation (https://developers.google.com
>> /identity/protocols/OAuth2ForDevices#step-6-handle-
>> responses-to-polling-requests
>>
<https://developers..google.com/identity/protocols/OAuth2ForDevices#step-6-handle-responses-to-polling-requests
<http://google.com/identity/protocols/OAuth2ForDevices#step-6-handle-responses-to-polling-requests>>)
>> not adhering to the explicit statement of the document and
electing to use
>> a (more appropriate) error code that exists outside of
section 5.2..
>>
>>
>
> Oh, I see what you mean now. Yes, given this is an
authorization request,
> not a token request, the errors from Section 4.1.2.1
> <https://tools.ietf.org/html/rfc6749#section-4.1.2> are more
relevant.
>
> I believe it was the authors intention to reference that set
of errors, so
> I will plan to update the doc to reference 4..1.2.1
instead. Good catch!
> Thank you.
>
>
>>
>> On Thu, May 31, 2018 at 8:06 AM, William Denniss
<wdenn...@google.com <mailto:wdenn...@google.com>>
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras
<andrewsciber...@pingidentity.com
<mailto:andrewsciber...@pingidentity.com>> wrote:
>>>
>>> Hello
>>>>
>>>>
>>>> Do we feel that the document should be more specific in
addressing how
>>>> the authorization service should respond to a device
access token request
>>>> when the user has refused to grant access to the device?
>>>>
>>>>
>>>> The document currently indicates in section 3.5 that a
success response
>>>> defined in section 5.1 of RFC6749, an error as defined in
section 5.2 of
>>>> RFC6749 (this includes invalid_request, invalid_client,
invalid_grant,
>>>> unauthorized_client, unsupported_grant_type, and
invalid_scope), or a new
>>>> device flow error code (authorization_pending, slow_down, and
>>>> expired_token) may be returned in a response to a device
token request
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
