-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Peter Saint-Andre
Sent: Wednesday, March 23, 2011 2:27 PM
1. I think it would help in the Introduction to state specifically that this
protocol is designed for use on the web and with HTTP
...@proofpoint.com]
Sent: Thursday, March 24, 2011 4:43 PM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: draft-ietf-oauth-v2-13 comments
3. I believe that section 5.2 is ambiguous as to the error code that
should be returned from the token endpoint when the client
credentials are valid
https://github.com/hueniverse/draft-ietf-oauth/raw/master/draft-ietf-oauth-v2.txt
This includes all the feedback received until now. My queue is now empty except
for the need to propose a new error code extensibility solution to accommodate
the needs of protocol extensions.
I replied back to
It's a safe language to align it with common assumptions. Also, in the case of
URI values, they are usually case insensitive.
EHL
-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Friday, March 25, 2011 8:00 AM
To: Eran Hammer-Lahav
Cc: Mike Jones
-Original Message-
From: Freeman, Tim [mailto:tim.free...@hp.com]
Sent: Friday, March 25, 2011 11:48 AM
Tim:
Section 2.1.1 says If a redirection URI was registered, the
authorization server MUST compare any redirection URI received at the
authorization endpoint with the
Unless someone has an objection, I'll make the change from SHOULD to MUST.
EHL
-Original Message-
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Friday, March 25, 2011 12:42 PM
To: Eran Hammer-Lahav
Cc: OAuth WG; Chuck Mara Mortimore
Subject: Re: [OAUTH-WG] WGLC on draft-ietf
Coming right after IETF-80 in -15.
EHL
From: Freeman, Tim [mailto:tim.free...@hp.com]
Sent: Friday, March 25, 2011 5:16 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: What's up with the secuity considerations? (was RE: Preview of -14)
What's the plan for filling in the security considerations
You should probably go read RFC 2616 again...
EHL
-Original Message-
From: Anthony Nadalin [mailto:tony...@microsoft.com]
Sent: Thursday, March 24, 2011 2:15 PM
To: Eran Hammer-Lahav; Phil Hunt; Manger, James H
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] Apparent consensus on OAuth
Removed.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Wednesday, February 16, 2011 11:03 AM
To: OAuth WG
Subject: [OAUTH-WG] -13 4.3.2: internationalization consideration for username
and password
Unless someone provides a proposed text
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Phil Hunt
Sent: Monday, February 21, 2011 4:49 PM
To: OAuth WG
Subject: [OAUTH-WG] Draft13: What are the possible OAuth related access
errors for section 7?
When accessing a protected
Was there any conclusion?
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Thursday, February 24, 2011 4:09 PM
To: OAuth Mailing List; web...@ietf.org
Subject: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF
Q. Should an
I have started processing all the incoming feedback (expect responses to each
note received). If you have additional feedback, I suggest it waits for the
next draft (-14). However, if it is a blocking comment, please post to the list
as soon as possible.
EHL
-Original Message-
From:
Done.
Also removed ' and the authentication of the client is based on the
user-agent's same-origin policy'.
EHL
-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Wednesday, March 02, 2011 6:05 AM
To: Eran Hammer-Lahav
Cc: Marius Scurtescu; OAuth WG
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Mark Kent
Sent: Sunday, March 06, 2011 1:19 PM
1. The error response mechanism for the authorization endpoint depends on
the response_type being requested. Assuming that the client and
This line was left over from an earlier draft. It's now removed. It may
reappear in the security considerations section.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Craig Heath
Sent: Thursday, March 10, 2011 10:33 AM
To:
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Sunday, March 13, 2011 3:51 PM
section 1.4: An authorization grant is a general term used to describe the
intermediate credentials ...
Since passwords represent
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Chuck Mortimore
Sent: Monday, March 14, 2011 6:10 PM
1) I'd vote for dropping the following from 1.4.2. In turn I'd discuss some
of
the security considerations, such as difficulty of
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Mike Jones
Sent: Tuesday, March 15, 2011 7:52 AM
2.1.1: If no valid redirection URI is available, the authorization server
SHOULD - I don't understand why this is a SHOULD and not a MUST
-Original Message-
From: Chuck Mortimore [mailto:cmortim...@salesforce.com]
Sent: Thursday, March 24, 2011 7:22 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
On Mar 24, 2011, at 6:36 PM, Eran Hammer-Lahav e...@hueniverse.com
-Original Message-
From: Anthony Nadalin [mailto:tony...@microsoft.com]
Sent: Wednesday, March 23, 2011 3:11 PM
I don't believe that there is anything wrong in combining into a single
registry, as this has been done in other specifications.
There are very different endpoints with
: Tuesday, March 22, 2011 9:45 AM
To: Eran Hammer-Lahav
Cc: Manger, James H; oauth@ietf.org
Subject: Re: [OAUTH-WG] Apparent consensus on OAuth Errors Registry
Eran,
Thanks. Thats the best summary of the problem and I think it will help move the
discussion forward (finally).
Issue 1:
Since only one
but is not an OAuth extension. OAuth extensions are
specifications directly affecting the process of obtaining tokens, not using
tokens.
EHL
From: Anthony Nadalin [mailto:tony...@microsoft.com]
Sent: Tuesday, March 22, 2011 2:32 PM
To: Eran Hammer-Lahav; Phil Hunt; Manger, James H
Cc: oauth@ietf.org
Subject
Nadalin
For D or C:
Eran Hammer-Lahav
William Mills
Given that twice as many people indicated a preference for A as for any other
option, that seems to indicate a consensus for A. Therefore Eran, when you
update your draft, can you please proceed on that basis
-21, at 9:48 AM, Mike Jones wrote:
People voted as follows in the poll I conducted on the OAuth Errors Registry:
For A:
Mike Jones
Igor Faynberg
Justin Richter
Anthony Nadalin
For D or C:
Eran Hammer-Lahav
We had last calls for v2 and bearer. This is for the SAML profile.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Mike Jones
Sent: Saturday, March 19, 2011 11:04 AM
To: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG]
To: Eran Hammer-Lahav; Hannes Tschofenig; oauth@ietf.org
Subject: RE: [OAUTH-WG] Agenda Proposal
I think it does for example how one might discover the authorization service
and this would be a forum to see if others also do or not.
-Original Message-
From: Eran Hammer-Lahav
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Justin Richer
Mutual cross-reference between the MAC and Bearer specs might help
people trying to decide what kind of OAuth token to use.
Speaking for MAC - over my dead body :-)
EHL
OAuth 2 intentionally dropped the use of client credentials when making
protected resource requests. This seems to be your main issue.
If you are going to use MAC tokens, one easy solution is to tell your
developers to simply concatenate the client secret with the token secret when
signing the
for such requirements)?
EHL
Cheers,
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Monday, March 14, 2011 6:30 PM
To: David Recordon
Cc: oauth@ietf.org
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Tuesday, March 15, 2011 2:38 PM
Having a standard set of oauth errors on the protected
resource is a good idea. That said:
Not practical. Given the wide range of token types and schemes, each will have
to
2 more days. Please reserve some time to read the entire document and provide
detailed feedback.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Hannes Tschofenig
Sent: Tuesday, March 01, 2011 11:32 PM
To: OAuth WG
Subject:
It's a clear example of defining facilities without *ANY* use cases or
requirements.
We have clear use cases and actual registration requests for the current
registries defined in v2.
What's most annoying about this entire push for an error registry is that the
author and supporters have all
indicated earlier, I don't agree yet with the choices and would like more
information on the registry and use cases.
Phil
phil.h...@oracle.com
On 2011-03-14, at 6:29 PM, Eran Hammer-Lahav wrote:
It's a clear example of defining facilities without *ANY* use cases or
requirements
Decisions are never made outside the list.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Phillip Hunt
Sent: Friday, March 11, 2011 10:19 PM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Vote: Location of OAuth
D (not objection to C).
So far, not a single use case or technical rational has been presented to
justify option A.
Option B is not a valid option per IETF process (for option B to be valid, the
protocol spec must first be published as an RFC, and they the bearer token spec
updates it).
This
There are a few issues to consider.
1. Should the spec support sending bearer token in a query parameter?
- The argument that there are many use cases for this is unproven. JSON-P is
one valid example (though JSON-P usage is in decline with new methods for
cross-domain calls), but so far the
I hope this will be the last time we define a query parameter for delivering
what should be sent via a request header field. Infringing on a service's
namespace is always a bad idea, no matter what prefix we put next to it.
EHL
From: William J. Mills
, but this working group
has had no problems putting all kinds of parameters into that space.
Unless we want to say that we can't use query or form parameters in
specifications ever again, this argument doesn't really hold up.
-- Justin
From: Eran Hammer-Lahav [e
words is a small change but one that I feel
would be beneficial on a number of fronts.
Thanks,
Brian
[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2
On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-
Lahave...@hueniverse.com wrote:
Feel free to propose alternative
the
security purpose of the Temporary Credentials shared secret? If an
implementation were to, say, always use an empty string, would it make any
difference to the security of the protocol?
- Craig.
-Original Message-
From: Eran Hammer-Lahav
Sent: 02-03-2011, 8:27 pm
To: Craig Heath
I am opposed to all the new registration changes and requirements which have
any impact on draft-ietf-oauth-v2. This request seems a bit odd given my
feedback (which you have, again, ignored).
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent:
, and examples for each of your new
proposals?
---
Did I miss a reply?
EHL
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Monday, February 28, 2011 1:25 PM
To: Eran Hammer-Lahav; Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready
: Monday, February 28, 2011 1:34 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group last
call
I realize that we disagree. Unless you change your position, it seems that the
working group will need to decide whether registering error
One more round trip is often too slow.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Phil Hunt
Sent: Monday, February 28, 2011 3:18 PM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
Given
Hey Justin,
Can you provide some examples, use cases or requirements?
EHL
-Original Message-
From: Richer, Justin P. [mailto:jric...@mitre.org]
Sent: Monday, February 28, 2011 2:29 PM
To: Eran Hammer-Lahav; Mike Jones; Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: RE
I think you are making too much of this.
Section 3.2 clearly states:
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.
Which
I don't see a point in an error registry (and I find it odd for the Bearer
token specification to impose any requirements of the protocol specification).
Registries are created to prevent namespace collision. I don't see real problem
with collision of error codes, especially not for a while.
proposals?
EHL
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Friday, February 25, 2011 2:40 PM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: RE: OAuth Errors Registry and OAuth Parameters Registry
I see a problem with collision of error codes. I believe that the working
group
'oauth_token' is limited to bearer tokens only. It is not suitable for anything
else. It is a hack and should be treated as such. The right (extensible)
solution is to use the HTTP Authorization header, which comes with its own
extensibility model.
EHL
From: oauth-boun...@ietf.org
, February 21, 2011 9:36 PM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for
draft-lodderstedt-oauth-security-00
On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav
e...@hueniverse.commailto:e...@hueniverse.com wrote:
How do you
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Toby White
Sent: Sunday, February 20, 2011 8:12 AM
To: OAuth Mailing List
Subject: [OAUTH-WG] OAuth2 queries
Some more OAuth2 queries (based on reading -13)
* There's no direct
Thanks for submitting this draft.
How do you envision this being incorporated into v2? Just section 5 or the
entire document?
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Sunday, February 20, 2011 11:05 AM
To: OAuth WG
Subject:
By #3 Hannes meant defining another option in the spec, not just allowing it to
be defined elsewhere.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Phillip Hunt
Sent: Friday, February 18, 2011 10:22 AM
To: Hannes Tschofenig
Cc:
The best approach (at this point) is to leave the spec unchanged. However,
another spec can update the definition of the response_type parameter,
including defining a registry or other methods for extensibility.
We can define this now, and it will not have any impact on existing code, but I
am
to
extend. That's like the OAuth 1.0 utterly broken oauth_version parameter and
the long confusion it created later on.
EHL
From: Breno [mailto:breno.demedei...@gmail.com]
Sent: Thursday, February 17, 2011 1:58 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom
[mailto:breno.demedei...@gmail.com]
Sent: Thursday, February 17, 2011 4:22 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type
The use case is very straightforward:
- SAML provides session management. Facebook Connect provides session
management. Both use
17, 2011 4:50 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type
On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav
e...@hueniverse.commailto:e...@hueniverse.com wrote:
I am not questioning the use case, only how it fits within the OAuth
Ok.
So you want to request a cookie from both endpoints: the authorization endpoint
and the token endpoint? How would that work? There is no response_type on the
token endpoint.
EHL
From: Breno [mailto:breno.demedei...@gmail.com]
Sent: Thursday, February 17, 2011 9:30 PM
To: Eran Hammer-Lahav
You mean this is encoded into the authorization code?
EHL
From: Breno [mailto:breno.demedei...@gmail.com]
Sent: Thursday, February 17, 2011 10:07 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type
On Thu, Feb 17, 2011 at 9:52 PM, Eran
Can you send an example wire interaction?
EHL
From: Breno [mailto:breno.demedei...@gmail.com]
Sent: Thursday, February 17, 2011 10:07 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type
On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav
e
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Wednesday, January 26, 2011 12:09 PM
- 4.3. Resource Owner Password Credentials. The 3rd paragraph states that
the client MUST discard the credentials once it obtains an access token. I
think it SHOULD
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Wednesday, January 26, 2011 12:09 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
- 4.1. Authorization Code. It is stated that authorization code is suitable
-Original Message-
From: Skylar Woodward [mailto:sky...@kiva.org]
Sent: Thursday, January 27, 2011 2:37 AM
-- 3.1.1, 4.1.2, and Out-of-Band flows
It is an important consideration for us that clients that cannot capture a
redirect from the user-agent be able to use authentication
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Richer, Justin P.
Sent: Thursday, January 27, 2011 12:05 PM
1.2
Tokens may be pure capabilities. To a non-security-engineer such as
myself, this bit reads very oddly on its own. I
(a) is more appropriate. See -13 for revised language.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Stuebner, Christian (extern)
Sent: Wednesday, February 16, 2011 8:01 AM
To: 'oauth@ietf.org'
Subject: [OAUTH-WG] Missing Client
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Wednesday, February 16, 2011 9:05 AM
Yes, I understand. But Native Apps have no appropriate flow now, and they
started the whole protocol.
I am not sure they started the whole protocol (it was more like
Draft -13 includes all feedback received (unless was noted otherwise on the
list) to date. It does not include any implementation changes since -12. Given
the stable state of this draft and the lack of any blocking issues raised for
the included text, I would like to officially request the
Unless someone provides a proposed text to address internationalization
consideration for username and password, I am going to remove this note
unaddressed.
EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
The reason why we don't return a refresh token in the implicit grant is exactly
because there is no client authentication... These are all well-balanced flows
with specific security properties. If you need something else, even if it is
just a tweak, it must be considered a different flow. That
: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Wednesday, February 16, 2011 1:39 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav
e...@hueniverse.com wrote:
The reason why we
Hey Toby,
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Toby White
Sent: Saturday, February 12, 2011 5:57 PM
* Can the timestamp parameter have leading zeroes? ie, would an
authorization header be valid which read:
Authorization:
There wasn't a vote. Just call for feedback and so far I haven't seen consensus.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Phil Hunt
Sent: Thursday, February 10, 2011 3:11 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Hum about
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Manger, James H
Sent: Monday, February 07, 2011 11:31 PM
3. Define link relations.
Link: http://login.example.com/auth? rel=oauth2-auth
This feels possible, but not ideal.
Details
There is no way I'm going to allow not signing the request URI and any query
parameters. That leaves just the body...
EHL
-Original Message-
From: Skylar Woodward [mailto:sky...@kiva.org]
Sent: Monday, February 07, 2011 11:43 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re
: Skylar Woodward [mailto:sky...@kiva.org]
Sent: Tuesday, February 08, 2011 12:57 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02
On Feb 8, 2011, at 6:45 AM, Eran Hammer-Lahav wrote:
This authentication method comes with well understood security
pointless.
EHL
-Original Message-
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, February 08, 2011 2:40 PM
To: Eran Hammer-Lahav; Torsten Lodderstedt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Discovery RE: Bearer token type and scheme
name (deadline: 2/10)
So, if we go
-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Marius Scurtescu
Sent: Tuesday, February 08, 2011 9:24 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline:
2/10)
On Mon, Feb 7, 2011 at 9:59 PM, Eran Hammer-Lahav
Why are we doing this again??? This was clearly option #3 which got no support.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Tuesday, February 08, 2011 3:05 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline
#2
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Tuesday, February 08, 2011 3:17 PM
To: Manger, James H; oauth@ietf.org
Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12
Yes, but it also had other options that were none
Yes, any token issued via OAuth by an authorization server is an OAuth token by
definition. Which makes 'token_type=oauth2' an silly and confusing statement,
given that any token issued via this method is also an OAuth 2.0 token... but
for some reason only one is labeled oauth2.
EHL
From:
Message-
From: Skylar Woodward [mailto:sky...@kiva.org]
Sent: Monday, February 07, 2011 9:25 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02
On body-hash...
Having completed a trial implementation, it seems redundant, and
potentially problematic
What don’t you agree with?
EHL
From: Phillip Hunt [mailto:phil.h...@oracle.com]
Sent: Monday, February 07, 2011 8:29 AM
To: Eran Hammer-Lahav
Cc: Dirk Balfanz; Manger, James H; OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)
-1
I don't agree fully here
token
is not compatible with the specification language, but this is just terminology
and has little to no practical implications.
EHL
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Monday, February 07, 2011 10:16 AM
To: Eran Hammer-Lahav
Cc: Dirk Balfanz; Manger, James H; OAuth WG
Subject
, 2011 at 11:39 AM, Eran Hammer-Lahav
e...@hueniverse.com wrote:
Hey Marius,
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, February 03, 2011 10:36 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Bearer token
parameters are critical to
the request integrity.
The right solution here is to provide either a library for your developers, or
an API without any parameters.
EHL
On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote:
http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02
New
This is where we stand so far:
Option 1 -- 14 votes
William Mills
Eran Hammer-Lahav
Franklin Tse
David Recordon
Peter Saint-Andre
Phil Hunt
Skylar Woodward
Michael Adams
Igor Faynberg
Justin Hart
Brian Campbell
Luke Shepard
James Manger
Minoo Hamilton
Option 2 -- 1 vote
Marius Scurtescu
I'm confused. Can you cut-and-paste the problematic text?
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Saturday, February 05, 2011 8:42 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: draft-hammer-oauth-v2-mac-token-02
Reading through and looking at your example in 1.1 I think you
Of Eran Hammer-Lahav
Sent: Thursday, 3 February 2011 7:34 PM
To: OAuth WG
Subject: [OAUTH-WG] Bearer token type and scheme name (deadline:
2/10)
After a long back-and-forth, I think it is time to present a few
options and have people express their preferences
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Friday, February 04, 2011 9:39 AM
- schemes are not easily reusable outside OAuth.
Sure. But I really don't see this group trying to create generic
authentication schemes.
MAC is exactly that.
After a long back-and-forth, I think it is time to present a few options and
have people express their preferences.
These are the options mentioned so far and their +/-:
1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC)
Each token type gets its own name (which does not include the
03, 2011 5:03 AM
To: Eran Hammer-Lahav; Hannes Tschofenig; oauth@ietf.org
Subject: RE: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication
for Client Credentials'
The main question for me is: What is mandatory to implement?
Nothing. The authorization server can support whatever
The problem with your entire statement below is that it doesn't explain how all
those important goals listed are actually accomplished by this header as
currently defined. Asking again...
- Can you please explain how this header helps interoperability?
- How does a client use this header to
a new option (with full analysis), or don't vote.
EHL
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Thursday, February 03, 2011 8:20 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Bearer token type and scheme name (deadline: 2/10)
This seems like an overly complex characterization
/10)
I'm coming around to #1, I'll put my vote there.I do agree that we have
usage out there of the OAuth2 scheme and we need not to break that, how do we
solve that?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Thursday, February 03
, especially with regard to
the extensive security review this scheme is getting.
Calling the two current scheme and types 'Mac' and 'Bearer' is clean, simply,
descriptive, and forward looking.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent
take it you fully agree with my analysis of the various
options.
And I'm actually implementing the specification thank-you-very-much.
EHL
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Thursday, February 03, 2011 9:20 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Bearer token type
Hey Marius,
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, February 03, 2011 10:36 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline:
2/10)
On Thu, Feb 3, 2011 at 12:34 AM, Eran
Seems a bit odd to issue a refresh token for 6 hours. Why not just issue an
access token for 6 hours without any refresh token.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of matake@gmail
Sent: Thursday, February 03, 2011 4:43 PM
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Hannes Tschofenig
Sent: Thursday, February 03, 2011 8:19 AM
A) Simple Web Discovery (SWD)
http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt
This has no business in this
Hey Marius,
It is critical for us to discuss the client assertion credentials separately
from the assertion authorization grant. The two have nothing to do with one
another.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Marius
501 - 600 of 1089 matches
Mail list logo
