: Tuesday, September 20, 2011 7:12 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2
If the server issues clients with password credentials it MUST support HTTP
Basic (this is the flip side of 'the client MAY use HTTP Basic') and should
only
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Tuesday, September 20, 2011 3:13 PM
3.1.1 Response Type
The response_type parameter is REQURED but its absence SHOULD result
in an error. Why not MUST?
Changes
of listing them
(and their status/response).
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Tuesday, September 20, 2011 3:13 PM
To: Leif Johansson; OAuth WG
Subject: Re: [OAUTH-WG] secdir review of draft-ietf
Sending to the right place.
EHL
From: DIEGO GONZALEZ MARTINEZ [mailto:die...@tid.es]
Sent: Friday, October 07, 2011 1:35 AM
To: draft-ietf-oauth...@tools.ietf.org
Subject: draft-ietf-oauth-v2: Doubt about chapter 4.2
Hello,
My name is Diego González, I work in Telefónica RD and I'm following
'Client credentials' needs to be removed from invalid_grant. It is not
appropriate.
Use invalid_client all the way to a fully authenticate client. ANY failure to
authenticate the client should result in invalid_client.
Use unauthorized_client for an authenticate client which is not permitted
I can work with Berry's text.
Another alternative is to:
* Require the server to implement at least one of Bearer and MAC, or provide
the client with a method for discovering or requesting a specific token type
(which is beyond the scope).
This way, until there is a discovery method, each
Bearer tokens are practically identical to OAuth 1.0 PLAINTEXT. Get your facts
right.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Anthony Nadalin
Sent: Sunday, December 04, 2011 1:37 AM
To: Mike Jones; Barry Leiba; Stephen Farrell
It has to be.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of MARCON, JEROME (JEROME)
Sent: Friday, December 02, 2011 5:47 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] TR: [oauth] #27: Incorporate bearer scope character
restrictions into
This functionality can be implemented in two main ways:
1. Using the client credentials flow to get an access token, then using
the protocol as usual
2. Just using the Bearer (over SSL) or MAC token schemes without the rest
of OAuth
EHL
From: oauth-boun...@ietf.org
doesn't care.
It feels like the bearer scheme just doesn't work for what I'm trying to do.
Thanks
Brian
On Tue, Nov 29, 2011 at 1:06 PM, Eran Hammer-Lahav
e...@hueniverse.commailto:e...@hueniverse.com wrote:
This functionality can be implemented in two main ways:
1. Using the client
: Thursday, November 24, 2011 5:03 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] MAC: body-hash
I'd lobby for something more than just prose, since for me, including the
body or body hash in the HMAC is a pretty essential piece of security for any
real implementation. I understand
:
No objection from me, but it's too bad the browser vendors aren't
interested.
-Peter
On Sat, Nov 19, 2011 at 10:33 AM, Eran Hammer-Lahav
e...@hueniverse.com wrote:
I would like to drop the cookies support defined in the MAC document
due to lack of interest from the browser vendors
-Original Message-
From: apps-discuss-boun...@ietf.org [mailto:apps-discuss-boun...@ietf.org] On
Behalf Of Mark Nottingham
Sent: Wednesday, November 23, 2011 10:22 PM
To: IETF Apps Discuss; draft-ietf-oauth-v2-bearer@ietf.org
Cc: The IESG
Subject: [apps-discuss] APPS Area review of
I would like to drop the cookies support defined in the MAC document due to
lack of interest from the browser vendors. At this point it is most likely
going to be an unimplemented proposal. If there is interest in the future, it
can be proposed in a separate document. This will allow us to
I want to reaffirm our previous consensus to drop the body-hash parameter and
leave the ext parameter. Body-hash as currently specified is going to cause
significant interop issues due to character (and other) encoding issues.
Providers who desire to MAC the body can define their own ext use
The charset is restricted so no issues.
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Saturday, November 19, 2011 7:46 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] MAC: body-hash
I haven't read the MAC spec recently enough, did you already deal with the
character set
We had a long discussion about what to use for the numerical component of the
nonce string. I would like to suggest we use:
nonce
REQUIRED. A unique string generated by the client to allow the
server to verify that a request has never been made before and
helps
-Original Message-
From: Mark Nottingham [mailto:m...@mnot.net]
Sent: Tuesday, May 31, 2011 4:57 PM
The normalized request string contains the request-URI and values
extracted from the Host header. Be aware that intermediaries can and do
change these; e.g., they may change an
Thanks.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Justin Richer
Sent: Friday, August 12, 2011 11:44 AM
To: oauth@ietf.org
Cc: Anganes, Amanda L
Subject: [OAUTH-WG] MAC Token Comments
2: MAC Key: The server MUST NOT reissue a
1. Should we specify some token type as mandatory to implement? Why or
why not (*briefly*)?
On the server - no. It makes no sense because the server dictates the token
type so if it decides to never issue the mandated type, what's the point in
implementing?
On the client, maybe. If the
No, but you can define a new parameter for use instead or alongside the
existing parameter.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Declan Newman
Sent: Tuesday, November 08, 2011 1:58 AM
To: oauth@ietf.org
Cc: Will Simpson; Geoffrey Bilder
Subject:
I have not seen any responses to these items so I assume the group is in
agreement with the comments made. I will push out a revised ID addressing these
items in a few days.
EHL
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Stephen
Do you want to see no change or adjust it to client must implement both, server
decides which to use.
EHL
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of John Bradley
[ve7...@ve7jtb.com]
Sent: Wednesday, November 02, 2011 1:06 PM
To: Torsten
: Wednesday, November 02, 2011 1:45 PM
To: John Bradley
Cc: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] AD review of -22
So perhaps this is the interesting point of difference.
On 11/02/2011 08:37 PM, John Bradley wrote:
It is up to the server to decide what formats it will support
That's a whole different issue as this is about talking to a single server
retuning two tokens with different scopes.
EHL
From: Dick Hardt [dick.ha...@gmail.com]
Sent: Saturday, October 29, 2011 12:07 AM
To: Eran Hammer-Lahav
Cc: Dan Taflin; OAuth WG
Why not just ask for one access token with all the scopes you need, then
refresh it by asking for the different subsets you want.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Dan Taflin
Sent: Tuesday, October 25, 2011 3:37 PM
To:
Who is we had already decided? This was not discussed on this list.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Hannes Tschofenig
Sent: Thursday, October 20, 2011 10:19 AM
To: Richer, Justin P.
Cc: OAuth WG; Barry Leiba
Subject:
This is not how the IETF, or for that matter, any standards body operates.
Working groups must be focused with a clearly defined purpose. For example, JWT
is a large enough effort and clear enough to form a working group today - just
go ahead and propose it. JWT has OAuth binding but it is not
What possible rational is there for SWD to belong in the OAuth working group
and in the security area?
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Mike Jones
Sent: Thursday, October 20, 2011 12:12 PM
To: Hannes Tschofenig; OAuth
-Lahav; Hannes Tschofenig; OAuth WG
Subject: RE: [OAUTH-WG] Rechartering
Because it's intended for (and used for) discovery of OAuth endpoints...
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, October 20, 2011 12:42 PM
To: Mike Jones; Hannes
18, 2011 at 9:39 AM, Julian Reschke julian.resc...@gmx.de
wrote:
On 2011-10-18 17:38, Eran Hammer-Lahav wrote:
Space is allowed inside a quoted string and is already not allowed
inside each scope string.
EHL
...
a) yes.
b) well:
The value of the scope parameter
No-brainer, low-hanging-fruit:
2) Token Revocation
8) User Experience Extension
Don't see the point, but simple enough not to care if plenty of others want to
see it included:
4) Client Instance Extension
5) XML Encoding
9) Request by Reference
Now for the objectionable...
1) Dynamic Client
Space is allowed inside a quoted string and is already not allowed inside each
scope string.
EHL
-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de]
Sent: Tuesday, October 18, 2011 6:50 AM
To: Eran Hammer-Lahav
Cc: Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH
Sending to the right place.
On Oct 18, 2011, at 20:36, qijun83
qiju...@gmail.commailto:qiju...@gmail.com wrote:
Dear Sir,
It's really very pleasure for me to write to you for asking some questions
about oauth-v2-22 as follows.
In section 2.3 (Client Authentication), it is recommended to use
I agree.
EHL
-Original Message-
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Monday, October 17, 2011 6:07 AM
To: Richer, Justin P.
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues
Proposed Resolutions
The scopes cross
17, 2011 8:25 AM
To: Eran Hammer-Lahav
Cc: Hannes Tschofenig; John Bradley; Richer, Justin P.; OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues
Proposed Resolutions
It is good that we have an agreement among a few people that more text
needs to be provided
It's an open question for the list.
EHL
-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de]
Sent: Sunday, October 16, 2011 11:00 AM
To: Mike Jones
Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth WG;
Eran Hammer-Lahav
Subject: Re: [OAUTH-WG
This is not sufficient.
For scope, if you are going to restrict the allowed characters, you must either
specify how to encode all other values to fit the field, or we must move this
restriction to the v2 specification so that no encoding is required.
For the token, you need to also define
to explicitly
define the allowed range for tokens. Saying they must comply with the b64token
rule is enough, just not enough to leave it implied via the header definition.
EHL
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Friday, October 14, 2011 9:51 AM
To: Eran Hammer-Lahav; Hannes
Not that I will ever use this, but this is really broken way to create a
protocol. Now is the time to make hard choices and pick one format.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Mike Jones
Sent: Wednesday, October 12, 2011
I agree with this analysis and its conclusions.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Sunday, October 02, 2011 5:51 AM
To: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26
The best
Two observations:
- I doubt anyone is going to implement RFC 5987 in most OAuth 2.0
libraries, mostly because it offers little value and,
- No one really needs scope values other than limited ASCII or URIs
There should not be any interoperability issues with the
On Sep 9, 2011, at 15:31, André DeMarre andredema...@gmail.com
wrote:
Greetings Everyone,
I hope the draft isn't too far along for these comments.
(draft-ietf-oauth-v2-21)
1. AUTHORIZATION CODE RESTRICTIONS
The specification (particularly Section 4.1) does not say if the
Thanks. Fixed in a few other places too.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Paul
Madsen
Sent: Monday, September 12, 2011 1:30 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Typo in Sec 5.1
scope
OPTIONAL. The scope of the access request as
Thanks.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Niv Steingarten
Sent: Monday, September 12, 2011 2:01 PM
To: OAuth WG
Subject: [OAUTH-WG] Typos and language in -21
In section 10.12 (CSRF):
5th paragraph: A CSRF attack
'invalid_grant'. Added (e.g.) to the error code to make it more explicit.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Colm Divilly
Sent: Tuesday, September 13, 2011 9:08 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Section 4.3.
Thanks.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Anganes, Amanda L
Sent: Monday, September 19, 2011 8:23 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth 2.0 v21 Nits and Typos
Lots of minor grammar and wording catches here. I
(+OAuth WG, -everyone else)
Thanks Leif.
See comments inline. Whatever issues are still open will be addressed along
with the rest of the IETF LC feedback.
EHL
-Original Message-
From: Leif Johansson [mailto:le...@sunet.se]
Sent: Monday, September 12, 2011 11:31 AM
** General
If the server issues clients with password credentials it MUST support HTTP
Basic (this is the flip side of 'the client MAY use HTTP Basic') and should
only support the client_secret parameter if it has clients incapable of using
HTTP Basic.
This language has been tweaked to reach a delicate
This will go into the IETF LC feedback loop.
EHL
-Original Message-
From: André DeMarre [mailto:andredema...@gmail.com]
Sent: Tuesday, September 20, 2011 7:12 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2
If the server issues
Just a general note: you don't need every spec to become a working group item.
If you get an area director to sponsor your draft, you can push it through
sooner as an individual submission. Sometimes you don't even need sponsorship.
I'm not saying this out of any objection to the WG taking on
Is this malicious piece of software external a native application either past
of a native client or external to the browser?
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, September 14, 2011 6:51 AM
To: Eran Hammer-Lahav
Cc: Niv
I have no objection, but much clearer? :-)
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Justin Richer
Sent: Wednesday, September 14, 2011 6:04 AM
To: Greg Brail
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Nit: Language in section
I suggest we address this particular scenario in the thread model document.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, September 14, 2011 7:26 AM
To: Eran Hammer-Lahav
Cc: Niv Steingarten; oauth@ietf.org
Subject: RE: [OAUTH-WG
Sending to the right address.
EHL
On Sep 9, 2011, at 15:31, André DeMarre andredema...@gmail.com wrote:
Greetings Everyone,
I hope the draft isn't too far along for these comments.
(draft-ietf-oauth-v2-21)
1. AUTHORIZATION CODE RESTRICTIONS
The specification (particularly Section
Michael,
I suggest you go back and read the entire thread again:
http://www.ietf.org/mail-archive/web/oauth/current/maillist.html
I don't think you have been listening to the 11 (!) people who all completely
disagree with you and dismiss your suggestions (on technical grounds). The one
person
Melinda,
We clearly have different views on what it means to [deal] with this like an
adult. I would like to address what I *think* were your two main points: the
lack of civility in addressing the feedback provided by Mr. Thomas, and the
alleged IETF process violation by me as editor. I have
You can revoke access tokens but only if they are Stateful (which usually means
a DB lookup for every API call which doesn’t scale as well).
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Phillip Hunt
Sent: Wednesday, September 07, 2011 4:24 PM
To: William Mills
I agree. If you are going to install a native app, you better trust it not to
do bad things. Grabbing your password is the least interesting thing such an
app can abuse. I don't see any need to change the v2 draft.
EHL
On Sep 6, 2011, at 11:10, Igor Faynberg igor.faynb...@alcatel-lucent.com
Don't install crap on you device or computer. OAuth is the least of your
concern if you install bad software.
If there was a solution to this we would not need an antivirus.
EHL
On Sep 6, 2011, at 11:23, Michael Thomas m...@mtcc.com wrote:
Eran Hammer-Lahav wrote:
I agree. If you
I'm dismissive of this being an OAuth problem.
EHL
On Sep 6, 2011, at 11:35, Michael Thomas m...@mtcc.com wrote:
Eran Hammer-Lahav wrote:
Don't install crap on you device or computer. OAuth is the least of your
concern if you install bad software.
If there was a solution to this we
this is all on the shoulders of the end user.
It sure looks like oauth is easily subverted in the real world.
Mike
*From:* Michael Thomas m...@mtcc.com
*To:* Eran Hammer-Lahav e...@hueniverse.com
*Cc:* oauth@ietf.org oauth
protections but they are
all gone if you install a bad native app – following your logic people should
not use TLS in apps either.
I do not consider this an issue.
EHL
From: Michael Thomas m...@mtcc.commailto:m...@mtcc.com
Date: Tue, 6 Sep 2011 11:58:11 -0700
To: Eran Hammer-lahav e
I understood his request and disagree that any action needs to be taken. It is
unreasonable to expect every protocol to discuss the security considerations of
a user installing malware.
EHL
From: Melinda Shore melinda.sh...@gmail.commailto:melinda.sh...@gmail.com
Date: Tue, 6 Sep 2011 12:18:18
It is a problem. For a few months now we have been going through this over and
over again. The longer we work on this draft the more of this two-sentence
changes people suggest. They don't make the document any better, create a false
sense of comprehensiveness, and just further delay being
Wg consensus is clearly to do nothing here.
EHL
On Sep 6, 2011, at 17:05, Michael Thomas m...@mtcc.com wrote:
On 09/06/2011 03:27 PM, Eran Hammer-Lahav wrote:
So yeah, unless you can prove that there is an actual problem, we are done.
I will point out that the chairs make
, at 17:13, Melinda Shore melinda.sh...@gmail.com wrote:
On 09/06/2011 04:09 PM, Eran Hammer-Lahav wrote:
Wg consensus is clearly to do nothing here.
?? No, it clearly is not, unless you're laboring
under the misconception that consensus means voting.
At any rate the job of calling consensus
What do you think such a warning would accomplish? There are no ways to
mitigate malware (bad client or otherwise), and using passwords make it even
easier.
End users are not going to read the specification and service providers have
absolutely no alternatives.
As for the example, the issue
You clearly feel strongly about this. The only way forward if you want to
pursue this is to suggest text and show how providing it will lead to more
secure implementations. Otherwise this is just going in circles.
EHL
On Sep 6, 2011, at 18:13, Michael Thomas m...@mtcc.com wrote:
On
think you can offer text that will win wg consensus you should. Arguing
with me as a participant is, unfortunately, part of the deal.
EHL
On Sep 6, 2011, at 18:27, Michael Thomas m...@mtcc.com wrote:
On 09/06/2011 06:24 PM, Eran Hammer-Lahav wrote:
You clearly feel strongly about this. The only
On 2011-09-04, at 4:25 PM, Eran Hammer-Lahav wrote:
The corresponding 'state' parameter definition:
RECOMMENDED. An opaque value used by the client to maintain
state between the request
and callback. The authorization server includes this value
when redirecting
Sorry for the late response.
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Sunday, August 21, 2011 10:59 AM
To: Eran Hammer-Lahav
Cc: Niv Steingarten; oauth@ietf.org
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
, 2011 1:36 PM
To: Eran Hammer-Lahav
Cc: e...@sled.com; oauth@ietf.org
Subject: Re: [OAUTH-WG] redirect uri validation
Hi Eran,
Am 15.08.2011 08:57, schrieb Eran Hammer-Lahav:
Added to 1.4.2:
When issuing an implicit grant, the authorization server does
not
authenticate
, Justin P. [mailto:jric...@mitre.org]
Sent: Friday, August 19, 2011 4:56 AM
To: Eran Hammer-Lahav; Lu, Hui-Lan (Huilan); Brian Campbell
Cc: oauth
Subject: RE: [OAUTH-WG] treatment of client_id for authentication and
identification
I find the original text clearer, myself.
-- Justin
of
the resource owner.
EHL
From: William J. Mills [mailto:wmi...@yahoo-inc.com]
Sent: Thursday, August 25, 2011 12:11 PM
To: Anthony Nadalin; Eran Hammer-Lahav; Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
I had proposed text, and I'll reprise it here
Where is this feedback?
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Monday, August 29, 2011 1:16 AM
To: Eran Hammer-Lahav
Cc: Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] Security area review
Hi Eran,
I gave presentations
#19 - no text proposed, consider current text sufficient. Close.
#20 - reference to DOM variable removed. Close.
#21 - resolved by new text, no comments received. Close.
#24 - pending comments. Close if agreed to by Torsten.
#25 - no comments received to proposed text which has been applied.
I'd like to ask the chairs to declare a 2 weeks review period limited to
changes made since -20 after which we will either declare -21 as the final WG
draft or publish a quick -22 with all changes agreed prior on the list and no
additional WG review period. Of course, the chairs can change all
to move forward.
EHL
From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 25 Aug 2011 08:11:01 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com,
Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net
Cc: OAuth WG (oauth
To: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Cc: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com,
Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net,
OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
oauth@ietf.orgmailto:oauth@ietf.org
I believe we have full consensus on this approach.
EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Tuesday, August 23, 2011 11:06 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
making CSRF prevention a MUST
Sounds like a good compromise. I will play with the text Bill proposed and
follow up with new text on the list.
EHL
From: Phil Hunt phil.h...@oracle.commailto:phil.h...@oracle.com
Date: Mon, 22 Aug 2011 08:57:54 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com
Cc
I light to the recent discussion, do you still feel that changing 'state' from
optional to required is the best approach?
EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Sunday, August 21, 2011 11:04 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH
-Original Message-
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Sunday, August 21, 2011 10:39 PM
To: David Recordon
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
I think the complication here is that CSRF issues are multi
not proposing we close this issue just yet.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
To demonstrate why making state required
I think using phishing here is misleading. This is not a classic phishing
attack. I'm open to other suggestions.
EHL
From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Wednesday, August 17, 2011 3:22 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: AW: Authorization Code Leakage
' is the right place and if it is, find a new way to describe it because
using it for CSRF is a relative new use case for the parameter (which still
have all the previous use cases).
EHL
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Wednesday, August 17, 2011 11:41 PM
To: Eran Hammer-Lahav
Cc: OAuth
...@telekom.de]
Sent: Thursday, August 18, 2011 12:12 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: AW: Authorization Code Leakage feedback (Yaron Goland)
The security document designates it as Authorization code leakage through
counterfeit client
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel
, August 18, 2011 5:49 AM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
Impersonation)
Here are two very simple examples. They are very naive ones, but get the
point across and I would not be suprised
Hey Torsten,
-Original Message-
From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Thursday, August 18, 2011 12:52 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; oauth@ietf.org
Subject: AW: [OAUTH-WG] Draft 20 last call comment (Resource Owner
Impersonation)
I've
Chairs - please open an issue for this: Clarifying reference to refresh tokens
in section 1.4.3 of -20.
-Original Message-
From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Thursday, August 18, 2011 1:01 AM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: AW: [OAUTH
-Original Message-
From: Niv Steingarten [mailto:nivst...@gmail.com]
Sent: Thursday, August 18, 2011 10:16 AM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
Impersonation)
(thanks for the typo
-Original Message-
From: Niv Steingarten [mailto:nivst...@gmail.com]
Sent: Thursday, August 18, 2011 11:08 AM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
Impersonation)
On Thu, Aug 18, 2011
-Original Message-
From: Niv Steingarten [mailto:nivst...@gmail.com]
Sent: Thursday, August 18, 2011 12:12 PM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
Impersonation)
On Thu, Aug 18, 2011
(mostly business folks that want to avoid user
interaction because it's too scary and somehow informing the user what
they are doign is a bad thing).
-bill
From: Niv Steingarten nivst...@gmail.commailto:nivst...@gmail.com
To: Eran Hammer-Lahav e
-Original Message-
From: Niv Steingarten [mailto:nivst...@gmail.com]
Sent: Thursday, August 18, 2011 1:04 PM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
Impersonation)
On Thu, Aug 18, 2011
-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
that up to the
editors of that document.
EHL
From: William J. Mills [mailto:wmi...@yahoo-inc.com]
Sent: Thursday, August 18, 2011 9:21 PM
To: Niv Steingarten
Cc: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
Impersonation)
While I agree
10.6. Authorization Code Leakage: Comment I fancy myself as being
reasonably intelligent and I'm unclear what attack is actually being described
here.
Yeah... I had to go back to -16 to be reminded of the section original title
'session fixation attack' to figure out what this was about.
Noticed this follow up question after I sent this:
10.6. Authorization Code Leakage: Comment on The authorization server
SHOULD require the client to register their redirection URI: Why is this a
should?
Because comparing the redirect_uri value used between the two calls
(authorization and
1 - 100 of 977 matches
Mail list logo
