Hi Filip,
Yes, this was exactly what I was thinking about. Good to know I'm
working in the right direction. I must say that the spec reads really
well and is fairly straightforward to implement.
Best regards,
Emond Papegaaij
Topicus KeyHub
On Mon, Mar 11, 2019 at 6:29 PM Filip Skokan wrote:
>
>
Hi Emond,
the way i approached implementation of device flow into an OIDC server was
to allow all already registered and handled parameters excluding the ones
[1] that really don't make sense for the flow at the device authorization
endpoint.
What can be validated at the device authorization endp
Yes, that's how I implemented it as well. I return 'invalid_request'
when the client_id is missing entirely.
Do you have any thoughts how this specification should work in
combination with other specs, such as OIDC? For example, the OIDC
Authentication Request specifies several additional paramete
While probably not terribly important from an interoperability perspective,
I agree that does seem like an omission.
I took a quick look at our implementation and bad requests to the device
authorization endpoint will indeed return what is a standard OAuth 2.0
error response normally from the toke
Dear all,
I'm working on an implementation of the OAuth 2.0 Device Flow for Browserless
and Input Constrained Devices and noticed a possible omission in the spec.
Section 3.2 describes the Device Authorization Response, but only the success
response is specified, not the error response. I would
