> Eran's suggestion of "Service", "Client", and "User-Agent" sounds likes
> it might work well to clarify the text.
I'll go as far as claiming that OAuth is a traditional client-server model. The
client uses a token to access resources. The fact that those resources are
owned by a third entity d
Hi everyone,
I am new to oAuth & opensocial. A bit confused on oAuth issue.
I am trying to build an opensocial api that enable end user add in the
google, via this api, they would be able to access the private data on
our web application(our server).
After reading some docs, I now understand th
[johnk said]
> The problem is that the term 'consumer' is quite accurate and
> descriptive when you imagine that a software application, in the role
> of a consumer, is consuming the output of the "service provider". An
> 'application' is certainly an OAuth system entity, but the application
On Mar 2, 2009, at 5:37 PM, Brian Eaton wrote:
>
> Ah, I totally forgot about the whole "consumer key" nomenclature.
>
> It would make me incredibly happy if OAuth talked about "consumer
> name"
Exactly, the "consumer key" is an _identifier_ (a name) for the
consuming application.
- johnk
>
On Mar 2, 2009, at 6:32 PM, Manger, James H wrote:
> I would be incredibly happy if OAuth talked about Applications,
> instead of Consumers (a term many have found strange).
The problem is that the term 'consumer' is quite accurate and
descriptive when you imagine that a software application
I don't think application is a good term for the "role" but it certainly should
be used in the explanation.
EHL
> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> Of Manger, James H
> Sent: Monday, March 02, 2009 6:32 PM
> To: oauth@googlegrou
I would be incredibly happy if OAuth talked about Applications, instead of
Consumers (a term many have found strange). Given that oauth_consumer_key is
baked into the protocol, this might be a lost cause.
Perhaps improving the nomenclature is more important.
The spec could add a note that for hi
The agent is a overused term and we still need to differentiate between the
service provider and the service aggregator.
What about service originator, service provider/cloud provider/service
aggregator and service consumer ? Or some version of it. Then we can talk about
SO Key or SP key or SC
I would like to change the entire Service Provider and Consumer terms. Just
use Server, Client, and User-Agent...
Yes, Consumer Key is AWEFUL! I think we can change it. The migration path is
going to be trivial (accept both for a while).
EHL
On 3/2/09 5:37 PM, "Brian Eaton" wrote:
>
>
> Ah
Ah, I totally forgot about the whole "consumer key" nomenclature.
It would make me incredibly happy if OAuth talked about "consumer
name" and "consumer secret", because crypto geeks and others tend to
think that "keys" are secrets. The OAuth consumer key is not secret,
thus leading to confusion.
OAuth’s use of “Consumer Developer” versus “Consumer” can be confusing.
It can sound like the OAuth spec is trying to distinguish: the software
developer who wrote a web app; from a web site where the web app is deployed. A
software developer can write lots of web apps. A web app can be installe
I think the procedure to get consumer keys and secrets depends on the
service providers. You should consult the related document of service
providers.
If you want to use Google applications as OAuth service provider, read
this page
http://code.google.com/apis/accounts/docs/RegistrationForWebApps
> a) Instead of another "easy-to-read" specification document
> of some kind, might be easier to write an OAuth Primer (similar to what
> W3C does). The document can have a section on "Lessons learned from
> implementations". Naturally all of these will get folded into the RFC.
The s
Eran,
Excellent write-up. Couple of quick points:
a) Instead of another "easy-to-read" specification document
of some kind, might be easier to write an OAuth Primer (similar to what
W3C does). The document can have a section on "Lessons learned from
implementations". Naturall
Hi again,
it could be nice adding in the wiki page the HTTP error code -
according to http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
spec - that the SP should be send to the consumer for each problem.
Are there already been defined? Otherwise, I propose following codes:
BAD_REQUEST = 400
Hi Eran,
congratulations, excellent post! It clarified a lot of questions I had
but that I've never asked :P
Best regards!
Simone
2009/3/2 Eran Hammer-Lahav :
>
> http://www.hueniverse.com/hueniverse/2009/03/state-of-the-oauth-union.html
>
> OAuth Core 1.0 was declared as final specification almo
Hi all folks,
I've a a maybe already asked question, so apologize in advance if I
didn't find the reply I'm looking for in the archive, I 'googled' and
raw codes before but unfortunately I didn't clarify my doubt.
I've been developing an OAuth SP for a customer and while writing the
Problem Repor
http://www.hueniverse.com/hueniverse/2009/03/state-of-the-oauth-union.html
OAuth Core 1.0 was declared as final specification almost a year and a half
ago. The overall reception was incredible with almost overnight adoption from
major web players like Google, Yahoo, and MySpace. We even got the
Yes. You are right.
Maybe you can read following OAuth draft which tries to specify how to sign
http request bodies that are not application/x-www-form-urlencoded.
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html.
Also the discussion in following web page is quite helpful
19 matches
Mail list logo
