[oauth] Re: OAuth FAIL

[Zhihong]

+10

This is really confusing in the context of signature. HMAC is keyed-
hash so it's easy to make mistake to feed the key to the hash function
(especially when the key is also a random string).

We experienced the same issue with OpenAuth. It used to have developer
key and now that's renamed to devId. Recently, I have to change our
configuration parameter name from "key" to "name" for the same reason.

If descriptive names are used, "consumer name" would be perfect.
"consumer id" may work better for random string.

Zhihong

On Mar 2, 8: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" 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.
>
> Given that oauth_consumer_key is baked into the protocol, this might
> be a lost cause.
>
> On Mon, Mar 2, 2009 at 5:28 PM, Manger, James H
>
>  wrote:
> > 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
> > installed on lots of independent web sites. I don’t think this is the
> > intention. The desired difference is between a human (“Application Owner”)
> > who can complete a registration process, and a computer program
> > (“Application”) that is configured with keys and secrets.
>
> > It might be clearer to avoid the “Consumer Developer” term – perhaps saying
> > that a Key and Secret must be obtained for a Consumer from the Service
> > Provider.
>
> > James Manger
> > james.h.man...@team.telstra.com
> > Identity and security team — Chief Technology Office — Telstra
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

RE: consumer (was Re: [oauth] Re: OAuth FAIL)

[Eran Hammer-Lahav]

The effort here is (was intended to be) making a list of known issues and not 
so much trying to fix them.

EHL


> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> Of Stephen Farrell
> Sent: Tuesday, March 03, 2009 2:19 AM
> To: oauth@googlegroups.com
> Subject: Re: consumer (was Re: [oauth] Re: OAuth FAIL)
> 
> 
> 
> 
> Eran Hammer-Lahav wrote:
> > It is time to admit that while the terms fit the model, they confuse
> the shit out of everyone reading the spec. That's a clear FAIL.
> 
> I think that's a good synopsis:-)
> 
> Just one thing though, given that the putative IETF WG is probably
> going to be chartered to address these terminology issues (at least
> according to the current charter), folks here should be ready for
> another round of changes if/when the IETF WG gets spun up.
> 
> No harm to have improved proposals in the meantime of course, but
> some or all of this is likely to be revisited in the IETF context
> since that'll be a different set of folks on a different list
> working to the IETF's rough consensus model.
> 
> It'd help there if draft-hammer-oauth-01 (assuming you plan to do
> one before the IETF meeting) has a good section listing all changes
> since draft-hammer-oauth-00.
> 
> S.
> 
> 
> 
> 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

Re: consumer (was Re: [oauth] Re: OAuth FAIL)

[John Kemp]

Hi James,

On Mar 2, 2009, at 8:55 PM, Manger, James H wrote:

> [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
>> might play multiple roles, one of which is as a consumer.
>
>
> I disagree, John.
>
> Colloquially, a "consumer" is a member of the general public, a  
> residential customer, a person -- a closer match to what OAuth calls  
> a "User".

Consumers consume the output of producers, abstractly, whether they  
are humans or software applications.

>
>
> In computing a Consumer is invariably paired with a Producer. There  
> is usually an event stream from the Producer to the Consumer. OAuth  
> does not use "Producer" (using Service Provider instead), and there  
> is no event stream, so I think it should avoid "Consumer".

I hate to bring up SOAP, but "web services" had the web service  
consumer and web service provider. I know we don't like SOAP, but I do  
think "consumer" and "service" are reasonably descriptive terms, and I  
would suggest that although not perfect, they might be as close as we  
can get.

>
>
> Consider an application that posts tweets to twitter on my behalf,  
> or adds appointments to my online calendar, or periodically loads  
> images from a web cam into flickr. Such apps can hardly be called  
> consumers (without causing confusion). Such apps are producing the  
> content that the service consumes.
>
>
> Eran's suggestion of "Service", "Client", and "User-Agent" sounds  
> likes it might work well to clarify the text.

The client may be also a user-agent. Or the client might also be a  
service. I don't like "consumer" so much, but I don't think that  
"client" is an upgrade.

- johnk

>
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

Re: consumer (was Re: [oauth] Re: OAuth FAIL)

[Stephen Farrell]

Eran Hammer-Lahav wrote:
> It is time to admit that while the terms fit the model, they confuse the shit 
> out of everyone reading the spec. That's a clear FAIL.

I think that's a good synopsis:-)

Just one thing though, given that the putative IETF WG is probably
going to be chartered to address these terminology issues (at least
according to the current charter), folks here should be ready for
another round of changes if/when the IETF WG gets spun up.

No harm to have improved proposals in the meantime of course, but
some or all of this is likely to be revisited in the IETF context
since that'll be a different set of folks on a different list
working to the IETF's rough consensus model.

It'd help there if draft-hammer-oauth-01 (assuming you plan to do
one before the IETF meeting) has a good section listing all changes
since draft-hammer-oauth-00.

