-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Saturday, July 09, 2011 6:15 AM
To: Eran Hammer-Lahav
Cc: oauth
Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)]
Discussion on the other item, the grant_type URI, inline below
(- apps-discuss)
I don't have the bandwidth to do anything other than edit the v2 document.
Sorry.
EHL
-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Saturday, July 09, 2011 12:28 PM
To: Hannes Tschofenig
Cc: Eran Hammer-Lahav; OAuth WG; apps
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 Shane Weaden) and adding state in
dynamic redirect-uri
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 confidential
information or taking control of their computer while
]].
EHL
-Original Message-
From: Eran Hammer-Lahav
Sent: Thursday, July 07, 2011 1:01 AM
To: OAuth WG
Subject: RE: Timely review request: pre-draft-17
I finished the major part of -17, adding a new Client registration section and
folding client authentication into it. This new text
]
Sent: Friday, July 08, 2011 12:59 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Section 10.1 (Client authentication)
seems you are contradicting yourself.
You criticised the MUST and suggested to include some examples. I bought
into your argument and suggested to refer to the security
, 2011 1:23 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: [OAUTH-WG] state parameter and XSRF detection
Hi Eran,
including dynamic values within redirect uris is standard practice today and is
allowed by the spec's text so far. I don't mind to change it but the restricted
behavior you prefer
Authorization codes MUST be kept confidential
How exactly? They are not confidential by nature, being received via
redirection in the URI query. I know what this sentence is trying to accomplish
but not sure how to do that with normative language. SHOULD doesn't really work
here either.
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Authorization code security considerations
On Fri, Jul 8, 2011 at 11:39 AM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
How exactly? They are not confidential by nature, being received via
redirection in the URI query. I know what
Author(s) : Eran Hammer-Lahav
David Recordon
Dick Hardt
Filename: draft-ietf-oauth-v2-17.txt
Pages : 62
Date: 2011-07-08
The OAuth 2.0 authorization protocol enables a third
Published draft-ietf-oauth-v2-18.
This was a much larger effort than I was previously expecting or planning.
Review requires reading the full text as the number of changes makes using a
diff tool impractical. Below is the mostly complete list of changes. The new
draft should include very few
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Wednesday, July 06, 2011 10:20 PM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement
Very helpful.
EHL
From: Brian Eaton [mailto:bea...@google.com]mailto:[mailto:bea
it to the chairs to
decide if they still want to initiate WGLC or give the draft a few days of
informal review.
EHL
-Original Message-
From: Eran Hammer-Lahav
Sent: Monday, July 04, 2011 10:09 PM
To: OAuth WG
Subject: Timely review request: pre-draft-17
I have started sharing my
Allowing any flexibly in the redirection URI is a bad thing and the latest
draft (pre -17) clearly states that. The main fear is that by allowing the
query to be changed dynamically, attackers can find open redirector loopholes
to abuse. I really wanted to make registration of the absolute URI
That's not the point. Developers who are going to self-encode tokens don't need
the examples.
EHL
From: George Fletcher [mailto:gffle...@aol.com]
Sent: Thursday, July 07, 2011 6:35 AM
To: William J. Mills
Cc: Eran Hammer-Lahav; Brian Campbell; Oleg Gryb; OAuth WG
Subject: Re: [OAUTH-WG] Example
Looking back at the archives, I didn't find any replies to this proposal.
Torsten / Mark / Phil - is this a change you would like me to make?
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Brian Eaton
Sent: Sunday, May 22, 2011 8:47
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Peter Saint-Andre
Sent: Wednesday, June 01, 2011 11:43 AM
Throughout the document, the various parameters (e.g., client_secret and
client_id) are essentially undefined. There is no text
What is ‘monitoring http headers’?
EHL
From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
oauth@ietf.orgmailto:oauth@ietf.org
Sent: Tuesday, June 28, 2011 6:15 PM
Subject: [OAUTH-WG] Native
I still don’t find it useful. I think the existing text overall makes this
point already.
EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, July 06, 2011 12:48 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: Section 10.1 (Client authentication)
Hi Eran,
I would
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Brian Campbell
Sent: Thursday, July 07, 2011 12:06 PM
To: oauth
Subject: [OAUTH-WG] SAML Assertion Draft Items
WG,
Unfortunately I will not be at IETF#81 and will probably not be able
Are the tokens used in the examples long enough? I don't want the examples to
demonstrate poor choice of byte count.
EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
These are all good ways to mitigate the issue, but they don't solve it. If you
are running third-party scripts on the redirection URI page, all bets are off
as to who is going to end up with the access token, authorization code, etc. It
is pretty bad security to run any kind of third party code
What triggers this flow? If you are using the authorization endpoint with a
different response_type, it would be helpful if you shared that with the wg as
currently, that's simply not allowed (the values are not extensible). I am
going to change that in -17, but based on the requirement
Does that apply to access tokens, refresh tokens, and authorization codes? I
can try squeezing in 22 characters.
EHL
-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Wednesday, July 06, 2011 8:46 PM
To: Oleg Gryb
Cc: Eran Hammer-Lahav; OAuth WG
Fantastic!
From: Manger, James H [mailto:james.h.man...@team.telstra.com]
Sent: Wednesday, July 06, 2011 9:11 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Example tokens
Are the tokens used in the examples long enough? I don't want the examples to
demonstrate poor choice of byte count
Section 3:
In addition, the authorization server MAY allow unauthenticated
access token requests when the client identity does not matter (e.g.
anonymous client) or when the client identity is established via
other means. For readability purposes only, this specification is
In light of the new assertion draft, do we still want to make this change?
EHL
From: Brian Campbell
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com
Date: Tue, 24 May 2011 07:25:12 -0700
To: oauth oauth@ietf.orgmailto:oauth@ietf.org
Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me)
What about the example using SAML assertion?
From: Brian Campbell
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com
Date: Mon, 4 Jul 2011 11:42:21 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com
Cc: oauth oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH
:37 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, OAuth
WG oauth@ietf.orgmailto:oauth@ietf.org
Subject: Section 10.1 (Client authentication)
Hi Eran,
would you please add the following sentence (which was contained in the
original security considerations text
This needs to be reworked to reflect reality. The state value must be shared
with the resource owner's browser and authorization server, so it is not really
a secret known only to the client…
EHL
From: Mark Mcgloin mark.mcgl...@ie.ibm.commailto:mark.mcgl...@ie.ibm.com
Date: Wed, 1 Jun 2011
Date: Mon, 4 Jul 2011 09:16:28 -0700
To: OAuth WG oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] draft 16 review notes
On Sun, Jul 3, 2011 at 11:21 PM, Eran Hammer-Lahav
e...@hueniverse.commailto:e...@hueniverse.com wrote:
Need proposed text.
...
Need proposed text.
...
Need proposed
I have started sharing my planned changes for 17:
https://github.com/hueniverse/draft-ietf-oauth
Change log:
https://github.com/hueniverse/draft-ietf-oauth/commit/24a48f99c204331264028
f66708427961a1bc102#diff-3
My main focus right now is to clarify client types, registration, and
...@gmx.netmailto:hannes.tschofe...@gmx.net,
i...@ietf.orgmailto:i...@ietf.org IETF
i...@ietf.orgmailto:i...@ietf.org, Eran Hammer-lahav
e...@hueniverse.commailto:e...@hueniverse.com, oauth WG
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: Second Last Call: draft-hammer-hostmeta-16.txt (Web
...@au1.ibm.commailto:swee...@au1.ibm.com
Date: Sun, 3 Jul 2011 21:22:46 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com
Cc: Brian Eaton bea...@google.commailto:bea...@google.com,
oauth@ietf.orgmailto:oauth@ietf.org
oauth@ietf.orgmailto:oauth@ietf.org,
oauth-boun
Issuing a refresh token is more a function of the access grant duration than
anything else. The client can always throw away tokens when it is done of if
the user doesn't want to stay connected, but issuing long term credentials is
not really something the client asks but the server decides
AM
To: Eran Hammer-Lahav; George Fletcher; oauth@ietf.org
Subject: AW: [OAUTH-WG] Resource Owner Password Credentials question/feedback
Issuing a refresh token is more a function of the access grant duration than
anything else.
Agreed. How shall the user influence this duration? There is no direct
Yep. Invalid grant is the right error code.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Brian Campbell
Sent: Tuesday, June 28, 2011 9:05 AM
To: George Fletcher
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Resource Owner Password
oauth.net needs some love but I don't have the time. If anyone is interested in
working on it, please contact me and I'll get you setup.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eve Maler
Sent: Friday, June 24, 2011 10:02 AM
Libraries are no cure for stupidity.
On the client side, you make two simple HTTP requests. The facilities to make
these requests should be available and easy to use. Parsing JSON responses
should be part of any modern web platform. The part that might need more work
is handling of refresh
I maintain the node.js 'mac' module:
https://github.com/hueniverse/node-mac
or 'npm install mac'
A browser JS lib is available at:
https://sled.com/scripts/mac.js
Both are used in production.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
-Original Message-
From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Thursday, June 16, 2011 1:26 AM
To: Eran Hammer-Lahav; Mike Jones; David Recordon; George Fletcher
Cc: paul Tarjan; oauth@ietf.org
Subject: AW: [OAUTH-WG] consistency of token param name in bearer
Nope. OAuth is a secondary goal of the MAC scheme and calling it access_token
there would make no sense for anything but OAuth.
EHL
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, June 16, 2011 7:01 AM
To: KIHARA, Boku
Cc: Eran Hammer-Lahav; oauth
Easier said than done. If you don't have strong trust, giving the user hints
will cause more harm than good.
EHL
From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Thursday, June 16, 2011 1:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: AW
I think we want the same thing and I can adjust my proposal to align with your
comments below. I'll post in a separate thread.
EHL
From: Brian Eaton [mailto:bea...@google.com]
Sent: Thursday, June 16, 2011 9:19 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Redirection URI
and scary pages are useless.
EHL
From: Zeltsan, Zachary (Zachary) [mailto:zachary.zelt...@alcatel-lucent.com]
Sent: Thursday, June 16, 2011 10:35 AM
To: 'Lodderstedt, Torsten'; Eran Hammer-Lahav; 'Torsten Lodderstedt'; 'Brian
Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth
.
If you have a client identifier without secret (via the authentication code) or
registered callback, that client identifier is useless and must not be used.
EHL
From: tors...@lodderstedt.net [mailto:tors...@lodderstedt.net]
Sent: Thursday, June 16, 2011 11:24 AM
To: Eran Hammer-Lahav; Lodderstedt
identifier, they will
not go far without the secret, and the user data will remain safe.
EHL
From: Zeltsan, Zachary (Zachary) [mailto:zachary.zelt...@alcatel-lucent.com]
Sent: Thursday, June 16, 2011 12:51 PM
To: Eran Hammer-Lahav; 'Lodderstedt, Torsten'; 'Torsten Lodderstedt'; 'Brian
Eaton'
Cc
I'm standing behind my 99.99% projection for the next 5 years.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Thursday, June 16, 2011 9:04 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] issuing multiple tokens
[Issuing multiple tokens] is not an
yet to see any such text
gaining consensus.
My suggestion is to drop this attempt, but if a new text gain consensus, I'll
incorporate it.
EHL
From: Anthony Nadalin [mailto:tony...@microsoft.com]
Sent: Wednesday, June 15, 2011 10:10 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
: Wednesday, June 15, 2011 10:24 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps
Not seeing what you write about below, I think that the basic text that was
discussed at the F2F has consensus around the guidance (with some changes that
were
It should be pretty easy :-)
Anyone objects to changing the parameter name from 'bearer_token' to
'access_token'? Let Mike know by 6/20 or he will make the change.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Mike Jones
Sent:
: Brian Eaton [mailto:bea...@google.com]
Sent: Wednesday, June 15, 2011 11:33 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Refresh tokens
On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav
e...@hueniverse.commailto:e...@hueniverse.com wrote:
I would like to add a quick discussion
I agree to the extent that the user can be trusted to know how they got to the
authorization endpoint.
If the client cannot be authenticated, the authorization server is limited in
the information it can offer the user to make the decision. It is extremely
hard to come up with language that
This is coming from recent experience building a full web service and multiple
clients using OAuth 2.0. I am going to make these changes to my own
implementation and would like to raise the questions here and discuss possible
changes.
A few questions:
1. Why not require the registration of a
to developers who are not security experts to make
the right decisions, and that includes me.
Yes, some use cases will suffer, but that's just what standards are about.
EHL
From: Kris Selden [mailto:kris.sel...@gmail.com]
Sent: Wednesday, June 15, 2011 12:21 PM
To: Eran Hammer-Lahav
Cc: Brian
from being allowed to use this flow, but
at the same time, the most likely clients to use this grant type are those who
cannot authentication (native applications).
This is goo.
EHL
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Wednesday, June 15, 2011 11:47 AM
To: Eran Hammer
-Original Message-
From: Brian Eaton [mailto:bea...@google.com]
Sent: Wednesday, June 15, 2011 1:53 PM
But I have no idea why we need client authentication for using a refresh
token?
This is covered here: http://www.ietf.org/mail-
archive/web/oauth/current/msg06362.html.
So
?
EHL
From: Brian Eaton [mailto:bea...@google.com]
Sent: Wednesday, June 15, 2011 5:33 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement
On Wed, Jun 15, 2011 at 5:27 PM, Eran Hammer-Lahav
e...@hueniverse.commailto:e...@hueniverse.com
-Original Message-
From: Shane B Weeden [mailto:swee...@au1.ibm.com]
Sent: Wednesday, June 15, 2011 3:19 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
From: Eran Hammer-Lahav e...@hueniverse.com
To: OAuth WG oauth@ietf.org
? Or that 30 days is a
reasonable time period for ignoring an attack?
EHL
From: Brian Eaton [mailto:bea...@google.com]
Sent: Wednesday, June 15, 2011 6:15 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement
On Wed, Jun 15, 2011 at 6:02 PM
...@team.telstra.com]
Sent: Wednesday, June 15, 2011 7:37 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Redirection URI and Implicit grant
It seems like an authorization server receiving a request with an unregistered
redirect_uri of https://example.org/ can tell the user:
Permission will be passed to your
To: OAuth WG
Subject: [OAUTH-WG] issuing multiple tokens
Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg said +1 to
that; John Bradley identified that OpenID Connect needs to request multiple
tokens; Eran Hammer-Lahav even mentioned a no-token flow as something
that could make
identified that OpenID Connect needs to request
multiple tokens; Eran Hammer-Lahav even mentioned a no-token flow as
something that could make sense; ...
Issuing 0, 1 or more tokens looks like an important enough feature to fix
now, instead of trying to hack it in after the spec is finalised
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Adam Barth
Sent: Tuesday, June 14, 2011 10:05 AM
To: Manger, James H
Cc: oauth
Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
On Tue, Jun 14, 2011 at 7:25 AM,
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Manger, James H
Sent: Tuesday, June 14, 2011 7:06 PM
To: oauth
Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
Perhaps omitting the id parameter from the
This whole cookie thing is a 'a bit hacky'... that's part of what we're working
with... :-)
EHL
-Original Message-
From: Manger, James H [mailto:james.h.man...@team.telstra.com]
Sent: Tuesday, June 14, 2011 10:39 PM
To: Eran Hammer-Lahav; oauth
Subject: RE: [OAUTH-WG] FW: MAC
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Manger, James H
Sent: Monday, June 13, 2011 6:11 PM
There have been suggestions that the MAC calculation could/should cover
the key id. In that situation it is even more crucial that the
Don't care. Will never use it. :-)
EHL
-Original Message-
From: David Recordon [mailto:record...@gmail.com]
Sent: Friday, June 10, 2011 1:20 AM
To: George Fletcher; Eran Hammer-Lahav; Doug Tangren
Cc: Mike Jones; paul Tarjan; oauth@ietf.org; Marius Scurtescu
Subject: Re: [OAUTH-WG
-Original Message-
From: Robert Sayre [mailto:say...@gmail.com]
Sent: Friday, June 10, 2011 11:37 AM
To: Adam Barth
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: Why not use a server-supplied nonce (was: HTTP MAC
Authentication Scheme)
On Fri, Jun 10, 2011 at 10:51 AM, Adam
-Original Message-
From: Tim [mailto:tim-proje...@sentinelchicken.org]
Sent: Wednesday, June 08, 2011 8:32 AM
At risk of repeating myself: Why not just adapt HTTP Digest for OAuth?
That is not just rhetorical, it is a genuine question. What is HTTP Digest
missing that you need?
The last part, refresh token, is with the authorization server, not resource
server.
EHL
From: denadai2 [mailto:denad...@gmail.com]
Sent: Wednesday, June 08, 2011 1:27 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand
Perfect
-Original Message-
From: Mark Nottingham [mailto:m...@mnot.net]
Sent: Wednesday, June 01, 2011 5:16 PM
To: Eran Hammer-Lahav
Cc: apps-disc...@ietf.org; Ben Adida; http-st...@ietf.org; OAuth WG;
'Adam Barth (a...@adambarth.com)'; HTTP Working Group
Subject: Re: [apps-discuss] HTTP
-Original Message-
From: Skylar Woodward [mailto:sky...@kiva.org]
Sent: Tuesday, May 31, 2011 10:54 PM
Unfortunately though, this implementation doesn't help my use cases
because such sequential requirement of a timestamp/age requires all
devices with the token to be in sync as to
-Original Message-
From: Skylar Woodward [mailto:sky...@kiva.org]
Sent: Tuesday, May 31, 2011 11:03 PM
To: Eran Hammer-Lahav
Cc: igor.faynb...@alcatel-lucent.com; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Eran, sorry, where should use cases
-Original Message-
From: Skylar Woodward [mailto:sky...@kiva.org]
Sent: Wednesday, June 01, 2011 12:16 AM
To: Eran Hammer-Lahav
Cc: Adam Barth; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Provider: api.megaworld.com
Software Program
of a concern. If for some
reason you are not using TLS alongside client authentication for obtaining an
access token, this particular use case becomes out of scope.
EHL
-Original Message-
From: Skylar Woodward [mailto:sky...@kiva.org]
Sent: Wednesday, June 01, 2011 1:06 AM
To: Eran Hammer
AM
To: Adam Barth
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
It seems we're failing to communicate. Or you're not understanding my use
cases. Age doesn't just work. It only works for a limited number of uses
cases that must include
... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -.. - ... -.-
-.-- .-.. .- .-. - .-
- --- --- -.. .-- .- .-. -..
skylar woodward
Kiva Developer Program / build.kiva.org / @buildkiva
On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
Any kind of clock sync requirement for user-agents (basically,
home desktops) it completely impractical. The added complexity pales
/ @buildkiva
On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
Any kind of clock sync requirement for user-agents (basically,
home desktops) it completely impractical. The added complexity pales in
comparison to the difficulty of trying to use timestamps and any kind of clock
sync
just think this
isn't worth the effort in a formal document.
EHL
-Original Message-
From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Tuesday, May 31, 2011 6:15 PM
To: Eran Hammer-Lahav
Cc: Phil Hunt; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: issues with token age
schemes are by definition complex and right now MAC is amazingly
simple.
EHL
-Original Message-
From: Skylar Woodward [mailto:sky...@kiva.org]
Sent: Tuesday, May 31, 2011 10:14 PM
To: Eran Hammer-Lahav
Cc: igor.faynb...@alcatel-lucent.com; Phil Hunt; OAuth WG
Subject: Re: [OAUTH-WG
We can add it as an example. Instead of 'Commonly', 'For example, using'.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of David Recordon
Sent: Saturday, May 28, 2011 9:41 AM
To: OAuth WG
Cc: paul Tarjan
Subject: [OAUTH-WG]
This applies to 4.1.1 and 4.2.1 only. It must be required in 4.1.3 is must
match the location actually used by the server to deliver the code to
(regardless of whether the redirection uri was registered or included
explicitly with the request).
EHL
From: oauth-boun...@ietf.org
forwarded message:
From: Skylar Woodward sky...@larw.com
Date: May 23, 2011 6:14:00 PM PDT
To: Skylar Woodward sky...@kiva.org
Cc: Eran Hammer-Lahav e...@hueniverse.com, OAuth WG
oauth@ietf.org
Subject: Re: [OAUTH-WG] issues with token age element - MAC token
So after discussing
That's never going to be complete and will be out of date before the RFC is
out. Another example is a good idea.
EHL
On May 26, 2011, at 10:10, Igor Faynberg igor.faynb...@alcatel-lucent.com
wrote:
Actually, I would go even further: Provide a list of different ways of
redirecting and
We are taking multiple paths trying to find the best balance.
There is an effort to draft a new document describing client authentication
using assertions. That effort seems to expand to encompass all assertion
related business. I'm supportive of that approach. This document may or may not
All section 3 says is that you cannot use it alone for authentication. You can
use it alone, but it is not considered authentication and the client identity
is nothing more than a hint without other information you can validate.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
You need to be more specific about what is confusing you. V2-16 7.1 is just an
example. For using MAC you need to refer to the MAC spec.
How you generate your access token string is an internal detail but your use of
the authorization code in the algorithm is odd, IMO.
The MAC is calculated
From: denadai2 denad...@gmail.commailto:denad...@gmail.com
Date: Sun, 22 May 2011 08:27:41 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com
Cc: oauth@ietf.orgmailto:oauth@ietf.org
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft
-Original Message-
From: Nico Williams [mailto:n...@cryptonector.com]
Sent: Friday, May 20, 2011 1:25 PM
To: Eran Hammer-Lahav
Cc: apps-disc...@ietf.org; Ben Adida; http-st...@ietf.org; OAuth WG; Adam
Barth (a...@adambarth.com); HTTP Working Group
Subject: Re: [apps-discuss] HTTP
I'm dropping it from MAC.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Andrew Wooster
Sent: Friday, May 20, 2011 8:42 PM
To: Julian Reschke
Cc: Kris Selden; OAuth WG
Subject: Re: [OAUTH-WG] Language encoding in error_description
The error_description parameter and similar parameters in the MAC and Bearer
specs do not specify the language or encoding used. This is a problem. Can
someone offer a solution?
EHL
___
OAuth mailing list
OAuth@ietf.org
-Original Message-
From: Peter Wolanin [mailto:peter.wola...@acquia.com]
Sent: Wednesday, May 04, 2011 8:54 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: OAuth v2 Mac token spec
Can you give an example of a setup where the hash cannot be calculated?
Large file upload
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)
-
I forgot to mention (the obvious) that the chairs will follow up on each open
issue with their own notes and will do the actual determination with regard to
closing issues.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Wednesday, May 18
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,
: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] unauthenticated token requests
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
The client_id is required. client_secret is not.
EHL
On May 13, 2011, at 16:00, Vlad Skvortsov v...@aboutecho.com wrote:
Hi,
a have a question regarding unauthenticated requests to a token endpoint
in OAuth 2.0. The spec v2-15 section 3 says[1] that the authorization
server MAY allow
This is an official interim working group meeting which goes by all the normal
IETF rules of such meetings and is open for all.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Doug
Tangren
Sent: Tuesday, May 10, 2011 11:38 PM
To: Barry Leiba
Cc: OAuth WG
Subject:
The name needs to be unique enough not to conflict with likely parameters
already used by providers. I don’t have an opinion which name is better, just
that it was oauth_token before and when we changed the scheme name to Bearer,
changed it too.
EHL
From: oauth-boun...@ietf.org
301 - 400 of 1089 matches
Mail list logo
