Please use this link to post purely editorial feedback:
http://r9.sharedcopy.com/6djt2n9v
EHL
On 7/11/10 2:35 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Draft -10 submitted. It includes the following changes:
o Fixed typos. Many editorial changes. Rewrote introduction. removed
My bad. I forgot to update the ABNF for the parameters.
The right answer is 2 in the example below and the correct ABNF is:
credentials= OAuth RWS access-token RWS [ 1#auth-param ]
access-token = 1*( quoted-char / )
quoted-char= ! / # / $ / % / / ' / (
/ )
On 7/11/10 3:32 PM, Robert Sayre say...@gmail.com wrote:
On Sun, Jul 11, 2010 at 12:27 PM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
[this has noting to do with realm]
Any solution should be:
- Extensible we removed the few discovery parameters from the core spec
due to lack
-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Monday, 12 July 2010 1:19 PM
To: m...@automattic.com; OAuth WG
Subject: Re: [OAUTH-WG] Authorization Header Format in draft-10
My bad. I forgot to update the ABNF for the parameters.
The right
.
EHL
On 6/29/10 12:11 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
For editorial feedback, I am going to try something new and use SharedCopy.com
(no install required).
Try it out at: http://r6.sharedcopy.com/6bnqq8v
If this doesn't work, I'll let people know and cancel it.
EHL
From
How about write some new text about what refresh tokens are for and when they
should be issued. I think this can benefit from its own section. The rest is
mostly editorial.
EHL
On 7/10/10 8:09 PM, Brian Eaton bea...@google.com wrote:
Hey folks -
The client credentials flow should never
See 'grant_type=none' described in 4.1.
EHL
On 7/10/10 8:12 PM, Brian Eaton bea...@google.com wrote:
Hi folks -
Draft 6 section 2.9.1 had a section called Client Requests Access
Token: http://tools.ietf.org/html/draft-ietf-oauth-v2-06#page-34.
In this flow a client presented a client_id and
There is no user-agent flow anymore. There is a profile (of the generic
endpoints described in the rest of the spec). Draft -09 added the ability to
get both an authorization code and an access token. Your description makes it
sound like draft -09 broke something when it was never proposed that
of it being allowed, but if the general use
case is going to be without it then the example should reflect that and
cut down on the confusion.
-- Justin
On Wed, 2010-07-07 at 18:01 -0400, Brian Eaton wrote:
On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
I disagree
D. No.
But I am looking forward to a long list of feedback for -10 and will do my best
to attend virtually.
EHL
On 7/8/10 9:29 AM, David Recordon record...@gmail.com wrote:
I'm honestly trying to decide myself and a few other people are in similar
situations. Thus a poll:
A) Yes, I'm going
...@ietf.org] On Behalf Of
Andrew Arnott
Sent: Saturday, July 03, 2010 12:16 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user
authresponse code-and-token's scope parameter)
(this sounds sarcastic, but I'm no being
Thanks. Browser security is not my area.
It seems to me that this must be documented as all the examples I have seen for
such scripts did not include any such security measures.
EHL
On 7/7/10 1:06 PM, m...@automattic.com m...@automattic.com wrote:
On Wed, Jul 7, 2010 at 12:47 PM, Eran Hammer
I don't have time to go dig through the list archive.
On 7/7/10 2:02 PM, Brian Eaton bea...@google.com wrote:
On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
It is pretty much the same as originally proposed. Any recent changes are an
oversight, not any
.
EHL
On 7/7/10 2:42 PM, Brian Eaton bea...@google.com wrote:
On Wed, Jul 7, 2010 at 2:18 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
On 7/7/10 2:02 PM, Brian Eaton bea...@google.com wrote:
Can you point me to the e-mail threads that reached consensus on using
client authentication
the parameters for
each endpoint are listed in a single place).
If people think this can be useful, I'm happy to give it a try once -10 is out
and declared stable.
EHL
On 7/7/10 3:01 PM, Brian Eaton bea...@google.com wrote:
On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
I
On Jul 3, 2010, at 7:50, Diogo Almeida diogo.borges.alme...@gmail.com wrote:
Good afternoon,
I would like to ask the WG two questions regarding -09
1)
On section 3.1, regarding the scope parameter, it reads:
code
REQUIRED if the response type is token or code-and-token, otherwise
Platforms change over time. These platforms are not designed with providing
APIs and web services in mind. They are also typically not capable of running
over SSL (due to the self-hosted nature of most deployments). Using an apache
rewrite rules might be hard for some developers, but it is a
utility in application
tracking.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Andrew Arnott
Sent: Saturday, July 03, 2010 12:16 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Security of user
On Sat, Jul 3, 2010 at 9:50 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
There is no difference. The client credentials are either valid or not.
EHL
On 7/3/10 5:28 PM, Andrew Arnott andrewarn...@gmail.com
http://andrewarn...@gmail.com wrote:
I see an invalid-client-credentials error code
Thanks. This was previously reported and already fixed for -10. Should include
the grant_type parameter.
EHL
On 7/3/10 3:57 PM, Diogo Almeida diogo.borges.alme...@gmail.com wrote:
Hello,
Both examples in section 2.1 mention a type parameter, which, if I'm
interpreting the changes correctly,
Section 2 talked about how the client authenticates itself. This is used in the
token endpoint but can be used elsewhere (i.e. A device profile).
EHL
On 7/3/10 5:42 PM, Andrew Arnott andrewarn...@gmail.com wrote:
It may be my misreading the spec, or making assumptions based on my cluttered
There is no difference. The client credentials are either valid or not.
EHL
On 7/3/10 5:28 PM, Andrew Arnott andrewarn...@gmail.com wrote:
I see an invalid-client-credentials error code, but for the basic-credentials
grant type, it seems there should be a specific error code to indicate the
-Original Message-
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Friday, July 02, 2010 4:05 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Versioning
Eran Hammer-Lahav wrote:
[Replying to everything at once...]
-Original Message-
From: Rob
shares state with
the embedding site/page? Not sure about that.
Marius
--
Andrew Arnott
I [may] not agree with what you have to say, but I'll defend to the
death your right to say it. - S. G. Tallentyre
On Fri, Jul 2, 2010 at 10:02 AM, Eran Hammer-Lahav
e...@hueniverse.com
it and pretend to be another client.
EHL
From: Andrew Arnott [mailto:andrewarn...@gmail.com]
Sent: Friday, July 02, 2010 7:24 PM
To: Eran Hammer-Lahav
Cc: Ian McKellar; Marius Scurtescu; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth
response
underscores.
So I also agree with 3 except headers
On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock l...@lukasrosenstock.net
wrote:
3 except headers.
2010/7/1 Eran Hammer-Lahav e...@hueniverse.com:
First, sorry about this. J
I do my best not to ask the group this kind of questions
Ignore as in, pretend it wasn't sent (from either the client or server).
EHL
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, July 01, 2010 6:03 AM
To: Eran Hammer-Lahav
Cc: Yaron Goland; OAuth WG
Subject: Re: [OAUTH-WG] How do we deal
: Thursday, July 01, 2010 10:49 AM
To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org
Subject: RE: [OAUTH-WG] Versioning
My feeling on this is that versioning explicitly in the protocol adds clarity
and
some small level of compatibility. Different auth and token endpoints are
easy, what's
[mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Thursday, July 01, 2010 10:57 AM
To: Marius Scurtescu
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Versioning
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday
Basic
for client credentials, not to log-in an end-user.
EHL
-Original Message-
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Thursday, July 01, 2010 11:08 AM
To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org
Subject: RE: [OAUTH-WG] Versioning
Why is using the string Token
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, July 01, 2010 11:16 AM
To: Eran Hammer-Lahav
Cc: William Mills; Rob Richards; oauth@ietf.org
Subject: Re: [OAUTH-WG] Versioning
On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav
e
: Thursday, July 01, 2010 11:19 AM
To: Eran Hammer-Lahav
Cc: Luke Shepard; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Underscore, dash, green, blue
3 - all underscores.
If underscores are a big issue with headers then we should consider 1
- all dashes. The problem with all dashes
It was and this approach was rejected by this group as confusing. At this
point, it's specification is so short, it can live anywhere.
EHL
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, July 01, 2010 11:28 AM
To: Eran Hammer-Lahav
Cc
The rest of the parameters being in the body.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Marius Scurtescu
Sent: Thursday, July 01, 2010 12:26 PM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Versioning
On Thu,
I think all servers must support the header. I don't think we can demand all
servers to support query or post parameters as that can conflict with their
existing namespace or architecture. I suggest we:
1. Make the Token scheme required in all resource servers
2. Allow resource servers to
I don't think this is necessary.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Marius Scurtescu
Sent: Thursday, July 01, 2010 12:52 PM
To: OAuth WG
Subject: [OAUTH-WG] register prefixes as opposed to full parameter names
For section
[Replying to everything at once...]
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, July 01, 2010 11:36 AM
Not sure about the future, but looking at OAuth 1 vs OAuth 2. A protected
resource request filter may want to decide early what
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, July 01, 2010 2:21 PM
2. Greatly reduce the chances of a conflict with a query parameter
used by an authz server endpoint or client redirect_uri.
There should not be any conflict. Either
That's where the error parameter will be (the only supported place in -09 for a
failed protected resource response).
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Thursday, July 01, 2010 2:51 PM
To: Eran Hammer-Lahav
Cc: Marius Scurtescu
[mailto:tors...@lodderstedt.net]
Sent: Thursday, July 01, 2010 2:59 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Draft -09
since the rewrite of the draft the token endpoint has become a token issuing
endpoint, so revocation does not really fit into the picture
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, July 01, 2010 2:59 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter
names
On Thu, Jul 1, 2010 at 2:52 PM, Eran Hammer-Lahav e
Good point. No error required.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Thursday, July 01, 2010 3:05 PM
To: Eran Hammer-Lahav
Cc: Marius Scurtescu; Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Support for query/body parameters
The SharedCopy experiment is working great (at least for me). However, they
have a bug where the sticky notes move so please always highlight the text in
addition to leaving a note.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Tuesday
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Manger, James H
Sent: Wednesday, June 30, 2010 9:18 PM
To: Yaron Goland; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposal for text for section 2
Yaron,
how can you ding client
First, sorry about this. :)
I do my best not to ask the group this kind of questions and just pick
something on my own, but I can't decide so I'll run a quick vote (yes, a VOTE -
I can't imagine seeking a consensus call on this).
-09 uses underscores for parameter names (except for in the
-Original Message-
From: pel...@gmail.com [mailto:pel...@gmail.com] On Behalf Of Pelle
Braendgaard
Sent: Tuesday, June 29, 2010 7:43 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Draft -09
I found one small error in 3.1 for the code parameter
]
Sent: Friday, June 25, 2010 11:09 PM
To: Yaron Goland
Cc: Eran Hammer-Lahav; James Manger; OAuth WG
Subject: Re: [OAUTH-WG] OAuth discovery draft?
I think it should be possible to discover a resource's OAuth server and its
capabilities using a direct Discovery request. I don't think a WWW
First, there is nothing preventing the server from using:
scope=photos:read profile:read friends:read
or:
scope=photos:read profile:readwrite friends:write
---
I think the current language strikes the right balance between interop and
scopes definitions. While a generic client will not
] On Behalf
Of Eran Hammer-Lahav
Sent: Sunday, June 27, 2010 11:10 PM
To: Dick Hardt; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] semantics of scope parameter
First, there is nothing preventing the server from using:
scope=photos:read profile:read friends:read
or:
scope=photos:read
There are 3 general ways to deal with this:
1. Break on unrecognized parameters - this tends to make the use of extensions
hard, and at a minimum requires an error to include the bad parameter in a
machine readable way (so a library can figure out an extension is not
supported).
2. Ignore
28, 2010 6:11 PM
To: Eran Hammer-Lahav
Cc: Yaron Goland; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests
and responses?
For #2, if an extension defines required parameters then you're not supporting
the extension if you ignore them. Or am I
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Client credentials type
While the AS implementor can infer the request by the parameters, I prefer the
programmer explicitly state what she is doing. Thinking of it as a method
parameter rather than a type parameter makes
Over the past year many people expressed concerns about the use of the 'realm'
WWW-Authenticate header parameter. The parameter is defined in RFC 2617 as
required, and is allowed to have scheme-specific structure.
We have a few options:
1. Leave it as required under the definition of RFC 2617
-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Monday, June 14, 2010 11:35 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] OAuth meeting notes on -05 (with updates)
During the OAuth WG interim meeting, the group spent a considerable
amount of time going over draft -05
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Tuesday, June 22, 2010 11:08 PM
To: OAuth WG
Subject: [OAUTH-WG] Extensibility for OAuth?
Hi Eran,
Hi all,
I briefly browsed through the -08
The interop value of the current proposal is simple:
- defines how multiple scopes are to be expressed (order doesn't matter, space
delimited)
- provides an easy way to express the required scope when rejected a protected
resource request
- allows clients the ability to combine scopes (known
) is a
good thing to support, and by requiring review, only parameters that don't
change the overall design will be approved.
EHL
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Friday, June 25, 2010 11:13 AM
To: Eran Hammer-Lahav
Cc: Tschofenig, Hannes (NSN
The access grants do not correlate to the profiles anymore. For example,
user-agent uses the authorization-code access grant. The section lists how an
autonomous client can use the client credentials or assertion to obtain an
access token.
EHL
From: oauth-boun...@ietf.org
That's coming in -09.
EHL
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Friday, June 25, 2010 11:19 AM
To: Eran Hammer-Lahav
Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG
Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?
I'm ok
We never had support for two assertions in one request.
The client authenticates itself and can include an assertion (or use type
'none'). The client credentials are the client assertion and the assertion is
about the resource owner.
Also, you can define an assertion type that's a composite
on a public list (special for this)
4. get designated expert review
5. get IANA to register
The whole thing can be as fast as 2-3 weeks.
EHL
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Friday, June 25, 2010 11:22 AM
To: Eran Hammer-Lahav
Cc: Tschofenig
easily retrieve my secret and there is no centralized way to revoke/replace
the secret.
Eran Hammer-Lahav wrote on his blog:
However, when the Consumer is a desktop application, a mobile application,
or any other client-side software such as browser applets (Flash, Java,
Silverlight
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, June 17, 2010 2:56 PM
Basically, why cannot be that problem solved by 2 different requests,
both done by the JavaScript layer?
If latency is a problem, it would be good to know exactly
case.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Monday, June 21, 2010 9:50 PM
To: Manger, James H; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] OAuth discovery draft?
Yes, it's on my desk and not yet ready
To: Eran Hammer-Lahav; OAuth WG
Subject: OAuth discovery draft?
Eran,
There have been a few mentions recently of an OAuth discovery draft. Is
there any such draft yet, or is this just a part that we know needs to be
done?
___
OAuth mailing list
It was proposed as part of the device or username and password flow IIRC.
Google has something like that when captcha breaks.
EHL
-Original Message-
From: David Recordon [mailto:record...@gmail.com]
Sent: Tuesday, June 22, 2010 1:47 PM
To: Eran Hammer-Lahav
Cc: Marius Scurtescu
You are a bit behind. -08 added it back as grant_type which works better with
the current explanation.
EHL
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Tuesday, June 22, 2010 1:29 PM
To: Brian Eaton
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Draft -07
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Tuesday, June 22, 2010 4:17 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: native app support (was: Next draft)
On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav
e...@hueniverse.com wrote
I am working on -09 which I hope will be the last major revision of the
specification. If you were planning on submitting any feedback on draft -08 or
the simplification proposal from David and me, please do so by tomorrow to be
included in the next draft.
EHL
: Monday, June 21, 2010 8:03 PM
To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: OAuth discovery draft?
Eran,
There have been a few mentions recently of an OAuth discovery draft. Is
there any such draft yet, or is this just a part that we know needs to be
done?
The email on OAuth
This is a joint proposal from David Recordon and me:
** Background:
The latest draft (-08) unified the web-server and user-agent client types into
a single authorization request format. This was done because once we added an
optional authorization code to the user-agent response, it became
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, June 17, 2010 11:08 AM
To: David Recordon
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user
authorization endpoint
Yes, I am
With the exception of extensibility, I consider draft -08 to be feature
complete. This means that the draft contains all the features and components
needed and other then editorial work is close to finished. I plan to finish
work on the -09 draft by Mon or Tue next week which will include the
Not sure what you are referring to.
EHL
-Original Message-
From: Nat [mailto:sakim...@gmail.com]
Sent: Thursday, June 17, 2010 4:42 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Status update
What about the 'request_url' indirection (without sig
that the proposal in the I-D is
solid and has wide support. Then try to merge it in.
EHL
-Original Message-
From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Thursday, June 17, 2010 6:12 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Status update
...@gmail.com]
Sent: Wednesday, June 16, 2010 8:17 AM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single
authorization flow
Alternative proposal. Create a new call for 'dropping privileges' where a
client can
As long as:
- You can provide a URI identifier for the assertion format you are going to
use, and
- The authorization server can do something useful with the assertion provided
and decide if it should grant an access token
Then sure, you can use the assertion flow for utilizing any other trust
Since XML was dropped, if you feel strongly about this, please submit a new I-D
extending the spec to allow XML format responses. Don't worry about how to
extend it, just add parameters or whatever for now.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Andrew
How they communicate is out of scope.
EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, June 14, 2010 11:57 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] OAuth meeting notes on -05 (with updates)
- Explain that the separation between
Please turn this into a text proposal for section 1.4.3 in -08.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Marius Scurtescu
Sent: Monday, June 07, 2010 12:26 PM
To: OAuth WG
Subject: [OAUTH-WG] OAuth 2 for Native Apps
Hi,
The best way to address this is to write more resilient servers. Servers should
accept empty optional parameters.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Andrew Arnott
Sent: Tuesday, June 15, 2010 6:56 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG]
If the current draft is too hard for server developers to implement correctly,
they should probably hire someone more capable. Server side development of a
security protocol isn't something I'd like to see done by people without the
proper experience. Once we have the security consideration
header field to figure
out the absolute expiration time.
EHL
-Original Message-
From: axel.nenn...@telekom.de [mailto:axel.nenn...@telekom.de]
Sent: Tuesday, June 15, 2010 6:10 AM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: expires_in RE: [OAUTH-WG] OAuth meeting notes on -05
I added:
Parameters sent without a value MUST be treated as if they were omitted from
the request.
This should cover it.
EHL
From: Andrew Arnott [mailto:andrewarn...@gmail.com]
Sent: Tuesday, June 15, 2010 9:49 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Tuesday, June 15, 2010 5:24 PM
To: Eran Hammer-Lahav
Cc: Andrew Arnott; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
On Tue, Jun 15, 2010 at 5:05 PM, Eran Hammer-Lahav e
There is nothing in the spec to prevent other parameters. There will be
specific methods to extend the protocol.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat
Sakimura
Sent: Tuesday, June 15, 2010 6:27 PM
To: oauth
Subject:
on the end-user authorization endpoint to something else such as the proposed
'response_type'. Otherwise change it to 'grant_type' or something like that.
EHL
-Original Message-
From: Chuck Mortimore [mailto:cmortim...@salesforce.com]
Sent: Monday, June 14, 2010 7:54 AM
To: Eran Hammer
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Monday, June 14, 2010 7:20 AM
To: Eran Hammer-Lahav
Cc: Marius Scurtescu; OAuth WG
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
I disagree. I don't think it's redundant, I think it's a clarifying piece
of the end-user authorization
endpoint response, two people voiced specific objections to that. For now, -07
contains an editorial note about that option (using JSON). I think it is worth
further (separate) discussion.
EHL
On Jun 10, 2010, at 2:29 PM, Eran Hammer-Lahav wrote:
After taking a break
:26 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] in-app logout?
Hi Eran,
in my perception, there is some support on the list for having a request to
revoke refresh tokens. Will you add such a request to the specification? Do
you need a text proposal
Yeah. I need to finish the big rewrite before adding new stuff. I plan to get
this done this week.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Paul Madsen
Sent: Monday, June 14, 2010 10:20 AM
To: OAuth WG (oauth@ietf.org)
This is the second half of the big rewrite. I changed the entire introduction
to better explain the new model, as well as cleaned up the rest of the new
work. This is still not a smooth specification, but I think the general
structure is starting to come through. I feel much better about the
:
+1
--
James Manger
--
From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org
[mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Friday, 11 June 2010 6:29 AM
To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject
scope will be.
EHL
From: Evan Gilbert [mailto:uid...@google.com]
Sent: Sunday, June 13, 2010 3:07 AM
To: Eran Hammer-Lahav
Cc: Marius Scurtescu; record...@gmail.com; OAuth WG
Subject: Re: [OAUTH-WG] A display parameter for user authorization requests
The immediate parameter is can have unintended
To be clear, you are +1 on using only JSON for server responses on the token
endpoint?
EHL
From: Evan Gilbert [mailto:uid...@google.com]
Sent: Sunday, June 13, 2010 11:20 AM
To: Eran Hammer-Lahav
Cc: Robert Sayre; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Proposal for single JSON
Unlike the rest of the flows, the device flow lacks deployment experience and
is still likely to change. It also uses a very different architecture than the
rest of the flows (which becomes more obvious in my -07 rewrite). Unless there
is strong objection, I am going to remove it from the core
, 2010 at 5:32 PM, David Recordon record...@gmail.com wrote:
+1 for moving immediate here as well.
On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
Since these are all extensions to the end-user endpoint, I'd suggest we move
the 'immediate' parameter here as well
Unlike the rest of the flows, the device flow lacks deployment experience and
is still likely to change. It also uses a very different architecture than the
rest of the flows (which becomes more obvious in my -07 rewrite). Unless there
is strong objection, I am going to remove it from the core
I'm 135 messages behind on the list. I'm knee deep in -07.
EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Friday, June 11, 2010 10:03 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Fwd: Re: [OAUTH-WG] in-app logout?
Hi Eran,
you probably didn't notice my
Client doesn't need to *be* a web server, just *have* a web server available.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of George Fletcher
Sent: Friday, June 11, 2010 9:25 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] User-agent
801 - 900 of 1089 matches
Mail list logo
