+1
to using the same client authn method as for the /token endpoint
On 3/11/19 12:31 PM, Brian Campbell wrote:
On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan <[email protected]
<mailto:[email protected]>> wrote:
Strike that, it should maybe just use the registered auth method
for the token endpoint?
Yeah, that's what I'd think would be the way to go.
If there's auth we should also make it clear that client_id should
not be omitted from the request body and it must be the same as
the one provided with client authentication.
Fair point.
S pozdravem,
*Filip Skokan*
On Mon, 11 Mar 2019 at 17:14, Filip Skokan <[email protected]
<mailto:[email protected]>> wrote:
If we're about to add client authentication for the
device_authorization_endpoint, i'd say we should also register
for device_authorization_endpoint_auth_method,
device_authorization_endpoint_auth_signing_alg client
metadata. Maybe define the default value to be "none" / not
provided to be in line with the late draft implementations. Wdyt?
S pozdravem,
*Filip Skokan*
On Mon, 11 Mar 2019 at 17:08, Brian Campbell
<[email protected]
<mailto:[email protected]>> wrote:
I do realize it's very late in the process for this
document but believe these omissions can be addressed in
the document with only minor changes/additions and that
it'd be better late than not at all..
On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell
<[email protected]
<mailto:[email protected]>> wrote:
Another omission[1] (maybe, I believe it is anyway) to
the Device Flow is that client authentication isn't
defined for the device authorization request to device
authorization endpoint.
I suspect that it's largely an oversight because
public clients are really the conical use-case for the
device flow and no authentication is needed or
possible in that case. There are, however, likely to
be cases where a client with credentials will do the
device flow and it would be good for the AS to be able
to properly authenticate such clients before setting
up and saving the state for the transaction. Having
normal client authentication at device authorization
endpoint also brings better consistency to client
identification/authentication for requests made
directly from client to AS.
[1] error responses from the device authorization
endpoint should probably also be defined
https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4
/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./_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
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./
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
Identity Standards Architect
Verizon Media Work: [email protected]
Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
