Subject: [OAUTH-WG] Change grant_type="none" to something less confusing

From: Justin Richer <[email-masked]>
Date: Fri, 16 Jul 2010 12:30:26 -0400

The choice of the value "none" for the grant_type parameter in the
client-credentials case is confusing. I understand the philosophy behind
this choice, but I think that calling it "none" here gives the wrong
impression. It almost sounds like it's a deny-request on first glance,
or even a revoke request of some type. Furthermore, I'd say that there
really is an access grant being made here, but it's implicit, and given
to the client directly and not to an end user. 

I propose we change this key to "client", "implicit", "direct", or
something other than "none" to avoid this kind of confusion. Along with
this, I would also like the paragraph in 4.1 describing the usage of
this grant type to be pulled into its own (admittedly short) subsection.
In this way, someone looking to implement this style of auth will have
somewhere concrete to look, bringing this method on par with others in
section 4.1. 

 -- Justin

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 16 Jul 2010 09:39:54 -0700

I agree that grant_type=none is confusing. "client" or "direct" sound better.

Marius

On Fri, Jul 16, 2010 at 9:30 AM, Justin Richer <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Brian Eaton <[email-masked]>
Date: Fri, 16 Jul 2010 09:41:53 -0700

+1.

How about calling it "client password", or something along those
lines...?  That's what Dick called it for WRAP.

http://tools.ietf.org/html/draft-hardt-oauth-01#page-13

Cheers,
Brian

---

From: Brian Campbell <[email-masked]>
Date: Fri, 16 Jul 2010 13:22:40 -0600

+1 for something different but not "client password" as sounds like it
would preclude other methods of client authentication

---

From: Brian Eaton <[email-masked]>
Date: Fri, 16 Jul 2010 12:26:31 -0700

> would preclude other methods of client authentication

I think it would work like this:

grant_type=client_password:
     maps to the "client password flow" from
http://tools.ietf.org/html/draft-hardt-oauth-01#page-13.

grant_type=client_assertion
     maps to the "client assertion" profile
http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2

Cheers,
Brian

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 16 Jul 2010 22:29:30 +0200

good idea.

---

From: David Recordon <[email-masked]>
Date: Fri, 16 Jul 2010 13:37:10 -0700

I've always found "client password" to be a confusing term.

---

From: Brian Eaton <[email-masked]>
Date: Fri, 16 Jul 2010 13:57:23 -0700

> I've always found "client password" to be a confusing term.

Are you going to support this flow at all...?

---

From: Brian Campbell <[email-masked]>
Date: Fri, 16 Jul 2010 15:15:26 -0600

I guess I don't see why there's a need to distinguish between, in the
grant type identifier, how the client authenticates?   (this is all
presupposes, of course, some kind of assertion based client
authentication technique)

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Jul 2010 14:23:31 -0700

And that matters how?

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Jul 2010 14:25:39 -0700

External, out-of-band, implicit.

It cannot be client because that is not always the case. 

EHL

---

From: Brian Eaton <[email-masked]>
Date: Fri, 16 Jul 2010 15:19:19 -0700

> It cannot be client because that is not always the case.

Can you point to a use case where someone is going to use the client
password flow to authenticate something besides a client?

Because I'm pretty sure that use case is crazy, and can safely be ignored.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Jul 2010 15:27:03 -0700

The client authentication can be used to retrieve a grant previously arranged. While the grant is linked to the client, it is not always about the client's resources. Calling it 'client' implies it is about the client's resources. 

EHL

---

From: Brian Eaton <[email-masked]>
Date: Fri, 16 Jul 2010 15:27:34 -0700

I withdraw my question.  David might not be interested in implementing
the client password flow, but he is certainly interested in
implementing other flows that involve the client password term.  So
he's entitled to an opinion on what color the client password bike
shed should be painted. =)