S.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[Christian Scholz / Tao Takashi (SL)]

On Tue, Mar 3, 2009 at 4:43 AM, John Kemp  wrote:

>
> 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.


Maybe consumer_id then ;-)

Another thing which might be interesting would be to explain what all the
parts are good for. Like why a consumer name/secret, why a request token and
so on. I would assume that to some people it might not be directly clear and
it probably helps implementations if people know more why they are doing
things. But I haven't looked back into the spec so I am not sure if it's not
maybe already in there.

And (unrelated) another question: Is there a list of extensions somewhere?
Would be good to prevent duplicating efforts.

-- Christian


-- 
Christian Scholz
http://mrtopf.de/blog

New Podcast: http://datawithoutborders.net

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

Re: consumer (was Re: [oauth] Re: OAuth FAIL)

[Hubert Le Van Gong]

Not quite. In many cases (Liberty Alliance, SOA, Apple developer etc.) I've seen
the term Service Consumer (and also Web Service Consumer) used and paired up
with (Web) Service Provider.
Hosting a protected resource and granting access to it is providing a service
so I think SP is an appropriate term.
One might want to use Relying Party instead of Service Consumer but I think
the latter is closer since it does consume a service offered by the
Service Provider.

Cheers,
Hubert


On Tue, Mar 3, 2009 at 5:55 AM, Manger, James H
 wrote:
