New tweak:
The security ramifications of allowing unauthenticated access by
public clients to the
token endpoint, as well as the issuance of refresh tokens to public
clients MUST be
taken into consideration.
EHL
-Original Message-
From: Richer,
I find the original text clearer, myself.
-- Justin
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav [e...@hueniverse.com]
Sent: Thursday, August 18, 2011 5:16 PM
To: Lu, Hui-Lan (Huilan); Brian Campbell
Cc: oauth
Eran Hammer-Lahav wrote:
Added to 2.4.1:
client_secret
REQUIRED. The client secret. The client MAY omit the
parameter if the
client secret
is an empty string.
I would suggest rewording the above as follows:
client_secret
REQUIRED unless it is an
-Original Message-
From: Lu, Hui-Lan (Huilan) [mailto:huilan...@alcatel-lucent.com]
Sent: Thursday, August 18, 2011 1:45 PM
To: Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: RE: [OAUTH-WG] treatment of client_id for authentication and
identification
Eran Hammer-Lahav
FWIW, I was okay with the text EHL had originally proposed for 21.
client_secret
REQUIRED. The client secret. The client MAY omit the
parameter if the client secret
is an empty string.
I would suggest rewording the above as follows:
client_secret
It is difficult to parse the last sentence of 3.2.1: The security
ramifications of
allowing unauthenticated access by public clients to the token endpoint
MUST be considered, as well as the issuance of refresh tokens to public
clients, their scope, and lifetime.
I think it should be
I just noticed that some words were missing in my previous post. Here is the
full text that Eran requested:
Allowing unauthenticated access to the token endpoint by public clients has
security ramifications. So does
issuing refresh tokens to public clients. Such security ramifications MUST be
Added to 2.4.1:
client_secret
REQUIRED. The client secret. The client MAY omit the parameter
if the client secret
is an empty string.
Added to 3.2.1:
A public client that was not issued a client password MAY use the
'client_id' request
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
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
Okay, looking at some of those drafts again, I see that now. Except
for -16 they are all pretty similar on client_id back to -10.
Apparently it was my misunderstanding. Maybe I'm the only one who
doesn't get it but I do think it could be clearer. I'd propose some
text but I'm still not fully
The way I've set it up in –18 is that the client_id parameter in the
authorization endpoint is used to identify the client registration record. The
identifier is described in section 2.3. Then in section 2.4.1 the parameter is
extended for use with the token endpoint for client authentication
Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav:
The way I've set it up in --18 is that the client_id parameter in the
authorization endpoint is used to identify the client registration
record. The identifier is described in section 2.3. Then in section
2.4.1 the parameter is extended for use
You just issue them a set of password credentials (which can include an empty
or fixed password). There is nothing preventing you from doing that and once
you do, the spec requires them to use those credentials.
EHL
From: Torsten Lodderstedt
That was more or less what I was trying to say as well. There are
times when client identification is needed at the token endpoint and
it's not clear if or how, short of actual authentication, the current
spec allows for it.
On Wed, Jul 27, 2011 at 11:38 AM, Torsten Lodderstedt
There is no need and I don't intend to pro-forma issue client secrets
just to conform to some text of the spec. I thought we are beyond that
point.
The obvious approach would be to use the client_id the same way as it is
used on the authz endpoint.
regards,
Torsten.
Am 27.07.2011 13:45,
This is the best way to keep the protocol simple and secure of the main use
cases it explicitly addresses.
There is not clean way to introduce the client_id parameter at the token
endpoint without making it confusing for developers. The problem is how do
explain when to perform authentication
I personally think that would be more confusing than just adding the
client_id parameter to the token endpoint request (independent of client
authentication credentials).
Am 27.07.2011 18:17, schrieb Brian Campbell:
I think that would be helpful, thanks.
On Wed, Jul 27, 2011 at 12:43 PM,
There is not clean way of adding it.
First where? In each flow of the token endpoint or just in 3.2? Then how is it
defined? Optional? Required for public clients? How does it work alongside
authentication? If you use client_password or Basic then it becomes
authentication but otherwise
I'll take this as –20 last call comment.
From: Brian Campbell
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com
Date: Wed, 27 Jul 2011 15:17:48 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com
Cc: Torsten Lodderstedt
I'm probably somewhat biased by having read previous version of the
spec, previous WG list discussions, and my current AS implementation
(which expects client_id) but this seems like a fairly big departure
from what was in -16. I'm okay with the change but feel it's wroth
mentioning that it's
Not exactly.
The current setup was pretty stable up to –15. In –16 I tried to clean it up by
moving the parameter into each token endpoint type definition. That didn't work
and was more confusing so in –17 I reverted back to the –15 approach.
What makes this stand out in –20 is that all the
I need to revisit a question that came up about two months ago. I
thought I had a clear understanding of when client_id was and wasn't
included in access token requests but drafts 18/19 seemed to have
changed things (or my understanding of 16 was wrong).
The question is, when is client_id a
client_id is only required on the authorization endpoint, not the token
endpoint. -18 cleaned up how the document talked about client authentication in
general. So you should remove client_id from your draft and instead mention
client authentication (if appropriate).
EHL
-Original
How should HTTP Basic be used for a client not in possession of a
client secret?
On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
client_id is only required on the authorization endpoint, not the token
endpoint. -18 cleaned up how the document talked about
It shouldn't. You are still allowed to reuse client_id outside the specific
password credentials use case. Just make sure the way the parameter is defined
in v2 is consistent.
EHL
-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Monday, July 25, 2011
I'm asking from both an implementation perspective as well as the spec
perspective.
On the spec side, draft-ietf-oauth-assertions will deal with client_id
and while it's currently required I'd guess it will become optional or
even forbidden.
On the implementation side, let me make sure I
29 matches
Mail list logo
