Subject: [OAUTH-WG] Client credentials type

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 28 Jun 2010 10:39:34 -0700

Yaron Goland offered a proposal for an additional client credentials mechanism based on assertion. His proposal raises the issue of differentiating between the different kind of credentials used. When it comes to access grant types, this group argued for being explicit and providing a parameter declaring the grant type being used (even though it is not technically necessary).

While I don't believe a grant or credential type parameter is needed - the type can be deduced from the other parameters present - we now treat the same requirement with a different solution. I think this creates a broken environment for extensibility (which is my current focus).

At the same time, introducing such a parameter can conflict with the standard HTTP authentication mechanism. For example, a request containing both "client_credentials_type=basic" and the HTTP Authorization header seems odd.

There are a few ways to address this:

1. Only use a type parameter when the credentials are passed using parameters and not a header.
2. Only allow HTTP headers for authentication, while "grandfathering-in" the client_secret parameter to simplify the most common current practice.
3. Leave is underspecified, relying on the presence of extension parameters or authentication headers for other credentials types.

Thoughts?

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 28 Jun 2010 20:21:08 +0200

I would prefer (2) since authorization headers are the natural way to 
handle authentication in HTTP. Different client credential mechanisms 
can be represented by different authentication scheme (even 
custom-defined). HTTP libraries typically have special support for 
handling such headers and it keeps the authentication mechanism 
orthogonal of the API. Moreover, authorization headers very well work 
together with status code 401 and WWW-Authenticate headers. Using 
WWW-Authenticate headers, an authz server can easily signal what 
mechanisms (multiple WWW-Authenticate headers are allowed in a single 
HTTP response) it accepts for a particular request.

regards,
Torsten.

Am 28.06.2010 19:39, schrieb Eran Hammer-Lahav:
>
> Yaron Goland offered a proposal for an additional client credentials 
> mechanism based on assertion. His proposal raises the issue of 
> differentiating between the different kind of credentials used. When 
> it comes to access grant types, this group argued for being explicit 
> and providing a parameter declaring the grant type being used (even 
> though it is not technically necessary).
>
> While I don't believe a grant or credential type parameter is needed 
> -- the type can be deduced from the other parameters present -- we now 
> treat the same requirement with a different solution. I think this 
> creates a broken environment for extensibility (which is my current 
> focus).
>
> At the same time, introducing such a parameter can conflict with the 
> standard HTTP authentication mechanism. For example, a request 
> containing both "client_credentials_type=basic" and the HTTP 
> Authorization header seems odd.
>
> 2. Only allow HTTP headers for authentication, while 
> "grandfathering-in" the client_secret parameter to simplify the most 
> common current practice.
>
> 3. Leave is underspecified, relying on the presence of extension 
> parameters or authentication headers for other credentials types.
>
> Thoughts?
>
> EHL
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 28 Jun 2010 12:19:40 -0700

Only HTTP headers may not be enough. In Yaron's proposal, the
assertion could be a SAML assertion, and these could be too large for
headers.

I think #1 makes sense.

Marius

On Mon, Jun 28, 2010 at 11:21 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> I would prefer (2) since authorization headers are the natural way to handle
> authentication in HTTP. Different client credential mechanisms can be
> represented by different authentication scheme (even custom-defined). HTTP
> libraries typically have special support for handling such headers and it
> keeps the authentication mechanism orthogonal of the API. Moreover,
> authorization headers very well work together with status code 401 and
> WWW-Authenticate headers. Using WWW-Authenticate headers, an authz server
> can easily signal what mechanisms (multiple WWW-Authenticate headers are
> allowed in a single HTTP response) it accepts for a particular request.
>
> regards,
> Torsten.
>
> differentiating between the different kind of credentials used. When it
> comes to access grant types, this group argued for being explicit and
> providing a parameter declaring the grant type being used (even though it is
> not technically necessary).
>
>
>
> While I don’t believe a grant or credential type parameter is needed – the
> type can be deduced from the other parameters present – we now treat the
> same requirement with a different solution. I think this creates a broken
> environment for extensibility (which is my current focus).
>
>
>
> standard HTTP authentication mechanism. For example, a request containing
> both “client_credentials_type=basic” and the HTTP Authorization header seems
> odd.
>
>
>
> 2. Only allow HTTP headers for authentication, while “grandfathering-in” the
> client_secret parameter to simplify the most common current practice.
>
> 3. Leave is underspecified, relying on the presence of extension parameters
> or authentication headers for other credentials types.
>
>
>
> Thoughts?
>
>
>
> EHL
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 28 Jun 2010 12:24:51 -0700

