, 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
This is fantastic feedback. Some parts moved to new threads.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Mike Jones
Sent: Wednesday, August 10, 2011 2:39 PM
1.4. Authorization Grant: Change resource owner authorization to
resource
This seems to include two separate items.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Anthony Nadalin
Sent: Friday, August 12, 2011 8:29 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] x-www-form-urlencoded
In the text on the
Thanks for the feedback.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Justin Richer
Sent: Thursday, August 11, 2011 2:07 PM
1.2/1.4: The term authorization grant remains confusing and the
introduction is riddled with jargon like
I've read the thread leading to this, and the proposed text and I do not
understand the attack. Can you provide a step-by-step scenario of how an
attacker gains access?
Also, it is unlikely that any major provider is going to require CAPCHA as part
of the authorization flow. This is especially
We should relax it. Just need someone to propose new language.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Justin Richer
Sent: Tuesday, August 16, 2011 12:49 PM
To: Rob Richards
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] TLS 1.2
(Working group feedback requested at the end)
Moved here to solicit additional feedback from the group.
3.1.2.2. Registration Requirements: Comment on last word path: Huh?
Scheme, authorization and path is a complete URI minus a query
component. Is the goal to specifically mandate that
Moved here to help discuss.
3.1.2.4. Invalid Endpoint: Comment on open redirector: How many people
even know what the heck an open redirector is? I think we need a section in
the security considerations section that defines what an open redirector is
and why it's bad. Alternatively a
Ok.
From: William J. Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, August 16, 2011 3:37 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Open redirector feedback (Yaron Goland)
I like it, but I think using phishing attacks is too limited. I suggest
changing phishing attacks
4.1.2. Authorization Response: Comment The language around scopes in
the document is really frustrating. One only finds out much later in the
document that it is perfectly allowable for an authorization server to more or
less ignore what scopes are submitted and instead to just return
Where would you suggest I add this?
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, July 25, 2011 10:42 AM
To: Eran Hammer-Lahav
Cc: tors...@lodderstedt-online.de; oauth@ietf.org
Subject: Re: [OAUTH-WG] redirect uri validation
Hi
Sending to the list for proper archiving.
EHL
-Original Message-
From: Casey Lucas [mailto:clu...@e-miles.com]
Sent: Wednesday, July 27, 2011 8:05 AM
To: Eran Hammer-Lahav
Subject: FW: couple minor spec issues
Eran,
I tried to send this to the oauth list yesterday but it didn't get
parameter to identify itself when sending
requests to the token endpoint.
EHL
-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 28, 2011 12:11 PM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; oauth
Subject: Re: [OAUTH-WG
How about ‘add’? as in “Used to include additional data in the MAC normalized
string”.
EHL
From: William J. Mills [mailto:wmi...@yahoo-inc.com]
Sent: Thursday, August 04, 2011 6:06 PM
To: Eran Hammer-Lahav; Phil Hunt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] MAC Tokens body hash
It's the proverbial
I'm using my proposed text in -21.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Saturday, August 13, 2011 8:14 AM
To: Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code
On 7/26/11 9:56 AM, Casey Lucas clu...@e-miles.com wrote:
2. Section 6 Refreshing an Access Token seems to conflict with itself
concerning token scope:
The requested scope MUST be equal or lesser than the scope originally
granted by the resource owner, and if omitted is treated as equal
Received via github:
-Original Message-
From: alexbilbie [mailto:reply+i-1402979-
e64eed155dddc31922fd2a2afcf51540a6119...@reply.github.com]
Sent: Sunday, August 14, 2011 5:38 AM
To: Eran Hammer-Lahav
Subject: [draft-ietf-oauth] Removed a repeated sentence in 3.1.2.2 (#1)
Hello
may be exposed to the
resource owner or other applications with access to the resource
owner's user-agent.
Hope this is sufficient.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Sunday, August 14
changes.
EHL
-Original Message-
From: barryleiba.mailing.li...@gmail.com
[mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba
Sent: Monday, August 15, 2011 8:07 AM
To: Anthony Nadalin
Cc: Eran Hammer-Lahav; e...@sled.com; Torsten Lodderstedt; OAuth WG
(oauth@ietf.org
-Original Message-
From: barryleiba.mailing.li...@gmail.com
[mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba
Sent: Monday, August 15, 2011 8:25 AM
To: Eran Hammer-Lahav
Cc: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
information which further reduces the security of the protocol (as the
draft recommends not using dynamic callback query components). Encoding both
CSRF tokens and other state information can be non-intuitive or complicated for
some developers/platforms.
EHL
From: Eran Hammer-Lahav
Sent
...@oracle.commailto:phil.h...@oracle.com
To: Eran Hammer-Lahav
mailto:e...@hueniverse.come...@hueniverse.commailto:e...@hueniverse.com
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org
Sent: Saturday, August 13, 2011 4:41 PM
...@lodderstedt.net
Date: Fri, 12 Aug 2011 23:58:02 -0700
To: Eran Hammer-lahav e...@hueniverse.com
Cc: Anthony Nadalin tony...@microsoft.com, OAuth WG (oauth@ietf.org)
oauth@ietf.org
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav
This is really just a flavor of CSRF attacks. I have no objections to better
documenting it (though I feel the current text is already sufficient), but we
can't realistically expect to identify and close every possible browser-based
attack. A new one is invented every other week.
The problem
Section 1.5 already covers refresh tokens. There are many use cases for refresh
tokens. They are basically a protocol feature used to make scalability and
security more flexible. Anonymity was never part of their design, and by the
nature of this protocol, is more in the domain of the resource
I don't see any below justifying making changes. Comments inline.
From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 09:44:54 -0700
To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
oauth@ietf.orgmailto:oauth@ietf.org
Subject: [OAUTH-WG] Redirection
No objection, but in practice, this isn't very helpful. We can note the general
practical boundaries which will warn the server to accept a minimum size.
EHL
From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 10:34:26 -0700
To: OAuth WG
Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, Dick
Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
oauth@ietf.orgmailto:oauth@ietf.org
Subject: RE: [OAUTH-WG] Refresh Tokens
Anonymity
...@microsoft.commailto:tony...@microsoft.com wrote:
There are no use cases at all in WRAP to help explain choices taken, it does
not matter if there were or were not previous issues raised, it is being raised
now.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 1:46 PM
If you are going to post LC comments, please make sure every comment includes
suggested text. It is too late to raise open ended questions with specific
change proposal. Also, please don't post comments on behalf of others without
proper attribution and making sure they read the note well.
:
I’m raising the issue on the current text, I already provided text if the
original append.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG
rational and this is one way it’s used today with our
scenarios. This needs to be assigned an issue.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 3:39 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG
are not specifying what encryption you have to use here,
and we should not.
From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
To: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
oauth
...@gmail.com
[mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba
Sent: Sunday, August 07, 2011 8:29 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Security area review
Did the chairs issue a last call request to anyone in the security
area? I thought the whole
Did the chairs issue a last call request to anyone in the security area? I
thought the whole point of moving this working group from apps to security was
to increase the review and participation of that area. So far I have seen
absolutely nothing to indicate any such contribution. I would like
Hunt [mailto:phil.h...@oracle.com]
Sent: Monday, August 01, 2011 10:51 PM
To: William J. Mills
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] MAC Tokens body hash
Agree.
-1 on removing the ext parameter.
Phil
@independentid
www.independentid.comhttp://www.independentid.com
phil.h
scheme.
EHL
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Tuesday, August 02, 2011 8:31 AM
To: Eran Hammer-Lahav
Cc: William J. Mills; OAuth WG
Subject: Re: [OAUTH-WG] MAC Tokens body hash
Not sure I understand. How does 'app' change the issue about internal format
and register
no placeholders which will require code change. Considering
this is -00, it is clearly not a stable document.
Will these changes work with your use cases?
EHL
-Original Message-
From: Skylar Woodward [mailto:sky...@kiva.org]
Sent: Tuesday, August 02, 2011 4:02 PM
To: Eran Hammer-Lahav
, August 01, 2011 8:41 AM
To: Eran Hammer-Lahav; OAuth WG
Cc: Ben Adida; 'Adam Barth (a...@adambarth.com)'
Subject: Re: [OAUTH-WG] MAC Tokens body hash
Instead of body hash why not make it a payload hash or additional hash. The
app can include a hash of data there as defined by the app, and you've
Thanks for doing this.
EHL
On Jul 29, 2011, at 12:08, Brian Campbell bcampb...@pingidentity.com wrote:
Following up from
http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html a few
weeks ago, I've submitted a new I-D to establish an IETF URN
Sub-Namespace for OAuth
I plan to drop support for the bodyhash parameter in the next draft based on
bad implementation experience. Even with simple text body, UTF encoding has
introduced significant issues for us. The current draft does not work using
simple JS code between a browser and node.js even when both use
.
On Thu, Jul 28, 2011 at 9:20 AM, Eran
Hammer-Lahave...@hueniverse.commailto: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
...@pingidentity.com
Date: Wed, 27 Jul 2011 04:32:42 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com
Cc: oauth oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
identification
Okay, looking at some of those drafts
...@lodderstedt.net
Date: Wed, 27 Jul 2011 10:38:36 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com
Cc: Brian Campbell
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com, oauth
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] treatment of client_id for authentication
: Torsten Lodderstedt
tors...@lodderstedt.netmailto:tors...@lodderstedt.net
Date: Wed, 27 Jul 2011 11:02:18 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com
Cc: Brian Campbell
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com, oauth
oauth@ietf.orgmailto:oauth@ietf.org
...@pingidentity.com
Cc: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, oauth
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
identification
I personally think that would be more confusing than just adding the
client_id parameter
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
tors...@lodderstedt.netmailto:tors
I believe Google is working on a proposal for an oob URI value to use as the
redirection URI.
EHL
On Jul 26, 2011, at 9:18, Andrew Arnott
andrewarn...@gmail.commailto:andrewarn...@gmail.com wrote:
Trying a different DL...
--
Andrew Arnott
I [may] not agree with what you have to say, but I'll
, at least to me and hence my question, it
wasn't entirely clear how client_id should be used for those cases.
On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav
e...@hueniverse.commailto:e...@hueniverse.com wrote:
The client_id is currently only defined for password authentication on the
token
Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Sunday, July 10, 2011 1:59 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Section 10.1 (Client authentication)
Hi,
I just remembered the original aim of the text. We not just intended to list
alternative means but to get a general message across
user,
possibly compromising data.
This example attack can be mitigated by sanitising the 'state' parameter to
remove or escape HTML
syntax before interpolation of the value into server output to the user agent.
--end--
On 20 July 2011 19:40, Eran Hammer-Lahav
e...@hueniverse.commailto:e
How about confidential/open?
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Friday, July 22, 2011 2:12 PM
To: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] Issue 15, new client registration
Thanks for the feedback.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Wednesday, July 20, 2011 1:59 PM
2.1 Client types
I'm struggeling with the new terminology of private and public
clients. In my
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Wednesday, July 20, 2011 2:15 PM
The authorization server redirects the user-agent to the
client's redirection URI previously established with the
True.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Wednesday, July 20, 2011 2:19 PM
To: OAuth WG
Subject: [OAUTH-WG] Issue 17, new token endpoint Client Authentication
section (3.2.1)
just a minor issue
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Wednesday, July 20, 2011 2:49 PM
To: OAuth WG
Subject: [OAUTH-WG] Comments on -18
section 1.5
(A) The client requests an access token by authenticating with
Draft 19 includes all the feedback received for -18:
* Closes issues 15-19
* Moved client profiles to section 2.1 from 10
* New text for 'Code Injection and Input Validation'
* A few minor editorial clarifications
There are two open issues (20, 21) which are minor editorial requests, and the
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, July 25, 2011 7:24 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Comments on -18
Hi Eran,
section 5.2
The authorization server MAY return an HTTP 401
BTW, I'm planning on following -19 with -20 later today with text closing all
the remaining issues.
EHL
From: Eran Hammer-Lahav
Sent: Monday, July 25, 2011 1:07 AM
To: OAuth WG
Subject: Draft -19
Draft 19 includes all the feedback received for -18:
* Closes issues 15-19
* Moved client
Yeah, I'm not going to waste time trying to keep these in sync for now. This
will all be done once before IETF LC and then with the RFC editor.
EHL
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Monday, July 25, 2011 7:24 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Draft -19
...@civil-tongue.net]
Sent: Monday, July 25, 2011 6:46 AM
To: Peter Saint-Andre
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Draft -19
On Mon, 25 Jul 2011, Peter Saint-Andre wrote:
On 7/25/11 4:06 AM, Eran Hammer-Lahav wrote:
Draft 19 includes all the feedback received
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, July 25, 2011 7:19 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2)
Hi Eran,
Am 25.07.2011 03:28, schrieb Eran Hammer
I'll switch to confidential/public.
EHL
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Monday, July 25, 2011 7:41 AM
To: Eran Hammer-Lahav
Cc: e...@sled.com; Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] Issue 15, new client registration
I would
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
9:28 AM
To: Eran Hammer-Lahav
Cc: oauth
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
identification
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
There is nothing wrong with the examples.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Monday, July 25, 2011 9:28 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Extra Authorization: Basic lines in examples
In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft
-Original Message-
From: tors...@lodderstedt-online.de [mailto:torsten@lodderstedt-
online.de]
Sent: Sunday, July 24, 2011 12:36 AM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: redirect uri validation (was: Issue 15, new client registration)
Hi Eran,
let's move
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Wednesday, July 20, 2011 1:59 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Issue 15, new client registration
2.1 Client types
I'm struggeling with the new
(in either order, fragment-encoded response)
response_type=code token id_token (in any possible order, fragment-encoded
response)
We already have support for response_type=none and the signed_request one
is a few weeks out.
Paul
On 7/12/11 1:35 PM, Eran Hammer-Lahav
e...@hueniverse.commailto:e
for a client
application to turn into a vulnerability. It provides plenty of uniqueness
(it can
fit a sha512) for even the largest and most used client applications.
-Bob
On Wed, Jul 20, 2011 at 8:24 AM, Breno breno.demedei...@gmail.com
wrote:
On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer
Looks like we have consensus for the new text. I'd like to ask the chairs to
close issue 18 (or note it resolved until the I-D freeze is over and I can push
a revised draft).
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer
Take a look at how the other sections in the draft setup the premise first and
give a quick explanation of the attack...
EHL
From: Aiden Bell [mailto:aiden...@gmail.com]
Sent: Wednesday, July 20, 2011 11:38 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] OAuth v2-18 comment on state
I have tried to accommodate both the use cases and concerns raised. The new
text allows the registration of composite response types in which the order of
the space-delimited values does not matter. However, every combination must be
registered in order to avoid developers guessing what an
I would like to ask the chairs to close the following issues:
#15 section 2
#16 section 3.1.2
#17 section 3.2.1
I have posted a new proposal for #18 section 8.4 for the WG to consider in
order to close the issue.
EHL
___
OAuth mailing list
can be used
There are no other implied requirements. You don't need to register the parts
individually, only the combination.
EHL
From: Aiden Bell [mailto:aiden...@gmail.com]
Sent: Tuesday, July 19, 2011 4:39 AM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed change
Revised text. I changed it to focus on the implementation details.
In other words, all response types must be registered. If the type name
includes spaces, it changes how the value is compared (space-delimited list of
values where the order does not matter). That's it. Spaces only change how
Issue 18 did raise some comments. The feedback was that the parameter value
should be changed from a simple string to a space-delimited list of values. 5
people expressed support with 2 (myself included) expressed concern about this
change. I would be great if others would take 10 minutes to
I don't see the problem. The state value is percent-encoded both ways, so the
only way to inject a bad value there is by including a value that has special
meaning to the client. Putting a character limit on it will not do anything to
prevent that.
The server should reject requests with query
You can't have it both way. Either it is a simple string comparison or it
requires parsing of the string. The current prose is designed to offer a visual
cue without making any code changes to how response types are compared. To
allow different orders, we have to turn the value to a parsed
I think we can remove that line. The refresh token represents the original
authorization and the server an decide when it is still valid.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Zeltsan, Zachary (Zachary)
Sent: Wednesday, July
, IMNSHO. What is the
rationale to fear allowing multiple-valued response_type as we have for
other parameters in the spec?
On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav e...@hueniverse.com
wrote:
As for the plus encoding we can choose another char or give an example.
On Jul 11, 2011
: Breno de Medeiros [mailto:br...@google.com]
Sent: Tuesday, July 12, 2011 11:18 AM
To: Eran Hammer-Lahav
Cc: Marius Scurtescu; OAuth WG
Subject: Re: [OAUTH-WG] defining new response types
On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav e...@hueniverse.com
wrote:
Requiring parsing
-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Breno de Medeiros
Sent: Tuesday, July 12, 2011 11:48 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] defining new response types
On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav e...@hueniverse.com
wrote
Any cookie? What about a Secure cookie limited to a specific sub-domain? What
are the concerns about cookies? I think this would be helpful to discuss.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Marius Scurtescu
Sent: Monday,
You are over complicating it. You can define anything you want. But if you want
to use the special + character, each of the parts must be defined and
registered. If parts of a combination don't make sense on their own use
something else to join them like underscore.
EHL
On Jul 11, 2011, at
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Sunday, July 10, 2011 2:17 AM
Eran Hammer-Lahav e...@hueniverse.com schrieb:
The security of the protocol relies fully (implicit grant) or partially
(authorization code) on the validation
We probably need some help from the chairs to close 15-18. Maybe make an
official request for feedback with a deadline?
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Barry Leiba
Sent: Saturday, July 09, 2011 6:22 AM
To: OAuth WG
Sounds reasonable. Can you provide a schedule outline?
EHL
-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Saturday, July 09, 2011 5:53 AM
To: Eran Hammer-Lahav
Cc: oauth
Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 1: client auth
The OAuth WG is looking for assistance from the application area community.
OAuth 2.0 [1] defines a URI-namespaced method for defining extension grant
types[2]. The first specification to use this method needs to pick a URI
identifier for using SAML assertions [3]. Options proposed:
201 - 300 of 1089 matches
Mail list logo