(David, no offense, I'm just trying to stick by my guns on the whole
"stop screwing up the spec by merging separate use cases into single
flows" thing...)

---

From: Brian Eaton <[email-masked]>
Date: Fri, 16 Jul 2010 15:30:28 -0700

On Fri, Jul 16, 2010 at 3:27 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> The client authentication can be used to retrieve a grant previously arranged.

Really?

Who is going to implement that?

I'm pretty sure that if the only inputs to the protocol are a client
name and a client password, the output is going to be an
authentication credential that belongs to the client.

---

From: Luke Shepard <[email-masked]>
Date: Sat, 17 Jul 2010 15:52:55 +0000

Facebook does need to implement this - formerly the "client_cred" flow. We need apps to be able to interact directly with the service without a user involved.

As far as consistency, it is just a little weird to call it "client password" in one part of the spec, when it's defined as "client secret" elsewhere. We wouldn't call it the "client secret" flow because the client secret is used in other flows; I think the same argument applies to the term "client password".

How about just "client_only" ? Eran, I don't think I understand the other use cases you're talking about.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 17 Jul 2010 11:50:15 -0700

The use case is pretty simple: the user uses the server and approves a third party site access to their data directly (i.e. They are not sent to the server from the client, but just use the server). The third part then uses their client credentials to request a token. That token has access to whatever data was authorized previously by any user on the server side. This is still a client-only flow, but the grant isn't just for the client's own resources, but to whatever has been authorized to that client.

All I was trying to say was that when the client uses client credentials alone, it can access resources beyond those under its control (i.e. Its own resources) if such grant was previously arranged. For example, I think FireEagle had an API to ask if any of the users who authorized a client have changed location since last time the client checked. That was done using a client-only token, but it provided some information about individual users (which one was updated).

IOW, the client-credentials flow is not limited to cases where the client is also the resource owner. The client can also access other resources as authorized.

EHL

On 7/17/10 8:52 AM, "Luke Shepard" <[email-masked]> wrote:

---

From: Brian Eaton <[email-masked]>
Date: Sat, 17 Jul 2010 12:41:53 -0700

On Sat, Jul 17, 2010 at 11:50 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> The use case is pretty simple: the user uses the server and approves a third
> party site access to their data directly (i.e. They are not sent to the
> server from the client, but just use the server). The third part then uses
> their client credentials to request a token. That token has access to
> whatever data was authorized previously by any user on the server side. This
> is still a client-only flow, but the grant isn’t just for the client’s own
> resources, but to whatever has been authorized to that client.

Let's pretend we're talking about a human user instead of an API client.

The user enters their username, and their password.

They get a token that can be used to access resources.  Those might
not be their resources; they might be viewing a friend's calendar, for
example.

Would you say calling that a "user password" profile would be
misleading?  Because the grant isn't just for the user's own
resources?

My guess is not.

What we are doing with the client password profile is exactly
equivalent.  Except instead of a human user, we're dealing with an API
client.

Cheers,
Brian

---

From: Brian Eaton <[email-masked]>
Date: Sat, 17 Jul 2010 12:49:12 -0700

On Sat, Jul 17, 2010 at 8:52 AM, Luke Shepard <[email-masked]> wrote:
> As far as consistency, it is just a little weird to call it "client password" in one
> part of the spec, when it's defined as "client secret" elsewhere.

Agreed, we could be more consistent.  The value we're talking about is
the same in all of the flows, no sense in switching terminology.

I prefer client_password, because "password", for me, evokes all the
right kinds of security concerns.  Password storage, encryption on the
wire, etc...

I'm less happy with client_secret, though I can certainly live with
it.  My main concern with client_secret is that people might confuse
it with a signing secret.  The value is not used for signing.  If we
are going to have flows where clients have secrets that are used for
cryptographic authentication, then I would want to call those "keys"
instead.

> How about just "client_only" ?

That would be fine by me.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 17 Jul 2010 12:51:54 -0700

client_credentials worked fine before. I'll just replace none with that. No one had an issue with the name in -05. 

EHL

---

From: Dick Hardt <[email-masked]>
Date: Sat, 17 Jul 2010 13:50:22 -0700

> client_credentials worked fine before. I'll just replace none with that. No one had an issue with the name in -05. 

+1

---

From: Justin Richer <[email-masked]>
Date: Mon, 19 Jul 2010 13:17:11 -0400

"client_credentials" is fine with me for the name of this grant type.
I'd also like the paragraph describing its use to be pulled out into a
subsection, to be parallel with all the other grant types. 

 -- Justin

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Mon, 19 Jul 2010 12:52:03 -0500

I am not aware of the use cases where the client credentials flow is used for authenticating anything, but a client. But the flow is used for authorizing access to the resources other than those owned by a client.

>From OAuth2.0 -05.txt:
The client credentials flow is used when the client acts on behalf of
   itself (the client is the resource owner), or when the client
   credentials are used to obtain an access token representing a
   previously established access authorization.

I am for the initial proposal to replace "none".

Zachary
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, July 16, 2010 6:27 PM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing

EHL

---

From: Brian Eaton <[email-masked]>
Date: Mon, 19 Jul 2010 14:30:43 -0700

client credentials works for me as well.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 20 Jul 2010 11:26:25 +1000

grant_type=client_credential sounds ok.
An even better approach to addressing the discussions about grant_type and assertions would be to focus on the *token response* as a standalone media type, instead of focusing on a common token endpoint.

I don't think requiring the same token endpoint for the different flows is actually that helpful for anyone -- and it has caused confusion/complexity by *coupling* a variety of quite disparate flows (with a continuing debate on what is core vs extension).
Any particular app is likely to only be interested in one section 4 flow ("Obtaining an access token").
Services are free to use a common base URI for any section 4 flows even if that commonality isn't required by the spec.

A common token URI might help if there was a single way to discover it for all flows. So far there isn't, and I doubt there needs to be, nor should be.
Discovering a token endpoint by itself is not that useful. A client needs to know which flows work at that endpoint. Was discovery mentions a specific flow, it may as well provide the endpoint for that flow.

* The token endpoint to send an authorization code could be "discovered" from the code itself (make the code a URI).
* The token endpoint for an assertion flow could be discovered in the same place that describes the required assertion profile -- perhaps WS-MetadataExchange?
* The token endpoint to refresh a token should be discovered when the token is initially provided (ie as part of the token response media type -- make the token info self-descriptive).
* The token endpoint for a client to use on its own behalf should be provided as part of the signal that says the client needs to make this swap (eg a WWW-Auth response, either the same or different from the WWW-Auth response signalling user-delegation is supported).

draft-campbell-oauth-saml, for instance, could define an HTTP request with assertion_type and assertion parameters, and state that the result uses the token response media type. The media type is a cleaner dividing line between draft-campbell-oauth-saml and OAuth2 core.

-- 
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Jul 2010 21:33:50 -0700

I don't have anything against this approach but I suspect others might. I think a few examples would be useful to demonstrate these ideas.

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Manger, James H
> Sent: Monday, July 19, 2010 6:26 PM
> To: OAuth WG
> An even better approach to addressing the discussions about grant_type and
> assertions would be to focus on the *token response* as a standalone media
> type, instead of focusing on a common token endpoint.
> 
> I don't think requiring the same token endpoint for the different flows is
> actually that helpful for anyone -- and it has caused confusion/complexity by
> *coupling* a variety of quite disparate flows (with a continuing debate on
> what is core vs extension).
> 
> Services are free to use a common base URI for any section 4 flows even if
> that commonality isn't required by the spec.
> 
> A common token URI might help if there was a single way to discover it for all
> flows. So far there isn't, and I doubt there needs to be, nor should be.
> Discovering a token endpoint by itself is not that useful. A client needs to
> know which flows work at that endpoint. Was discovery mentions a specific
> flow, it may as well provide the endpoint for that flow.
> 
> * The token endpoint to send an authorization code could be "discovered"
> from the code itself (make the code a URI).
> * The token endpoint for an assertion flow could be discovered in the same
> place that describes the required assertion profile -- perhaps WS-
> MetadataExchange?
> * The token endpoint to refresh a token should be discovered when the
> token is initially provided (ie as part of the token response media type --
> make the token info self-descriptive).
> * The token endpoint for a client to use on its own behalf should be provided
> as part of the signal that says the client needs to make this swap (eg a WWW-
> Auth response, either the same or different from the WWW-Auth response
> signalling user-delegation is supported).
> 
> 
> draft-campbell-oauth-saml, for instance, could define an HTTP request with
> assertion_type and assertion parameters, and state that the result uses the
> token response media type. The media type is a cleaner dividing line
> between draft-campbell-oauth-saml and OAuth2 core.
> 
> 
> --
> James Manger