July 06, 2011 8:56 AM
> > To: Eran Hammer-Lahav
> > Cc: oauth@ietf.org; Torsten Lodderstedt
> > Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions
> >
> >
> >
> > Clickjacking
> > Clickjacking is the process of tricking users into re
gt; Sent: Wednesday, July 06, 2011 8:56 AM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org; Torsten Lodderstedt
> Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions
>
>
>
> Clickjacking
> Clickjacking is the process of tricking users into revealing confidenti
sday, July 06, 2011 8:56 AM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org; Torsten Lodderstedt
> Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions
>
> Reworded to modify the text around secret and some additional info on
> redirect-uri (with some input from S
er-Lahav
>
> To:
>
> Mark Mcgloin/Ireland/IBM@IBMIE, Torsten Lodderstedt
>
> Cc:
>
> "oauth@ietf.org"
>
> Date:
>
> 04/07/2011 20:01
>
> Subject:
>
> Re: [OAUTH-WG] Draft 16 Security Considerations additions
>
> This needs to be r
011 09:16:28 -0700
To: OAuth WG mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft 16 review notes
On Sun, Jul 3, 2011 at 11:21 PM, Eran Hammer-Lahav
mailto:e...@hueniverse.com>> wrote:
Need proposed text.
...
Need proposed text.
...
Need proposed text.
I will add to this that at
33 -0700
To: Torsten Lodderstedt
mailto:tors...@lodderstedt.net>>
Cc: "oauth@ietf.org<mailto:oauth@ietf.org>"
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions
Hi Torsten
It was implicit that the state parameter would be secret and n
Sun, 22 May 2011 21:40:22 -0700
To: "oauth@ietf.org<mailto:oauth@ietf.org>"
mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Draft 16 comment
First, I'd like to add my support for Brian Eaton's comments on Draft 16.
They actually helped clarify the comment I
On Sun, Jul 3, 2011 at 11:21 PM, Eran Hammer-Lahav wrote:
> Need proposed text.
...
> Need proposed text.
...
> Need proposed text.
I will add to this that at this stage in the document development, any
requests for changes need to be accompanied by specific proposed text.
If you absolutely can'
.org<mailto:oauth-boun...@ietf.org>"
mailto:oauth-boun...@ietf.org>>
Subject: Re: [OAUTH-WG] draft 16 review notes
>From 4.2.1 below:
The authorization server validates the request to ensure all
required parameters are
present and valid. The authoriz
om: Eran Hammer-Lahav
To: Brian Eaton , "oauth@ietf.org"
Date: 04-07-11 01:25 PM
Subject: Re: [OAUTH-WG] draft 16 review notes
Sent by:oauth-boun...@ietf.org
From: Brian Eaton
Date: Sun, 22 May 2011 20:38:53 –0700
1.4.1 Authorization Code
From: Brian Eaton mailto:bea...@google.com>>
Date: Sun, 22 May 2011 20:38:53 –0700
1.4.1 Authorization Code
maybe expand the section on important security benefits. “The use of
authorization codes also improves the ability to recover in the event
of compromise of an application server or auth
t-uri, would that suffice?
Regards
Mark
oauth-boun...@ietf.org wrote on 23/05/2011 05:40:22:
From:
Shane B Weeden
To:
oauth@ietf.org
Date:
23/05/2011 06:26
Subject:
[OAUTH-WG] Draft 16 comment
Sent by:
oauth-boun...@ietf.org
First, I'd like to add my support for Brian Eaton's
etect malicious clients (maleware, viruses).
regards,
Torsten.
> -Ursprüngliche Nachricht-
> Von: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com]
> Gesendet: Dienstag, 28. Juni 2011 12:26
> An: Shane B Weeden
> Cc: oauth@ietf.org; oauth-boun...@ietf.org
> Betreff: Re: [OAU
#x27;s redirect-uri, would that suffice?
Regards
Mark
oauth-boun...@ietf.org wrote on 23/05/2011 05:40:22:
> From:
>
> Shane B Weeden
>
> To:
>
> oauth@ietf.org
>
> Date:
>
> 23/05/2011 06:26
>
> Subject:
>
> [OAUTH-WG] Draft 16 comment
>
> S
"William J. Mills" wrote on 01/06/2011 00:17:44:
> From:
>
> "William J. Mills"
>
> To:
>
> Mark Mcgloin/Ireland/IBM@IBMIE, "oauth@ietf.org"
>
> Date:
>
> 01/06/2011 00:17
>
> Subject:
>
> Re: [OAUTH-WG] Draft 16 Security Cons
gt;
> 01/06/2011 09:11
>
> Subject:
>
> Re: [OAUTH-WG] Draft 16 Security Considerations additions
>
>
> Hi Mark,
>
> Am 31.05.2011 22:58, schrieb Mark Mcgloin:
> > Eran
> >
> > Here are some additional sections to add to the next draft under
security
&
Hi Mark,
Am 31.05.2011 22:58, schrieb Mark Mcgloin:
Eran
Here are some additional sections to add to the next draft under security
considerations
CSRF
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the website trusts or has
authe
http://tools.ietf.org/html/rfc6265#section-8.2 has good text on CSRF
definition, which I think is clearer. Perhaps that can be used to touch up
your first paragraph?
From: Mark Mcgloin
To: oauth@ietf.org
Sent: Tuesday, May 31, 2011 1:58 PM
Subject: [OAUTH-WG
Eran
Here are some additional sections to add to the next draft under security
considerations
CSRF
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the website trusts or has
authenticated. CSRF attacks on OAuth approvals can allow an a
Am 28.05.2011 20:25, schrieb Doug Tangren:
I just re-read draft 16 on this memorial day weekend :)
1. I had a comment on the suggested use of the authorization code flow
for native clients [1].
Section 10.9 on auth code transmission [2] suggests users of the auth
code flow should implement
I just re-read draft 16 on this memorial day weekend :)
1. I had a comment on the suggested use of the authorization code flow for
native clients [1].
Section 10.9 on auth code transmission [2] suggests users of the auth code
flow should implement tls on it's redirect uri. This makes sense for we
It would be great if you could do a similarly detailed read of the bearer token
spec as well!
-- Mike
Sent from my Windows Phone
-Original Message-
From: Brian Eaton
Sent: Sunday, May 22, 2011 8:39 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft 16 review notes
I just read over the
First, I'd like to add my support for Brian Eaton's comments on Draft 16.
They actually helped clarify the comment I have below
I found section 9 to be in contradiction to a part of section 6. In
particular in section 9:
Native applications SHOULD use the authorization code grant type flow
I just read over the whole of the draft for the first time in a while.
I looked it over mostly for
a) places where spec and reality were going to have trouble intersecting
and
b) places where security advice would be useful
and
c) grammer and speling, because I notices things like that
Mos
Hi Doug,
Am 19.05.2011 04:09, schrieb Doug Tangren:
Followup questions from draft 16
1. On storing user password for the resource owner creds flow. If the
client stores a access token along with the refresh token [1] to
refresh it, there should be no need to store the users password as
menti
Followup questions from draft 16
1. On storing user password for the resource owner creds flow. If the client
stores a access token along with the refresh token [1] to refresh it, there
should be no need to store the users password as mentioned here [2] right?
2. What value does adding the client
, 2011 4:43 PM
To: OAuth WG
Subject: [OAUTH-WG] Draft -16
Draft -16 should show up in a few minutes. This will be the last draft before
the meeting next week and the reference document for discussion. If you plan to
attend the meeting, this is a required reading.
Changes since -15
Draft -16 should show up in a few minutes. This will be the last draft before
the meeting next week and the reference document for discussion. If you plan to
attend the meeting, this is a required reading.
Changes since -15:
- New security consideration section (closes issue #7)
-
28 matches
Mail list logo
