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
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
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
On Wed, Apr 21, 2010 at 9:31 AM, Robert Sayre say...@gmail.com wrote:
On Wed, Apr 21, 2010 at 12:16 PM, Marius Scurtescu
mscurte...@google.com 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.
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
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
+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
Well that was fast!
http://developers.facebook.com/docs/authentication/
Allen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On Wed, Apr 21, 2010 at 1:16 PM, Marius Scurtescu mscurte...@google.com wrote:
On Wed, Apr 21, 2010 at 9:31 AM, Robert Sayre say...@gmail.com wrote:
On Wed, Apr 21, 2010 at 12:16 PM, Marius Scurtescu
mscurte...@google.com wrote:
At first 401 may seem like the perfect status code in this case,
+1.
On Wed, Apr 21, 2010 at 12:26 PM, Leah Culver leah.cul...@gmail.com wrote:
Nice!
On Wed, Apr 21, 2010 at 12:01 PM, Allen Tom a...@yahoo-inc.com wrote:
Well that was fast!
http://developers.facebook.com/docs/authentication/
Allen
___
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
Hi all,
On Tue, Apr 20, 2010 at 6:05 PM, Eve Maler e...@xmlgrrl.com 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).
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,
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 HTTP
On Wed, Apr 21, 2010 at 2:34 PM, Eran Hammer-Lahav e...@hueniverse.com 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
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 would the
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
On Wed, Apr 21, 2010 at 5:15 PM, Eran Hammer-Lahav e...@hueniverse.com 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,
section
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
Subject:
19 matches
Mail list logo