> [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
>> might play multiple roles, one of which is as a consumer.
>
>
> I disagree, John.
>
> Colloquially, a "consumer" is a member of the general public, a residential 
> customer, a person -- a closer match to what OAuth calls a "User".
>
> In computing a Consumer is invariably paired with a Producer. There is 
> usually an event stream from the Producer to the Consumer. OAuth does not use 
> "Producer" (using Service Provider instead), and there is no event stream, so 
> I think it should avoid "Consumer".
>
> Consider an application that posts tweets to twitter on my behalf, or adds 
> appointments to my online calendar, or periodically loads images from a web 
> cam into flickr. Such apps can hardly be called consumers (without causing 
> confusion). Such apps are producing the content that the service consumes.
>
>
> Eran's suggestion of "Service", "Client", and "User-Agent" sounds likes it 
> might work well to clarify the text.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

RE: consumer (was Re: [oauth] Re: OAuth FAIL)

[Eran Hammer-Lahav]

> 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 doesn't change the nature of the interaction.

Now, how the client gets the token is a different story in which the user plays 
a role. But it is important to separate the two parts. To get a token, the 
client brings the user into context, current via a user-agent.

It is time to admit that while the terms fit the model, they confuse the shit 
out of everyone reading the spec. That's a clear FAIL.

EHL

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

RE: consumer (was Re: [oauth] Re: OAuth FAIL)

[Manger, James H]

[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  
> might play multiple roles, one of which is as a consumer.


I disagree, John.

Colloquially, a "consumer" is a member of the general public, a residential 
customer, a person -- a closer match to what OAuth calls a "User".

In computing a Consumer is invariably paired with a Producer. There is usually 
an event stream from the Producer to the Consumer. OAuth does not use 
"Producer" (using Service Provider instead), and there is no event stream, so I 
think it should avoid "Consumer".

Consider an application that posts tweets to twitter on my behalf, or adds 
appointments to my online calendar, or periodically loads images from a web cam 
into flickr. Such apps can hardly be called consumers (without causing 
confusion). Such apps are producing the content that the service consumes.


Eran's suggestion of "Service", "Client", and "User-Agent" sounds likes it 
might work well to clarify the text.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[John Kemp]

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

> 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.
>
> Given that oauth_consumer_key is baked into the protocol, this might
> be a lost cause.
>
> On Mon, Mar 2, 2009 at 5:28 PM, Manger, James H
>  wrote:
>> 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
>> installed on lots of independent web sites. I don’t think this is the
>> intention. The desired difference is between a human (“Application  
>> Owner”)
>> who can complete a registration process, and a computer program
>> (“Application”) that is configured with keys and secrets.
>>
>>
>>
>> It might be clearer to avoid the “Consumer Developer” term –  
>> perhaps saying
>> that a Key and Secret must be obtained for a Consumer from the  
>> Service
>> Provider.
>>
>>
>>
>> James Manger
>> james.h.man...@team.telstra.com
>> Identity and security team — Chief Technology Office — Telstra
>>
>>
>>
>>>
>>
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

Re: consumer (was Re: [oauth] Re: OAuth FAIL)

[John Kemp]

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, 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  
might play multiple roles, one of which is as a consumer.

- johnk

> 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 historical reasons the label  
> "oauth_consumer_key" is used. Or change the label in a new version  
> with a note to also accept the old label when backward compatibility  
> is required.
>
>
> James Manger
> james.h.man...@team.telstra.com
> Identity and security team — Chief Technology Office — Telstra
> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On  
> Behalf Of Brian Eaton
> Sent: Tuesday, 3 March 2009 12:38 PM
> To: oauth@googlegroups.com
> Subject: [oauth] Re: OAuth FAIL
>
>
> 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.
>
> Given that oauth_consumer_key is baked into the protocol, this might
> be a lost cause.
>
> On Mon, Mar 2, 2009 at 5:28 PM, Manger, James H
>  wrote:
>> 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
>> installed on lots of independent web sites. I don’t think this is the
>> intention. The desired difference is between a human (“Application  
>> Owner”)
>> who can complete a registration process, and a computer program
>> (“Application”) that is configured with keys and secrets.
>>
>>
>>
>> It might be clearer to avoid the “Consumer Developer” term –  
>> perhaps saying
>> that a Key and Secret must be obtained for a Consumer from the  
>> Service
>> Provider.
>
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[Eran Hammer-Lahav]

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@googlegroups.com
> Subject: [oauth] Re: OAuth FAIL
> 
> 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 historical reasons the label
> "oauth_consumer_key" is used. Or change the label in a new version with
> a note to also accept the old label when backward compatibility is
> required.
> 
> 
> James Manger
> james.h.man...@team.telstra.com
> Identity and security team — Chief Technology Office — Telstra
> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> Of Brian Eaton
> Sent: Tuesday, 3 March 2009 12:38 PM
> To: oauth@googlegroups.com
> Subject: [oauth] Re: OAuth FAIL
> 
> 
> 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.
> 
> Given that oauth_consumer_key is baked into the protocol, this might
> be a lost cause.
> 
> On Mon, Mar 2, 2009 at 5:28 PM, Manger, James H
>  wrote:
> > 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
> > installed on lots of independent web sites. I don’t think this is the
> > intention. The desired difference is between a human (“Application
> Owner”)
> > who can complete a registration process, and a computer program
> > (“Application”) that is configured with keys and secrets.
> >
> >
> >
> > It might be clearer to avoid the “Consumer Developer” term – perhaps
> saying
> > that a Key and Secret must be obtained for a Consumer from the
> Service
> > Provider.
> 
> 
> 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[Manger, James H]

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 historical reasons the label 
"oauth_consumer_key" is used. Or change the label in a new version with a note 
to also accept the old label when backward compatibility is required.


James Manger
james.h.man...@team.telstra.com
Identity and security team — Chief Technology Office — Telstra
-Original Message-
From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian 
Eaton
Sent: Tuesday, 3 March 2009 12:38 PM
To: oauth@googlegroups.com
Subject: [oauth] Re: OAuth FAIL


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.

Given that oauth_consumer_key is baked into the protocol, this might
be a lost cause.

On Mon, Mar 2, 2009 at 5:28 PM, Manger, James H
 wrote:
> 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
> installed on lots of independent web sites. I don’t think this is the
> intention. The desired difference is between a human (“Application Owner”)
> who can complete a registration process, and a computer program
> (“Application”) that is configured with keys and secrets.
>
>
>
> It might be clearer to avoid the “Consumer Developer” term – perhaps saying
> that a Key and Secret must be obtained for a Consumer from the Service
> Provider.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[Krishna Sankar (ksankar)]

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 key and other artifacts thereof.

Cheers


|-Original Message-
|From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
|Of Eran Hammer-Lahav
|Sent: Monday, March 02, 2009 5:46 PM
|To: oauth@googlegroups.com
|Subject: [oauth] Re: OAuth FAIL
|
|
|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, 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.
|>
|> Given that oauth_consumer_key is baked into the protocol, this might
|> be a lost cause.
|>
|> On Mon, Mar 2, 2009 at 5:28 PM, Manger, James H
|>  wrote:
|>> 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
|>> installed on lots of independent web sites. I don¹t think this is the
|>> intention. The desired difference is between a human (³Application
|Owner²)
|>> who can complete a registration process, and a computer program
|>> (³Application²) that is configured with keys and secrets.
|>>
|>>
|>>
|>> It might be clearer to avoid the ³Consumer Developer² term ­ perhaps
|saying
|>> that a Key and Secret must be obtained for a Consumer from the
|Service
|>> Provider.
|>>
|>>
|>>
|>> James Manger
|>> james.h.man...@team.telstra.com
|>> Identity and security team < Chief Technology Office < Telstra
|>>
|>>
|>>
|
|
|

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[Eran Hammer-Lahav]

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, 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.
> 
> Given that oauth_consumer_key is baked into the protocol, this might
> be a lost cause.
> 
> On Mon, Mar 2, 2009 at 5:28 PM, Manger, James H
>  wrote:
>> 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
>> installed on lots of independent web sites. I don¹t think this is the
>> intention. The desired difference is between a human (³Application Owner²)
>> who can complete a registration process, and a computer program
>> (³Application²) that is configured with keys and secrets.
>> 
>> 
>> 
>> It might be clearer to avoid the ³Consumer Developer² term ­ perhaps saying
>> that a Key and Secret must be obtained for a Consumer from the Service
>> Provider.
>> 
>> 
>> 
>> James Manger
>> james.h.man...@team.telstra.com
>> Identity and security team < Chief Technology Office < Telstra
>> 
>> 
>> 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[Brian Eaton]

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.

Given that oauth_consumer_key is baked into the protocol, this might
be a lost cause.

On Mon, Mar 2, 2009 at 5:28 PM, Manger, James H
 wrote:
> 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
> installed on lots of independent web sites. I don’t think this is the
> intention. The desired difference is between a human (“Application Owner”)
> who can complete a registration process, and a computer program
> (“Application”) that is configured with keys and secrets.
>
>
>
> It might be clearer to avoid the “Consumer Developer” term – perhaps saying
> that a Key and Secret must be obtained for a Consumer from the Service
> Provider.
>
>
>
> James Manger
> james.h.man...@team.telstra.com
> Identity and security team — Chief Technology Office — Telstra
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[zhenhua guo]

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:
http://groups.google.com/group/oauth/browse_thread/thread/acd036474649402a/8a07b353faca5cea?pli=1

Gerald

On Sun, Mar 1, 2009 at 10:21 PM, Martin Atkins wrote:

>
>
> One I encountered recently:
>
> The OAuth spec doesn't define how to generate the signature for HTTP
> requests with bodies that are not application/x-www-form-urlencoded.
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[Martin Atkins]

One I encountered recently:

The OAuth spec doesn't define how to generate the signature for HTTP 
requests with bodies that are not application/x-www-form-urlencoded.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[Brian Eaton]

On Fri, Feb 27, 2009 at 11:36 AM, rawc  wrote:
> I don't see a huge problem with the 'request token' phrasing
> (especially since it is clearly described in the spec) and
> 'intermediate token' probably wouldn't make things any more clear as
> to the function of the token.  If it was changed, though, you could do
> something similar to Kerberos and call it a 'token granting
> token'...kind of like the Kerberos 'ticket granting ticket' (TGT).

It's not really similar to a kerberos TGT.  A kerberos TGT gets you
automatic authentication to all services, which is nowhere near what
an OAuth request token does.

I think "initialization token" might work.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[rawc]

I don't see a huge problem with the 'request token' phrasing
(especially since it is clearly described in the spec) and
'intermediate token' probably wouldn't make things any more clear as
to the function of the token.  If it was changed, though, you could do
something similar to Kerberos and call it a 'token granting
token'...kind of like the Kerberos 'ticket granting ticket' (TGT).

Just my two cents.

On Feb 25, 7:51 pm, anders conbere  wrote:
> On Wed, Feb 25, 2009 at 1:58 PM, Seth Fitzsimmons  wrote:
>
> > My quick list:
>
> > * terminology - 'request a request token'
>
> I would prefer something like "intermediate token" (what does request
> token mean?!)
>
> > * Handling of "required" empty parameters.
> > * plaintext secret w/ empty access token (&, not 
> > )
>
> This is a little weird, but ends up being really easy to program for.
> I could go either way.
>
> > * realm handling
> > * clearer explanation of creating the signature base string (in my
> > experience, this is the source of most problems)
> > * explicit definition of 2-legged auth
> > * sections 6 and 7 being approximately the same thing
>
> Having example input data and outputs of the resultant signature +
> various intermediate data items (sbs, etc.) would be extremely
> helpful.
>
> ~ Anders
>
>
>
> > seth
>
> > On Tue, Feb 24, 2009 at 3:25 PM, Eran Hammer-Lahav  
> > wrote:
>
> >> I am getting ready to making a complete rewrite of the current OAuth spec.
> >> The idea is to make it much easier to read without changing anything that
> >> will impact implementation. This will be useful both for clarity but also 
> >> as
> >> a better starting point for the upcoming OAuth effort at the IETF.
>
> >> What I would like to ask people who have read the spec or implemented it to
> >> share as many problems, errors, failures, mistakes, misunderstandings,
> >> wasted time, etc. caused by the spec not being clear enough.
>
> >> You can simply describe the error (did not sort parameter, did not 
> >> %-encode,
> >> %-encoded twice, etc.) or the section of the spec you had to read 325 times
> >> before it made any sense.
>
> >> Please reply to this thread so we have a public inventory of OAuth FAILs.
>
> >> EHL
>
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[Brian Eaton]

On Tue, Feb 24, 2009 at 3:25 PM, Eran Hammer-Lahav  wrote:
> Please reply to this thread so we have a public inventory of OAuth FAILs.

The nonce and timestamp checking language in the OAuth core spec would
require infinite storage to implement.  It should be removed entirely
or rephrased to something that people can implement.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[anders conbere]

On Wed, Feb 25, 2009 at 1:58 PM, Seth Fitzsimmons  wrote:
>
> My quick list:
>
> * terminology - 'request a request token'

I would prefer something like "intermediate token" (what does request
token mean?!)

> * Handling of "required" empty parameters.
> * plaintext secret w/ empty access token (&, not 
> )

This is a little weird, but ends up being really easy to program for.
I could go either way.

> * realm handling
> * clearer explanation of creating the signature base string (in my
> experience, this is the source of most problems)
> * explicit definition of 2-legged auth
> * sections 6 and 7 being approximately the same thing

Having example input data and outputs of the resultant signature +
various intermediate data items (sbs, etc.) would be extremely
helpful.

~ Anders

>
> seth
>
> On Tue, Feb 24, 2009 at 3:25 PM, Eran Hammer-Lahav  
> wrote:
>>
>> I am getting ready to making a complete rewrite of the current OAuth spec.
>> The idea is to make it much easier to read without changing anything that
>> will impact implementation. This will be useful both for clarity but also as
>> a better starting point for the upcoming OAuth effort at the IETF.
>>
>> What I would like to ask people who have read the spec or implemented it to
>> share as many problems, errors, failures, mistakes, misunderstandings,
>> wasted time, etc. caused by the spec not being clear enough.
>>
>> You can simply describe the error (did not sort parameter, did not %-encode,
>> %-encoded twice, etc.) or the section of the spec you had to read 325 times
>> before it made any sense.
>>
>> Please reply to this thread so we have a public inventory of OAuth FAILs.
>>
>> EHL
>>
>>
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[JR Conlin]

The biggest complaint I hear about is the confusion around "consumer 
key" vs. "oauth token".

For Netflix, the problem is determining who the consumer is, often with 
the individual creating the third party app to be sold on iPhones 
inevitably getting it wrong.

We use API Key and secret for the Consumer Key and Shared Secret along 
with Access Token and Access Secret for the OAuth Token and OAuth 
Secret. We do that because we use two legged OAuth for information that 
doesn't involve our customers and three legged for info that does. By 
and large, most folks get it.

Obviously "API Key" doesn't work for services that don't provide them, 
but they should be named something a bit more descriptive and less 
confusing, possibly "primary" and "secondary" to indicate how they're 
generally used.


Eran Hammer-Lahav wrote:
> I am getting ready to making a complete rewrite of the current OAuth spec.
> The idea is to make it much easier to read without changing anything that
> will impact implementation. This will be useful both for clarity but also as
> a better starting point for the upcoming OAuth effort at the IETF.
>
> What I would like to ask people who have read the spec or implemented it to
> share as many problems, errors, failures, mistakes, misunderstandings,
> wasted time, etc. caused by the spec not being clear enough.
>
> You can simply describe the error (did not sort parameter, did not %-encode,
> %-encoded twice, etc.) or the section of the spec you had to read 325 times
> before it made any sense.
>
> Please reply to this thread so we have a public inventory of OAuth FAILs.
>
> EHL
>
>
> >
>
>   


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[Seth Fitzsimmons]

My quick list:

* terminology - 'request a request token'
* Handling of "required" empty parameters.
* plaintext secret w/ empty access token (&, not )
* realm handling
* clearer explanation of creating the signature base string (in my
experience, this is the source of most problems)
* explicit definition of 2-legged auth
* sections 6 and 7 being approximately the same thing

seth

On Tue, Feb 24, 2009 at 3:25 PM, Eran Hammer-Lahav  wrote:
>
> I am getting ready to making a complete rewrite of the current OAuth spec.
> The idea is to make it much easier to read without changing anything that
> will impact implementation. This will be useful both for clarity but also as
> a better starting point for the upcoming OAuth effort at the IETF.
>
> What I would like to ask people who have read the spec or implemented it to
> share as many problems, errors, failures, mistakes, misunderstandings,
> wasted time, etc. caused by the spec not being clear enough.
>
> You can simply describe the error (did not sort parameter, did not %-encode,
> %-encoded twice, etc.) or the section of the spec you had to read 325 times
> before it made any sense.
>
> Please reply to this thread so we have a public inventory of OAuth FAILs.
>
> EHL
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[Andrew Arnott]

Cool.  You may recall these previous discussion on this list of questions of
mine that stemmed from reading of the spec:
Lexicographical ordering of
parameters

Is oauth_token required in SP redirect to
Consumer?


I'd love to see the spec fixed up so that these questions are implicitly
answered.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire


On Tue, Feb 24, 2009 at 3:25 PM, Eran Hammer-Lahav wrote:

>
> I am getting ready to making a complete rewrite of the current OAuth spec.
> The idea is to make it much easier to read without changing anything that
> will impact implementation. This will be useful both for clarity but also
> as
> a better starting point for the upcoming OAuth effort at the IETF.
>
> What I would like to ask people who have read the spec or implemented it to
> share as many problems, errors, failures, mistakes, misunderstandings,
> wasted time, etc. caused by the spec not being clear enough.
>
> You can simply describe the error (did not sort parameter, did not
> %-encode,
> %-encoded twice, etc.) or the section of the spec you had to read 325 times
> before it made any sense.
>
> Please reply to this thread so we have a public inventory of OAuth FAILs.
>
> EHL
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth FAIL

[Sergey Chernyshev]

I had this as a draft in my Gmail for a while - never had time to finish it,
but since you asked, here you go ;)

I'm digging into OAuth Core specification  and OAuth
Discovery extension  trying to understand
the use case where OAuth Consumers are not registered in any way with OAuth
Service Provider before they make requests and knowing only Data Resource
URLs (called "Protected Resource endpoint" in the Discovery extension
document), but having no idea about which Request URLs they use. My interest
is in using OAuth with arbitrary RDF resource (encoded in RDF/XML, n3, RDFa
or whatever).

I noticed an inconsistency in specification when looking at it from this
point of view:

"Service Providers *SHOULD NOT rely on the Consumer Secret as a method to
verify the Consumer identity*, unless the Consumer Secret is known to be
inaccessible to anyone other than the Consumer and the Service Provider. The
Consumer Secret *MAY be an empty string* (*for example when no Consumer
verification is needed* ...)" (section 4 paragraph 2)

and still

"The Consumer Developer *MUST *establish a Consumer Key and a Consumer
Secret with the Service Provider." (section 4.3).

What's the point to mandate register of a Consumer with Service Provider if
there are cases when no Consumer verification is needed? I think it's not
necessary to require this kind of registration upfront in cases when Service
Provider does not need to verify a Consumer.

Also, in

"The Service Provider *verifies the signature and Consumer Key*. If
successful, ..." (section 6.1.2)

it's not clear if Consumer key only verifies the signature or if it also
required to be verified against the Consumer registration entry.

Same goes for the assumption in

"The Service Provider presents to the User information about the Consumer
requesting access (*as registered by the Consumer Developer*)." (section
6.2.2)

