Thanks!
On 21 Apr 2010, at 5:12 PM, Eran Hammer-Lahav wrote:
> This is part of the delegation flows so username should be just fine…
>
> EHL
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eve
> Maler
> Sent: Wednesday, April 21, 2010 4:43 PM
> To: OAuth WG
> Su
Your original proposal seems like it would do the trick, although I would
make the allowed scope values as flexible as possible while allowing
multiple scope values to be separated by commas or spaces.
If the scope values were opaque to the client, then a server could use
values such as "accounts"
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Wednesday, April 21, 2010 5:22 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] feedback on 4/17 draft
>
> On Wed, Apr 21, 2010 at 5:15 PM, Eran Hammer-Lahav
> wrote:
> >> >> 5.2.2
>
On Wed, Apr 21, 2010 at 10:13 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Am 21.04.2010 17:31, schrieb Evan Gilbert:
>
>
>
> On Tue, Apr 20, 2010 at 10:29 PM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Am 21.04.2010 02:45, schrieb Evan Gilbert:
>>
>>
>>
>> On Tue
On Wed, Apr 21, 2010 at 5:15 PM, Eran Hammer-Lahav wrote:
>> >> 5.2.2
>> >>
>> >> If the entity body includes other parameters, is it worth requiring
>> >> that oauth_token be the first one?
>> >
>> > Why not last?
>>
>> If was just following the same convention as in OAuth 1.0, see RFC 5849,
>> s
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Wednesday, April 21, 2010 3:05 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] feedback on 4/17 draft
>
> On Wed, Apr 21, 2010 at 2:34 PM, Eran Hammer-Lahav
> wrote:
> >> -Origin
This is part of the delegation flows so username should be just fine...
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eve
Maler
Sent: Wednesday, April 21, 2010 4:43 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal
Tacking this response
Tacking this response to the end of the thread for lack of a better place to do
it: The name "username" seems not quite apt in the case of an autonomous client
that isn't representing an end-user. Would "identifier" be better? (Actually,
it sort of reminds me of SAML's "SessionIndex"...) Or woul
On Wed, Apr 21, 2010 at 2:34 PM, Eran Hammer-Lahav wrote:
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Marius Scurtescu
>> Sent: Monday, April 19, 2010 8:04 PM
>
>> 3.5.3.1
>>
>> "an HTTP GET request to the authorization endpoint", s
How about review the proposals?
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Chasen Le Hara
Sent: Wednesday, April 21, 2010 1:23 PM
To: Eve Maler
Cc: jsm...@stanfordalumni.org; OAuth WG
Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
Hi all,
On Tue, Apr 20,
Thanks Marius!
I dropped comments already applied to the spec.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Marius Scurtescu
> Sent: Monday, April 19, 2010 8:04 PM
> 3.5.1
>
> The client is described as being incapable to act as a HT
Am 20.04.2010 20:59, schrieb Eran Hammer-Lahav:
Because the rest of the spec did receive extensive review from both
early adopters and from the previous drafts it borrowed from. Nothing
so far is a new concept. The concept of an identity is new in OAuth,
and while offers important benefits, s
Hi all,
On Tue, Apr 20, 2010 at 6:05 PM, Eve Maler wrote:
> It seems like this proposal "goes there" in terms of getting as expressive
> as Eran fears, though the addition of the wildcard takes away a good deal of
> the pain depending on the particular interface at the endpoint(s). Is there
> an
New service provider that supports OAuth 2.0
Whoa, it was!
So, does anyone know what Facebook is planning to do when the spec changes,
which I assume it's going to keep doing for a while?
I mean, the part of the spec that they're describing on the page has been
pretty stable, but if I were
+1.
On Wed, Apr 21, 2010 at 12:26 PM, Leah Culver wrote:
> Nice!
>
> On Wed, Apr 21, 2010 at 12:01 PM, Allen Tom wrote:
>>
>> Well that was fast!
>>
>> http://developers.facebook.com/docs/authentication/
>>
>> Allen
>>
>> ___
>> OAuth mailing list
>> O
New text:
When issuing an access token, the scope, duration, and other access
attributes granted by
the resource owner must be retained and enforced by the resource server
when receiving a
protected resource request and by the authorization server when
receiving a token
Thanks Dick!
Comments already applied are not listed below.
> -Original Message-
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> Sent: Sunday, April 18, 2010 8:56 PM
> Use of "server" term. In numerous places, the term server is used instead of
> authorization server or resource serv
On Wed, Apr 21, 2010 at 1:16 PM, Marius Scurtescu wrote:
> On Wed, Apr 21, 2010 at 9:31 AM, Robert Sayre wrote:
>> On Wed, Apr 21, 2010 at 12:16 PM, Marius Scurtescu
>> wrote:
>>>
>>> At first 401 may seem like the perfect status code in this case, but
>>> because there is no real challenge resp
Nice!
On Wed, Apr 21, 2010 at 12:01 PM, Allen Tom wrote:
> Well that was fast!
>
> http://developers.facebook.com/docs/authentication/
>
> Allen
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
__
Well that was fast!
http://developers.facebook.com/docs/authentication/
Allen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
+1 on not requiring JSON exclusively. There are enough number of small embedded
software stack where JSON is not an option.
On Apr 20, 2010, at 12:45 PM, David Recordon wrote:
> Having written an implementation last night against the web server
> flow, I'm worried about adding JSON as a require
Ditto here. Apache Shindig uses OAuth extensively and we would like to
upgrade it to OAuth 2.0. The current stable java oauth library is okay, but
does not have an active developer community, and isn't even published to
maven central.
I just had a peek at Amber, looks fairly decent. I can help
I agree, we should not abuse HTTP. Why not just use BASIC authentication?
More arguments pro HTTP authentication can be found in thread
http://www.ietf.org/mail-archive/web/oauth/current/msg01952.html.
regards,
Torsten.
Am 21.04.2010 19:12, schrieb John Kemp:
You all might want to take a lo
On Wed, Apr 21, 2010 at 9:31 AM, Robert Sayre wrote:
> On Wed, Apr 21, 2010 at 12:16 PM, Marius Scurtescu
> wrote:
>>
>> At first 401 may seem like the perfect status code in this case, but
>> because there is no real challenge response, it probably is a bad
>> choice.
>>
>
> There certainly is,
Am 21.04.2010 17:31, schrieb Evan Gilbert:
On Tue, Apr 20, 2010 at 10:29 PM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:
Am 21.04.2010 02:45, schrieb Evan Gilbert:
On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:
You all might want to take a look at Thomas Broyer's cookie-auth HTTP auth
scheme: http://tools.ietf.org/html/draft-broyer-http-cookie-auth-00 for what he
did to implement something reasonably similar.
I do think it would be nice if we don't abuse HTTP, which suggests we should
define a new HTT
+1 pro James' proposal
Am 21.04.2010 18:38, schrieb Eran Hammer-Lahav:
How about Marius' suggestion to use a 200 response?
I'd rather not invent a new auth scheme that is used just to comply with HTTP
requirements for a 401... I think we either keep this simple(r) by using a 400
or 200, or ta
How about Marius' suggestion to use a 200 response?
I'd rather not invent a new auth scheme that is used just to comply with HTTP
requirements for a 401... I think we either keep this simple(r) by using a 400
or 200, or take another look at James' proposal for using Basic auth to send
the clien
On Wed, Apr 21, 2010 at 11:30 AM, Eran Hammer-Lahav wrote:
> We tried something like this approach before but the group consensus was that
> we should only have a single spec for now.
Eran kindly pointed me at this survey:
http://www.ietf.org/mail-archive/web/oauth/current/msg01214.html
It does
+1
At first 401 may seem like the perfect status code in this case, but
because there is no real challenge response, it probably is a bad
choice.
Some HTTP libraries will try to automatically respond to a 401
challenge and if they are not configured to do so will generate noise
in the log files.
On Tue, Apr 20, 2010 at 10:29 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Am 21.04.2010 02:45, schrieb Evan Gilbert:
>
>
>
> On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Hi all,
>>
>> I would like to propose an additional variant o
We tried something like this approach before but the group consensus was that
we should only have a single spec for now. I submitted a draft defining just
the Token auth scheme with the expectation that another drafts define the
flows, but the group didn't like this approach.
As for using Basic
On Wed, Apr 21, 2010 at 11:11 AM, Eran Hammer-Lahav wrote:
> The reason I used 400 in the flows (section 3) is that a 401 response
> requires returning a challenge [1]:
>
> The request requires user authentication. The response MUST include
> a WWW-Authenticate header field.
>
> and we don't
The reason I used 400 in the flows (section 3) is that a 401 response requires
returning a challenge [1]:
The request requires user authentication. The response MUST include
a WWW-Authenticate header field.
and we don't have a suitable challenge to return. We can't use the Token auth
sch
Hi Pid,
I'm also interested in developing a Java library for OAuth 2. There is an
Apache Lab (labs.apache.org , lab named Amber) working on an OAuth 1 Java
API, it could (will) eventually move to Incubator if we manage to get enough
momentum.
It would be nice to have a Java API that integrates wit
35 matches
Mail list logo