While the AS implementor can infer the request by the parameters, I prefer the programmer explicitly state what she is doing. Thinking of it as a method parameter rather than a type parameter makes more sense to me. Similiarly, HTTP has GET, POST, PUT etc. even though you could differentiate between them by looking at what was passed or not passed.

-- Dick

On 2010-06-28, at 10:39 AM, Eran Hammer-Lahav wrote:

> While I don’t believe a grant or credential type parameter is needed – the type can be deduced from the other parameters present – we now treat the same requirement with a different solution. I think this creates a broken environment for extensibility (which is my current focus).
>  
> At the same time, introducing such a parameter can conflict with the standard HTTP authentication mechanism. For example, a request containing both “client_credentials_type=basic” and the HTTP Authorization header seems odd.
>  
> 2. Only allow HTTP headers for authentication, while “grandfathering-in” the client_secret parameter to simplify the most common current practice.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 28 Jun 2010 21:25:46 +0200

what size do you expect? SPNEGO authentication headers can be up to 
12392 bytes and this does not seem to be a problem.

regards,
Torsten.

---

From: Yaron Goland <[email-masked]>
Date: Mon, 28 Jun 2010 22:15:11 +0000

We regularly deal with SAML assertions that easily go into the 100s of K. This is far more than most HTTP servers will accept. So we are pretty much required to use the body.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Torsten Lodderstedt
> Sent: Monday, June 28, 2010 12:26 PM
> To: Marius Scurtescu
> Cc: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Client credentials type
> 
> >> - the type can be deduced from the other parameters present - we now

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 28 Jun 2010 18:42:20 -0700

I don't care about the name (type vs method). Are there any objection to defining a parameter for the client authentication method? Any views about using this parameter with an HTTP authorization header?

EHL

From: Dick Hardt [mailto:[email-masked]]
Sent: Monday, June 28, 2010 12:25 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Client credentials type

-- Dick

Thoughts?

EHL
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Luke Shepard <[email-masked]>
Date: Mon, 28 Jun 2010 20:02:06 -0700

For what it's worth, I (Facebook) would not require my clients to specify a type. It's fine to discuss it in the docs and examples, but if a client passed in a request without a type, I would probably try to infer the grant type from the request rather than throwing an error.

Besides the purity of the spec, would anyone object to a server that tried to play nice by its clients?

On Jun 28, 2010, at 6:42 PM, Eran Hammer-Lahav wrote:

I don’t care about the name (type vs method). Are there any objection to defining a parameter for the client authentication method? Any views about using this parameter with an HTTP authorization header?

EHL

From: Dick Hardt [mailto:[email-masked]]
Sent: Monday, June 28, 2010 12:25 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Client credentials type

-- Dick

Thoughts?

EHL

<ATT00001..txt>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 28 Jun 2010 20:42:40 -0700

Your approach fits with the "be generous in what you accept" ethos.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 30 Jun 2010 08:49:21 +0200

that's pretty big! Can you please explain what kind of client you  
authenticate with such assertions? They must contain hundreds of  
attributes.

regards,
Torsten.

Zitat von Yaron Goland <[email-masked]>:

> We regularly deal with SAML assertions that easily go into the 100s  
> of K. This is far more than most HTTP servers will accept. So we are  
> pretty much required to use the body.
>

---