which is probably worthless as this registration does not mandate any
information that can properly identify the Consumer (or any other way fight
fake consumers). Spec also doesn't require knowing the identity of the
Consumer:

"When displaying any identifying information about the Consumer to the User
based on the Consumer Key, the Service Provider MUST inform the User *if it
is unable to assure the Consumer's true identity*." (section 6.2.2)

Having said all of this, I have a few questions:

   1. If it's safe to remove the assumption that Consumer is registered with
   the Service Provider prior to the phase when it is requesting first Request
   Tocken (see my rationale above regarding section 4 paragraph 2 of the spec)?
   2. If it's OK to do, then what are the implications for such
   implementation? Is it just putting more responsibility on a User when he
   accepts access for not really verifiable provider? What kind of attacks are
   possible in this case? And what might be the best practices to minimize a
   risk of fake Consumers (can we call it "phishing"?)?

Will be happy to answer any questions regarding this use case.

As more generic question for post-discussion - why do consumers need to know
anything other then URL when they talk to producers? Most of the time they
just need read-only access to data in some format that they can assume or
auto-detect...

Thank you,

   Sergey


On Tue, Feb 24, 2009 at 6:25 PM, Eran Hammer-Lahav wrote:

>
> I am getting ready to making a complete rewrite of the current OAuth spec.
> The idea is to make it much easier to read without changing anything that
> will impact implementation. This will be useful both for clarity but also
> as
> a better starting point for the upcoming OAuth effort at the IETF.
>
> What I would like to ask people who have read the spec or implemented it to
> share as many problems, errors, failures, mistakes, misunderstandings,
> wasted time, etc. caused by the spec not being clear enough.
>
> You can simply describe the error (did not sort parameter, did not
> %-encode,
> %-encoded twice, etc.) or the section of the spec you had to read 325 times
> before it made any sense.
>
> Please reply to this thread so we have a public inventory of OAuth FAILs.
>
> EHL
>
>
> >
>


-- 
Sergey Chernyshev
http://www.sergeychernyshev.com/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---