c.
Regards,
Andre DeMarre
On Tue, Sep 13, 2011 at 4:52 PM, Greg Brail wrote:
> I would like to add my support to the comments below on section 2.3,
> specifically 2.3.1.
>
> It is clear to me from reading section 2.3 that clients MAY use HTTP
> basic, or they MAY include clie
This part of section 1.1 is confusing to me and I stumble whenever I read it
– I see that Brian Eaton suggested looking at it a while back but I don’t
think it got changed:
“OAuth includes four roles working together to grant and provide
access to protected resources - access restricted reso
I would like to add my support to the comments below on section 2.3,
specifically 2.3.1.
It is clear to me from reading section 2.3 that clients MAY use HTTP
basic, or they MAY include client_id and client_secret in the request
body -- however, the latter is not recommended.
It is not clear what
we have a spec that specifies how an OAuth 2.0 client can securely
retrieve a key for each token in a way that makes sense for OAuth 2.0 and is
easy to implement? Or is this already specified somewhere else?
*From:* Greg Brail [mailto:gbr...@sonoasystems.com]
*Sent:* Thursday, July 22, 2010 2:58 PM
I apologize since I have a feeling that this decision was made long ago but
I'd like to understand...
OAuth 1.0 had a secret associated with every token and used an HMAC to
generate the signature. So, there is no way for an intermediary to see the
token secret, regardless of whether SSL is used.
I'm sorry that I'm late on this but for what it's worth:
Server Response Format: I prefer A (form-encoded only). It's the simplest
solution that requires the least amount of client-side technology. JSON is
too complex a spec for simply encoding a set of flat key-value parameters
when where is alre
then using form-urlencoded, to me, is the simplest
choice that places the fewest barriers in front of developers on all
platforms.
*From:* Luke Shepard [mailto:lshep...@facebook.com]
*Sent:* Friday, May 07, 2010 1:48 AM
*To:* Greg Brail
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] application/x-www-for
I agree that JSON is the long-term winner. However, at least for Java and
Python I know that JSON parsers are not part of the standard library,
whereas everything needed to decode a url-formencoded library is in the
standard libraries and has been there for a long, long time. Keep in mind
that the
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
I'd like to describe a token-related use case that, right now, is how some
people are using parts of OAuth 1.0. I think it's a real use case and I'm
wondering how the proposed OAuth 2.0 would handle it. (I'm on the IETF call too
and it is very quiet.)
We have seen APIs out there that require th
Like a lot of people, I think, things are moving along and we're trying to keep
up. I do have a few more basic questions.
Like it or not, the concept of a "consumer key" and "access token" is
hard-wired into many developers' perceptions of OAuth, and a major difference
between the two specs is
11 matches
Mail list logo