From: Yaron Goland <[email-masked]>
Date: Thu, 1 Jul 2010 00:38:53 +0000

Or just a bit of XML signatures and encryption. The byte bloat is astounding.

		Yaron

> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Tuesday, June 29, 2010 11:49 PM
> To: Yaron Goland
> Cc: Marius Scurtescu; OAuth WG ([email-masked])
> Subject: RE: [OAUTH-WG] Client credentials type
> 
> that's pretty big! Can you please explain what kind of client you authenticate
> with such assertions? They must contain hundreds of attributes.
> 
> regards,
> Torsten.
> 
> > We regularly deal with SAML assertions that easily go into the 100s of
> > K. This is far more than most HTTP servers will accept. So we are
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Torsten Lodderstedt
> >> > assertion could be a SAML assertion, and these could be too large
> >> > for headers.
> >> >
> >> > I think #1 makes sense.
> >> >
> >> > Marius
> >> >
> >> >
> >> >
> >> >> I would prefer (2) since authorization headers are the natural way
> >> >> to handle authentication in HTTP. Different client credential
> >> >> mechanisms can be represented by different authentication scheme
> >> >> (even custom-defined). HTTP libraries typically have special
> >> >> support for handling such headers and it keeps the authentication
> >> >> mechanism orthogonal of the API. Moreover, authorization headers
> >> >> very well work together with status code 401 and WWW-Authenticate
> >> >> headers. Using WWW-Authenticate headers, an authz server can
> >> >> easily signal what mechanisms (multiple WWW-Authenticate headers
> >> >> are allowed in a single
> >> >> Yaron Goland offered a proposal for an additional client
> >> >> credentials mechanism based on assertion. His proposal raises the
> >> >> issue of differentiating between the different kind of credentials
> >> >> used. When it comes to access grant types, this group argued for
> >> >> being explicit and providing a parameter declaring the grant type
> >> >> being used (even though it is not technically necessary).
> >> >>
> >> >>
> >> >>
> >> >> - the type can be deduced from the other parameters present - we
> >> >> now treat the same requirement with a different solution. I think
> >> >> this creates a broken environment for extensibility (which is my
> >> >> current
> >> focus).
> >> >>
> >> >>
> >> >>
> >> >> At the same time, introducing such a parameter can conflict with
> >> >> the standard HTTP authentication mechanism. For example, a request

---

From: Yaron Goland <[email-masked]>
Date: Thu, 1 Jul 2010 00:41:39 +0000

Oh and don't forget fun things like including the full cert chain which after encoding also bloats to amazing heights.

> Of Yaron Goland
> Sent: Wednesday, June 30, 2010 5:39 PM
> To: Torsten Lodderstedt
> > >> >> I would prefer (2) since authorization headers are the natural
> > >> >> way to handle authentication in HTTP. Different client
> > >> >> credential mechanisms can be represented by different
> > >> >> authentication scheme (even custom-defined). HTTP libraries
> > >> >> typically have special support for handling such headers and it
> > >> >> keeps the authentication mechanism orthogonal of the API.
> > >> >> Moreover, authorization headers very well work together with
> > >> >> status code 401 and WWW-Authenticate headers. Using
> > >> >> credentials mechanism based on assertion. His proposal raises
> > >> >> the issue of differentiating between the different kind of
> > >> >> credentials used. When it comes to access grant types, this
> > >> >> group argued for being explicit and providing a parameter
> > >> >> declaring the grant type being used (even though it is not technically
> necessary).
> > >> >>
> > >> >>
> > >> >>
> > >> >> now treat the same requirement with a different solution. I
> > >> >> think this creates a broken environment for extensibility (which
> > >> >> is my current
> > >> focus).
> > >> >>
> > >> >>
> > >> >>
> > >> >> the standard HTTP authentication mechanism. For example, a
> > >> >> request containing both "client_credentials_type=basic" and the
> > >> >> HTTP Authorization header seems odd.
> > >> >>
> > >> >>
> > >> >>