the client_id parameter had been added to the token endpoint in -16. As
far as I remember, the reason was to properly separate client
identification and authentication in order to support further client
authentication methods.
quote from
We had a discussion at the OAuth working group meeting about the worries people
have with using TLS.
Here is a relevant mail from a discussion around TCP crypt.
Begin forwarded message:
From: Eric Rescorla e...@rtfm.com
Date: July 28, 2011 10:53:00 AM EDT
To: tsv-a...@ietf.org
Subject:
I would be very much in favor of that addition/clarification.
On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
[...] and I can also add a short note that public clients may use
the client_id for the purpose of identification with the token endpoint.
EHL
+1
Am 28.07.2011 15:10, schrieb Brian Campbell:
I would be very much in favor of that addition/clarification.
On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahave...@hueniverse.com wrote:
[...] and I can also add a short note that public clients may use
the client_id for the purpose of
Perfect. I'll make this change after the last call before sending this to IETF
LC.
EHL
From: Torsten Lodderstedt
tors...@lodderstedt.netmailto:tors...@lodderstedt.net
Date: Thu, 28 Jul 2011 12:59:19 -0700
To: Brian Campbell
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com
Cc: Eran
My working group last call comments on draft-ietf-oauth-v2-bearer-08.txt:
1. Mentioning that this is an HTTP authentication mechanism in the title and/or
abstract would be useful to the wider IETF ( beyond) audience.
Title:
The BEARER HTTP authentication mechanism for use with OAuth 2
