Clarification would be helpful, thanks.
Note that the example in 3.2 doesn't have the client_id parameter in
the body of the request.
On Mon, May 16, 2011 at 4:50 PM, Eran Hammer-Lahav wrote:
> No, client_id is always required. Basic will just duplicate it (server must
> check they match - th
No, client_id is always required. Basic will just duplicate it (server must
check they match - that's the "basic auth binding").
I'll clarify it.
EHL
> -Original Message-
> From: Brian Campbell [mailto:bcampb...@pingidentity.com]
> Sent: Monday, May 16, 2011 3:45 PM
> To: Vlad Skvortsov
Yeah, I had just sort of being going off the assumption that
client_id is required & client_secret is not but, looking at -15
again, I agree that it's not entirely obvious. There's the text at
the end of section 3 that say allows for unauthenticated clients.
Then in 3.1 both client_id & client_sec
Folks-- Sorry for the intrusion, but this seemed the community best positioned
to respond to this query. I'm interested to talk to security architects and
application architects in organizations that have informed opinions on the
"client-server" pattern of OAuth as an enterprise web services sec
On Fri, May 13, 2011 at 04:15:17PM -0700, Eran Hammer-Lahav wrote:
> The client_id is required. client_secret is not.
Ok, thanks! This might deserve a clarification in the spec though — not
obvious.
>
> EHL
>
> On May 13, 2011, at 16:00, "Vlad Skvortsov" wrote:
>
> > Hi,
> >
> > a have a que
-Doug Tangren
http://lessis.me
On Mon, May 16, 2011 at 4:06 AM, Eran Hammer-Lahav wrote:
> The attributes serves both as a flag to indicate that a body hash has been
> included, but also to allow validation of the request (excluding the body)
> before the body is received.
>
>
Makes sense. Thank
Hi Igor, I will pass on your comments
Regards
Mark
Igor Faynberg wrote on 16/05/2011
09:45:23:
> Igor Faynberg
> 16/05/2011 09:45
>
> Please respond to
> igor.faynb...@alcatel-lucent.com
>
> To
>
> Mark Mcgloin/Ireland/IBM@IBMIE
>
> cc
>
> fcore...@pomcor.com, oauth@ietf.org
>
> Subject
>
> R
Hi Igor, comments Inline below
Igor Faynberg wrote on 16/05/2011
09:02:25:
> Igor Faynberg
> 16/05/2011 09:02
>
> Please respond to
> igor.faynb...@alcatel-lucent.com
>
> To
>
> Mark Mcgloin/Ireland/IBM@IBMIE
>
> cc
>
> oauth@ietf.org
>
> Subject
>
> Re: [OAUTH-WG] Formal security protocol ana
Mark,
Many thanks for posting this. I am thinking of the next step.
This paper proposes to use the Password-Based Asymmetric Key Exchange
protocol. Many messages ago, I had proposed to use the Password-Based
DH key exchange for the symmetric key generation.
Another option is to mandate som
The attributes serves both as a flag to indicate that a body hash has been
included, but also to allow validation of the request (excluding the body)
before the body is received.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Doug
Tangren
Sent: Sunday, May 15, 20
The approach looks right to me; the key is that the 1.0 state machine is
rather simple. A priori, I don't see the 2.0 as more complex (even
though it involves an additional machine), and I think it should be
straight-forward to build the machine and run the reachability analysis
on the system
11 matches
Mail list logo
