+1
Reason: Clarity is always good!
Igor
On 7/28/2012 5:56 PM, Torsten Lodderstedt wrote:
Hi John,
I would prefer to make it a MUST.
regards,
Torsten.
Am 27.07.2012 18:42, schrieb John Bradley:
The text in 3.2.1 is informational to explain why there is a
REQUIRED is in 4.1.3.
Putting the
Hi John,
I would prefer to make it a MUST.
regards,
Torsten.
Am 27.07.2012 18:42, schrieb John Bradley:
The text in 3.2.1 is informational to explain why there is a REQUIRED is in
4.1.3.
Putting the explanation in the parameter description seems awkward that is why
I left it in 3.2.1 where
The text in 3.2.1 is informational to explain why there is a REQUIRED is in
4.1.3.
Putting the explanation in the parameter description seems awkward that is why
I left it in 3.2.1 where the description that public clients can send client_id
originally lived.
I also note that there is no oth
Fair enough. I read 3.2.1 as being more informative and explanatory
while 4.1.3 has the actual normative requirements. But I see what you
are saying too.
On Fri, Jul 27, 2012 at 8:36 AM, Torsten Lodderstedt
wrote:
> Hi Brian,
>
> I know. But there is this sentence in 3.2.1,
>
> --
>
> In
Hi Brian,
I know. But there is this sentence in 3.2.1,
--
In the "authorization_code" grant_type request to the token endpoint,
an unauthenticated client sends "client_id" to prevent itself from
inadvertently accepting a code
intended for a client with a different "client_id".
--
Hey Torsten,
The requirement that public clients send their client_id with an authz
code grant is in 4.1.3 (Where the Access Token Request for the code
grant is defined) of John's proposed text:
4.1.3. Access Token Request
client_id
REQUIRED if the client is NOT authenticating with
Hi John,
I would expect sending a client_id is a MUST for public clients in the authz
code grant type. That's not how I read the proposed text for section 3.1.
regards,
Torsten.
John Bradley schrieb:
The changes introduced in Draft 29 had unintended consequences on parts of the
spec caused
Understood, however at this point major reworking of the token endpoint is
going to have to wait on the next release of OAuth.
I suspect that there will eventually be a 2.1.
For now this should let us close the book on this 3 year odyssey and address
some of the other issues like JWT etc.
John
>> The changes introduced in Draft 29 had unintended consequences on
>> parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1
>> as part of client authentication.
> this change breaks
> https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
and https://datatracker.ietf.or
+1
=nat via iPhone
On 2012/07/27, at 7:36, Dick Hardt wrote:
> +1
>
> On Jul 26, 2012, at 3:06 PM, Mike Jones wrote:
>
>> +1
>>
>> Given that the current spec inadvertently broke both the SAML profile and
>> JWT profile, I believe we need to make these changes.
>>
>>-- Mike
>>
+1
On Jul 26, 2012, at 3:06 PM, Mike Jones wrote:
> +1
>
> Given that the current spec inadvertently broke both the SAML profile and JWT
> profile, I believe we need to make these changes.
>
> -- Mike
>
> -Original Message-
> From: Brian Campbell [mailto:
+1
Given that the current spec inadvertently broke both the SAML profile and JWT
profile, I believe we need to make these changes.
-- Mike
-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 26, 2012 1:56 PM
T
I agree with the proposed changes and they do adequately address the
concerns I raised in a previous message about the unintended breaking
changes introduced in 29. Thanks for writing that up John.
On Thu, Jul 26, 2012 at 2:33 PM, John Bradley wrote:
> The changes introduced in Draft 29 had unint
The changes introduced in Draft 29 had unintended consequences on parts of the
spec caused by
Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 as part of client authentication.
This change restricts the requirement to send client_id to only Sec 4.1.4 for
clients that are not authenticated per Sec 3.2.
14 matches
Mail list logo
