Subject: [OAUTH-WG] Removal: Client Assertion Credentials

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 14 Jan 2011 23:45:14 -0700

I would like to suggest we drop the client assertion credentials (-11 section 3.2) from the specification, and if needed, publish it as a separate specification for the following reasons:

1.       The mechanism is under specified, especially in its handling of the client_id identifier (when used to obtain end-user authorization). It does not contain any implementation details to accomplish any level of interoperability or functionality. This is in contrast to the assertion grant type which has matured over a year into a fully thought-out extension mechanism, as well as a separate SAML assertion specification with active deployment (the two, together with running code, show clear consensus).

2.       The section is a confused mix of security considerations sprinkled with normative language. Instead, it should be replaced with guidelines for extending the set of supported client credentials, but without defining a new registry. It is clearly an area of little deployment experience for OAuth, and that includes using HTTP Basic authentication for client authentication (more on that to come).

3.       The section has received a little support and a little objection. Those who still want to advocate for it need to show not only consensus for keeping it, but also active community support for deploying it. Deployment, of course, will also require showing progress on public specifications profiling the mechanism into a useful interoperable feature.

Comments? Counter-arguments?

EHL

---

From: Phillip Hunt <[email-masked]>
Date: Sat, 15 Jan 2011 00:51:59 -0800

A strong client credential is needed in many cases. I had assumed client assertion would fulfill this need. 

Phil

Sent from my phone. 

On 2011-01-14, at 22:45, Eran Hammer-Lahav <[email-masked]> wrote:

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 15 Jan 2011 12:32:23 -0700

You still need to define it. The two parameters don’t accomplish anything since you can’t use them without a more detailed specification, in which case, what is the value of this? Where is the interoperability gain?

This is clearly not a feature that is likely to be implemented in any general purpose library, unlike the ‘scope’ parameter which is under-defined but still useful for library support.

Including it in the specification is confusing (the unanimous feedback I received so far), without any benefit. The specification provides a clear extension mechanism for new parameters. Why is that not enough?

EHL

From: Phillip Hunt [mailto:[email-masked]]
Sent: Saturday, January 15, 2011 12:52 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials

Phil

Sent from my phone.

On 2011-01-14, at 22:45, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
I would like to suggest we drop the client assertion credentials (-11 section 3.2) from the specification, and if needed, publish it as a separate specification for the following reasons:

EHL

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

---

From: Phillip Hunt <[email-masked]>
Date: Sat, 15 Jan 2011 12:06:50 -0800

It just needs to be defined properly. I was speaking only to the requirement. Not whether what is spec'd now is good or not. 

I will blog more on this shortly. 

Cheers,

Phil

Sent from my phone.

---

From: David Recordon <[email-masked]>
Date: Sun, 16 Jan 2011 12:36:58 -0800

Seems good enough to me. +1 to removing it so that it will become fully
fleshed out in a useful manner.

On Sat, Jan 15, 2011 at 11:32 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> You still need to define it. The two parameters don’t accomplish anything
> since you can’t use them without a more detailed specification, in which
> case, what is the value of this? Where is the interoperability gain?
>
>
>
> This is clearly not a feature that is likely to be implemented in any
> general purpose library, unlike the ‘scope’ parameter which is under-defined
> but still useful for library support.
>
>
>
> Including it in the specification is confusing (the unanimous feedback I
> received so far), without any benefit. The specification provides a clear
> extension mechanism for new parameters. Why is that not enough?
>
>
>
> EHL
>
>
>
> *From:* Phillip Hunt [mailto:[email-masked]]
> *Sent:* Saturday, January 15, 2011 12:52 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Removal: Client Assertion Credentials
>
>
>
> I would like to suggest we drop the client assertion credentials (-11
> section 3.2) from the specification, and if needed, publish it as a separate
> specification for the following reasons:
>
>
>
> 1.       The mechanism is under specified, especially in its handling of
> the client_id identifier (when used to obtain end-user authorization). It
> does not contain any implementation details to accomplish any level of
> interoperability or functionality. This is in contrast to the assertion
> grant type which has matured over a year into a fully thought-out extension
> mechanism, as well as a separate SAML assertion specification with active
> deployment (the two, together with running code, show clear consensus).
>
> 2.       The section is a confused mix of security considerations
> sprinkled with normative language. Instead, it should be replaced with
> guidelines for extending the set of supported client credentials, but
> without defining a new registry. It is clearly an area of little deployment
> experience for OAuth, and that includes using HTTP Basic authentication for
> client authentication (more on that to come).
>
> 3.       The section has received a little support and a little objection.
> Those who still want to advocate for it need to show not only consensus for
> keeping it, but also active community support for deploying it. Deployment,
> of course, will also require showing progress on public specifications
> profiling the mechanism into a useful interoperable feature.
>
>
>

---

From: Francisco Corella <[email-masked]>
Date: Sun, 16 Jan 2011 23:31:08 -0800 (PST)

I wanted to point out that an assertion by itself cannot
authenticate the client, contrary to what the draft seems to
imply.

Section 3.2 of the spec says that, when using a client
assertion, the client sends two parameters:
client_assertion_type and client_assertion.  This does not
work.  A client assertion will typically bind a public key
to some information about the client.  Sending the assertion
will not by itself authenticate the client.  The client must
also demonstrate that it owns the corresponding private key.

To look at it from a different angle, section 3.2 also says:

> The assertion format, the process by which the assertion is
> obtained, and the method of validating the assertion are
> defined by the assertion issuer and the authorization
> server, and are beyond the scope of this specification.

This misses an essential element of an assertion, what the
SAML spec calls "subject confirmation" (section 2.4.1.1).
Subject confirmation is not a private matter between the
assertion and the authorization server, it must also involve
the client, and hence it must be an integral part of the
protocol.

Another thing that's wrong is that the client assertion is
obtained too late in the protocol flow.  An assertion can
provide information that the server can use to identify the
client application to the user as it authenticates the user
and asks for permission to grant the client application's
request.  But that has already been done by the time the
server obtains the assertion.

On the other hand I like assertions because they could
help identify unregistered applications, which is what I'm
trying to achieve with my PKAuth protocol.  So I'm thinking
about adding them to PKAuth.  That should be easy, because
in PKAuth the client authenticates itself by presenting its
TLS certificate and demonstrating knowledge of the
corresponding private key in a TLS handshake.  An assertion
can then simply bind additional information to the
certificate, and "subject confirmation" is already taken
care of.

Francisco

--- On Sun, 1/16/11, David Recordon <[email-masked]> wrote:

From: David Recordon <[email-masked]>
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials
To: "Eran Hammer-Lahav" <[email-masked]>
Cc: "OAuth WG" <[email-masked]>
Date: Sunday, January 16, 2011, 8:36 PM

Seems good enough to me. +1 to removing it so that it will become fully fleshed out in a useful manner.

On Sat, Jan 15, 2011 at 11:32 AM, Eran Hammer-Lahav <[email-masked]> wrote:

 Comments? Counter-arguments? EHL  

OAuth mailing list

[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 17 Jan 2011 01:06:17 -0700

One more reason to remove the half-baked text from the spec and reintroduce it with a full specification elsewhere.

EHL

From: Francisco Corella [mailto:[email-masked]]
Sent: Sunday, January 16, 2011 11:31 PM
To: Eran Hammer-Lahav; David Recordon
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials

Francisco

--- On Sun, 1/16/11, David Recordon <[email-masked]<mailto:[email-masked]>> wrote:

From: David Recordon <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials
To: "Eran Hammer-Lahav" <[email-masked]<mailto:[email-masked]>>
Cc: "OAuth WG" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, January 16, 2011, 8:36 PM
Seems good enough to me. +1 to removing it so that it will become fully fleshed out in a useful manner.

On Sat, Jan 15, 2011 at 11:32 AM, Eran Hammer-Lahav <[email-masked]</mc/compose?to=[email-masked]>> wrote:

EHL

From: Phillip Hunt [mailto:[email-masked]</mc/compose?to=[email-masked]>]
Sent: Saturday, January 15, 2011 12:52 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials

Phil

Sent from my phone.

On 2011-01-14, at 22:45, Eran Hammer-Lahav <[email-masked]</mc/compose?to=[email-masked]>> wrote:

EHL

_______________________________________________
OAuth mailing list
[email-masked]</mc/compose?to=[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]</mc/compose?to=[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

-----Inline Attachment Follows-----
_______________________________________________
OAuth mailing list
[email-masked]</mc/compose?to=[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Mon, 17 Jan 2011 10:17:47 -0800

What if strong authentication of client (between client and AM) happened OOB? Instead of passing a client_assertion, why not pass a client_token? In a sense we would be repeating the pattern for users and applying it to clients.  A client use its own client_token to obtain access tokens.

I can see this approach having an advantage when a client is a web service supporting multiple end-users.  It could re-use its own authentication tokens many times and wouldn't have to incur an expensive strong-authentication every time it handles an OAuth token request.

The only concern I see with this, is whether a bearer token would work. You'd want to strongly bind the client with the token. IMHO

Phil
[email-masked]

---

From: Francisco Corella <[email-masked]>
Date: Mon, 17 Jan 2011 23:28:03 -0800 (PST)

Phil,

> What if strong authentication of client (between client and
> AM) happened OOB? Instead of passing a client_assertion, why
> not pass a client_token? In a sense we would be repeating
> the pattern for users and applying it to clients.  A client
> use its own client_token to obtain access tokens.

Interesting question.  Two answers:

1. That works, but the client_token is then a shared secret
between client and server, and there is no difference with a
client password established by registration of the client
with the server.  Registration is an out-of-bound process
that establishes a shared secret.  The registration process
can use a SAML assertion.

2. The best answer, though, is that client authentication
after the double redirection (after the client redirects the
user to the server for user authentication, and the server
redirects the user back to the client with the authorization
code) only provides an illusion of security.

Security hinges on the fact that the authorization code goes
to the legitimate client.  If it goes to an attacker, the
attacker can send the authorization code to the client from
its own browser, thus impersonating the legitimate user.
The client will send the authorization code to the server to
get an access token, and use the access token to access the
legitimate user's resources for the benefit of the attacker.
It does not matter how strongly the client authenticates
itself to the server; the legitimate client is now working
for the attacker!

And if the authorization code is guaranteed to go to the
legitimate client, there is no need for the client to
authenticate itself to the server.

Actually, client authentication after redirection is not
completely useless.  It can help limit the damage done by a
successful attack.  Here's how that goes.

Without client authentication after the double redirection,
if an attacker somehow gets the authorization code, he/she
can do two kinds of damage:

(i) he/she can use it to get an access token from the server
(masquerading as a legitimate client vis-a-vis the server)
and thus gain direct access to the legitimate user's
resources, and

(ii) he/she can use it to impersonate the legitimate user
and log in to the client (in the common case where the
client uses OAuth for "social login" a la Facebook Connect;
the client will log the user in after successfully
exchanging the authorization code for an access token).

With client authentication after the double redirection, the
attacker can do less damage after a successful attack.  

The attacker can try to get the authorization code in two
different ways:

(1) by setting up a bogus client that masquerades as the
legitimate client vis-a-vis the user, and tricking the user
into granting access to the bogus client; or

(2) by somehow intercepting the authorization code as the
server sends it to the legitimate client.

If the attacker gets the authorization code by method (1),
the attacker can do damage (i), but cannot do damage (ii)
because, when the legitimate client tries to verify the
authorization code by sending it to the server, the server
will detect that the authorization code was not sent to the
legitimate client (it was sent to the bogus client); the
server will not send the access token, and the legitimate
client will not log in the attacker.

If the attacker obtained the authorization code by method
(2), the attacker can do damage (ii), but cannot do damage
(i) because the attacker will not be able to exchange the
authorization code for an access token, given that the
authorization code was sent to the legitimate client and the
server wants the authorization code to be presented by
whichever client it was sent to.

Francisco

---

From: Phillip Hunt <[email-masked]>
Date: Tue, 18 Jan 2011 05:31:16 -0800 (PST)

Not sure I agree. Yes shared secret  But one may be long lived (permanent) while the other may be good for minutes. If a server has both what then? I suppose we could detect type in client_secret or do it by policy associated with a client_id. Is that what is intended in the spec?

As you say "
> to the legitimate client
". Somewhere we should be talking about the importance of this. Too many current implementations are using permanent shared secrets which as we know are not secrets. 

Phil

Sent from my phone.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 19 Jan 2011 09:28:44 +0200

Hi Eran, 
Hi all, 

I would like to start a working group last call on the base specification soon and the writeup in Section 3.2 about the Client Assertion Credentials is, unfortunately, not ready yet. Particularly the missing security discussion scares me. 

Hence, I would encourage someone to take the text from that section and to produce a new draft that also includes a reasonable security description. Do we have a volunteer?

Ciao
Hannes

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 25 Jan 2011 23:58:10 +0000

I don't understand the rationale for removing the client assertion credentials, as client password authentication is left in. Client Password Authentication is also underspecified as client_secret could be anything that the authentication server seems fit (raw clear text password,  hash, digest, etc.) and no way to determine the content. client_secret is also a very weak mechanism, since this is left in the core this leads me to believe that there is support for having client authentication in Oauth. I don't see how having client_assertion and client_assertion_type would be something that is underspecified as being a mechanism in which assertions can be used for authentication. Agree that the authentication server has to make right and declare what is being used but that is the same for client password authentication. The client authentication assertions are something that Microsoft and Google find useful and plan on implementing and using as a means for stronger authentication to the authorization server. This extensibility belongs in the core, there is no other place to put this functionality. I don't believe that the removal (either by editor or direction by co-chair) is something that should have been done w/o a consensus vote since this has been in the specification for some time without issue and the removal comes as complete unwelcome surprise. Getting almost total rewrites of the specification this late in the review cycle is also very disturbing.

A proposal for keeping the client authentication assertion would be to simplify to the following;

The client assertion credentials are used in cases where a password (clear-text shared symmetric secret) is unsuitable or does not provide sufficient security for client authentication. The client assertion credentials provide an extensible mechanism to use an assertion format supported by the authorization server for authentication of the client.

Using assertions requires the client to obtain an assertion (such as a SAML (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) [OASIS.saml‑core‑2.0‑os] assertion) from an assertion issuer or to self-issue an assertion. The assertion format, the process by which the assertion is obtained, and the method of validating the assertion are defined by the assertion issuer and the authorization server, and are beyond the scope of this specification.

When using a client assertion, the client includes the following parameters:
client_assertion_type - REQUIRED. The format of the assertion as defined by the authorization server. The value MUST be an absolute URI.
client_assertion - REQUIRED. The client assertion.

For example, the client sends the following access token request using a SAML 2.0 assertion to authenticate itself (line breaks are for display purposes only):

  POST /token HTTP/1.1

  Host: server.example.com

  Content-Type: application/x-www-form-urlencoded

  grant_type=authorization_code&code=i1WsRn1uB1&

  client_assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D&

  client_assertion_type=  urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:45 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: Client Assertion Credentials

EHL

---

From: David Recordon <[email-masked]>
Date: Tue, 25 Jan 2011 17:11:08 -0800

Explicitly saying, "The assertion format, the process by which the assertion
is obtained, and the method of validating the assertion are defined by the
assertion issuer and the authorization server, and are beyond the scope of
this specification" seems to reinforce the point about this being
underspecified. This would still require a second document which describes
the data within the SAML assertion as well as how it maps back to a
client_id.

On the process side, IIRC this was added to the spec without any consensus
and over some reservations by Eran...which was a broken process to begin
with and a poor decision on his part. I share Hannes' desire to move this
base spec to last call. Worried that leaving this text in is going to delay
that whereas moving it to a separate document published by the OAuth WG will
still lead toward market adoption of a more fully specified feature.

--David

On Tue, Jan 25, 2011 at 3:58 PM, Anthony Nadalin <[email-masked]>wrote:

>  I don't understand the rationale for removing the client assertion
> credentials, as client password authentication is left in. Client Password
> Authentication is also underspecified as client_secret could be anything
> that the authentication server seems fit (raw clear text password,  hash,
> digest, etc.) and no way to determine the content. client_secret is also a
> very weak mechanism, since this is left in the core this leads me to believe
> that there is support for having client authentication in Oauth. I don't see
> how having client_assertion and client_assertion_type would be something
> that is underspecified as being a mechanism in which assertions can be used
> for authentication. Agree that the authentication server has to make right
> and declare what is being used but that is the same for client password
> authentication. The client authentication assertions are something that
> Microsoft and Google find useful and plan on implementing and using as a
> means for stronger authentication to the authorization server. This
> extensibility belongs in the core, there is no other place to put this
> functionality. I don't believe that the removal (either by editor or
> direction by co-chair) is something that should have been done w/o a
> consensus vote since this has been in the specification for some time
> without issue and the removal comes as complete unwelcome surprise. Getting
> almost total rewrites of the specification this late in the review cycle is
> also very disturbing.
>
>
>
> The client assertion credentials are used in cases where a password
> (clear-text shared symmetric secret) is unsuitable or does not provide
> sufficient security for client authentication. The client assertion
> credentials provide an extensible mechanism to use an assertion format
> supported by the authorization server for authentication of the client.
>
> Using assertions requires the client to obtain an assertion (such as a SAML
> (Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol
> for the OASIS Security Assertion Markup Language (SAML) V2.0," March 2005.)<#12dbf9d29a2ee7cd_OASIS.saml-core-2.0-os>[OASIS.saml-core-2.0-os] assertion) from an assertion issuer or to
> self-issue an assertion. The assertion format, the process by which the
> assertion is obtained, and the method of validating the assertion are
> defined by the assertion issuer and the authorization server, and are beyond
> the scope of this specification.
>
> client_assertion_type - REQUIRED. The format of the assertion as defined
> by the authorization server. The value MUST be an absolute URI.
>
> For example, the client sends the following access token request using a
> SAML 2.0 assertion to authenticate itself (line breaks are for display
> purposes only):
>
>
>
>
>
>   POST /token HTTP/1.1
>
>   Host: server.example.com
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Eran Hammer-Lahav
> *Sent:* Friday, January 14, 2011 10:45 PM
> *To:* OAuth WG
> *Subject:* [OAUTH-WG] Removal: Client Assertion Credentials
>
>
>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 26 Jan 2011 01:31:35 +0000

Based on your logic then Scope, Client Password Authentication, etc, should be removed. Not sure how leaving the proposed text in would delay things

From: David Recordon [mailto:[email-masked]]
Sent: Tuesday, January 25, 2011 5:11 PM
To: Anthony Nadalin; [email-masked]; Eran Hammer-Lahav
Cc: OAuth WG; Blaine Cook
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials

Explicitly saying, "The assertion format, the process by which the assertion is obtained, and the method of validating the assertion are defined by the assertion issuer and the authorization server, and are beyond the scope of this specification" seems to reinforce the point about this being underspecified. This would still require a second document which describes the data within the SAML assertion as well as how it maps back to a client_id.

On the process side, IIRC this was added to the spec without any consensus and over some reservations by Eran...which was a broken process to begin with and a poor decision on his part. I share Hannes' desire to move this base spec to last call. Worried that leaving this text in is going to delay that whereas moving it to a separate document published by the OAuth WG will still lead toward market adoption of a more fully specified feature.

--David

On Tue, Jan 25, 2011 at 3:58 PM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:

  POST /token HTTP/1.1

  Host: server.example.com<http://server.example.com>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:45 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: Client Assertion Credentials

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 25 Jan 2011 18:37:31 -0700

Can you share with the list how you plan to use this client assertion authentication scheme?
Which of the authorization grant types you will use it with?
Will you use it with the authorization endpoint, and if so, how will you bind the assertion to the client_id?
Can you provide full examples of assertions and HTTP requests?

It would be helpful to see how far apart the proposed text below is from an actual implementation making use of it. I except to see these answers in any quality document defining a new client authentication scheme (which is true for the client password authentication throughout the document).

EHL

From: Anthony Nadalin [mailto:[email-masked]]
Sent: Tuesday, January 25, 2011 3:58 PM
To: Eran Hammer-Lahav; OAuth WG; [email-masked]; Blaine Cook
Subject: RE: Removal: Client Assertion Credentials

  POST /token HTTP/1.1

  Host: server.example.com

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 25 Jan 2011 19:11:06 -0700

Scope was discussed in detail, including use cases and implementation experience and the current language was (painfully) negotiated to reach a balance between flexibility and library interoperability. Client password authentication is well understood, is the primary way API calls are authenticated on the web today (API key and secret), it is how OAuth 1.0 defined client authentication, and enjoys numerous examples throughout the specification for each authorization grant type. Got other examples?

Adding the proposed text in is not an option given the objections raised. This process argument is moot because whether we put it back in or not before we reach consensus on the language, it will take the same amount of time to do just that – reach consensus. Drafting another spec will give us the time to properly discuss it and reach a useful, fully specified document with examples and other details that otherwise will delay this document. We followed this exact process for the SAML assertions specification.

In addition, everything in the spec right now is specified in enough detail to write the security consideration section. I have no clue how anyone can describe the security characteristics of this proposed text given that it has absolutely no details helpful to evaluate its security properties. This makes your opening paragraph in the proposed text someone of a tongue in cheek. “When passwords are not enough, use this strong and completely undefined method”.

We will only make progress on this if you stop trying to use process arguments (since as David pointed out, this was put into the spec in violation of our process and I apologize for that), and start working towards a language the WG can agree on.

EHL

From: Anthony Nadalin [mailto:[email-masked]]
Sent: Tuesday, January 25, 2011 5:32 PM
To: David Recordon; [email-masked]; Eran Hammer-Lahav
Cc: OAuth WG; Blaine Cook
Subject: RE: [OAUTH-WG] Removal: Client Assertion Credentials

--David

  POST /token HTTP/1.1

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 26 Jan 2011 21:52:06 +0000

Maybe this was the plan all along but specification is becoming useless for our scenarios and will require that we have to go well beyond the core specification to make things work, the client assertion credentials being a prime example. The client assertion credentials has been around for a while as it was a requirement for WRAP, then dropped when the various specs got merged to form OAUTH 2.0 and then came back into the OAUTH 2.0 and then has gone through various changes since version 6 for the worse. There has been much discussion in July/August over this and new text was proposed, but that seems to not be fully accepted, but I think that follows the path when you want to remove something.

Our usage will be via bearer token assertions only (at this time)
The grant_type would be the URI of the assertion type being used
The authorization endpoint can use what it wants to bind the assertion to the client_id, much like it has to today for the password authentication, as we have scenarios were client_id have multiple passwords
We use guidance from security consideration section of the assertion type being used along with the guidance from the bearer token specification
If needed I can capture the assertions and requests, but not sure what the point of this is at this time since this is not required for the password credentials

Sure we can add the client authentication assertion to the bearer token specification but I don’t think that is the proper place to do thus but since it’s gone from the core we will have to do just that. The same seems to happen with the HTTP Authentication Scheme as it seems to be repeated in follow-on companion specifications. While oauth-v2 is not an authentication protocol there is a requirement for authentication to address security concerns. There is clear separation between authentication and authorization; we are not suggesting that authentication is appropriate facility to negotiate authorization. I think that it makes sense to include a scheme in the core and have the particular follow-on companion specifications (the various token specifications) state/define the parameters and if they don’t like the default scheme let them define a new scheme but this puts a stake in the ground for an HTTP Authentication Scheme.

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Tuesday, January 25, 2011 5:38 PM
To: Anthony Nadalin
Cc: OAuth WG
Subject: RE: Removal: Client Assertion Credentials

EHL

From: Anthony Nadalin [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, January 25, 2011 3:58 PM
To: Eran Hammer-Lahav; OAuth WG; [email-masked]<mailto:[email-masked]>; Blaine Cook
Subject: RE: Removal: Client Assertion Credentials

  POST /token HTTP/1.1

  Host: server.example.com

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:45 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: Client Assertion Credentials

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 26 Jan 2011 21:56:07 +0000

The client aut6hetication assertion was also discussed many times and a lot in the July/August time frame. I don’t believe that the introduction of client assertion was a violation as this came from the merge of WRAP into OAUTH 2.0 and has been there for many drafts and then all of a sudden to drop it is just poor practice.

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Tuesday, January 25, 2011 6:11 PM
To: Anthony Nadalin
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Removal: Client Assertion Credentials

EHL

To: David Recordon; [email-masked]<mailto:[email-masked]>; Eran Hammer-Lahav

From: David Recordon [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, January 25, 2011 5:11 PM
To: Anthony Nadalin; [email-masked]<mailto:[email-masked]>; Eran Hammer-Lahav
Cc: OAuth WG; Blaine Cook
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials

--David

  POST /token HTTP/1.1

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 15:51:24 -0700

Can you explain how having to define *two* extension parameters makes the specification useless? The bearer token specification is going to define its corresponding WWW-Authenticate header, to match its already defined Authorization header. The scheme name is just style and branding and have absolutely no technical impact. I am honestly confused by your comments, as I was in the past when you declared the entire protocol useless because of my objections to an under-defined scope parameter.

Can you point me where in WRAP are the client assertion credentials defined? I can only find the assertion profile which is comparable to the extension grant type with the SAML assertion extension (where the assertion parameter is defined and registered). The concept of the client assertion used for client authentication (separate from the authorization grant) is new and was added based on a proposal from Yaron in -11 on December 1st, 2010.

As for your additional details below (thanks!), it seems like you are not using the client assertion credentials at all but using a simple extension grant with an assertion, exactly like the SAML extension grant specification, only you are not limited to SAML 2.0. Is that correct? If this is correct, then the only issue here is our decision (which was made without any comment from you or those now raising issues about this) to move the ‘assertion’ parameter and rename the grant type from assertion to extension (which has no implementation impact). All we did is relocate the assertion parameter because it doesn’t always apply to extension grants.

Is this just a confusion about what was being removed and where it went?

EHL

From: Anthony Nadalin [mailto:[email-masked]]
Sent: Wednesday, January 26, 2011 1:52 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: RE: Removal: Client Assertion Credentials

EHL

  POST /token HTTP/1.1

  Host: server.example.com

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 28 Jan 2011 19:55:55 +0000

I said its “becoming” useless as more and more stuff is being removed.

Maybe you did not understand or I did not tell you everything you needed to know, we have endpoints that expect assertions along with the grant_type of authorization_code and we also have endpoints that expect the grant_type of URI (or the assertion, which could be whatever the authorization server decides), these are 2 different endpoints with 2 different functions. The change that was made to remove the notion of client assertion credentials only left us with the extension so we can live with the changes to the extension (it is a code change for us) but not removal of client assertion credentials we can’t live with as we are using the notion of client credentials. I’m not sure that putting this in the bearer token specification would work.

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Wednesday, January 26, 2011 2:51 PM
To: Anthony Nadalin
Cc: OAuth WG
Subject: RE: Removal: Client Assertion Credentials

EHL

From: Eran Hammer-Lahav [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, January 25, 2011 5:38 PM
To: Anthony Nadalin
Cc: OAuth WG
Subject: RE: Removal: Client Assertion Credentials

EHL

  POST /token HTTP/1.1

  Host: server.example.com

EHL

---

From: Phil Hunt <[email-masked]>
Date: Fri, 28 Jan 2011 12:16:30 -0800

Tony,

I'm not totally understanding what the issue is as far as impact on code. My understanding was that the removal simply took it out of the standard but is still covered by "other authentication mechanism".  Thus no impact on code -- you can still use (as we will) the client_assertion form parameter. That said, I very much agree with your concerns.

It may be worthwhile for us to work on a profile that lays out the specifics of using client_assertion or client_token in a separate specification. Just as there will be multiple access token formats, I expect to see multiple client authentication methods.  Maybe client auth methods should also be defined in a registry? Though, I don't see this as necessarily an OAuth specific issue. There's a much broader requirement for defining client auth beyond Basic, Digest, Mutual SSL, etc for non-browser clients. 

As for value with OAuth, I think OAuth describe an important "pattern" and won't have much general impact on inter-operability as a standard. Thus doesn't undervalue the standard that much as it lays a foundation for other components. The key working inter-op components will likely have be defined in subsequent related specs such as suggested above.

What is not clear to me yet is what should the discovery and registration components for OAuth be? How much should be defined in deployment documentation? Deployment documentation is problematic for development tools. For example, building a .Net or Java platform is much different than a one time developer who just wants to access a single google, facebook, etc service.  In contrast, .Net/Java tools can't help much since they can't inspect the service. 

I agree, too much emphasis is on deployment docs for use of OAuth.

Phil
[email-masked]

On 2011-01-28, at 11:55 AM, Anthony Nadalin wrote:

> Using assertions requires the client to obtain an assertion (such as a SAML (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.)[OASIS.saml‑core‑2.0‑os] assertion) from an assertion issuer or to self-issue an assertion. The assertion format, the process by which the assertion is obtained, and the method of validating the assertion are defined by the assertion issuer and the authorization server, and are beyond the scope of this specification.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 28 Jan 2011 14:01:25 -0700

Thanks for the additional details.

I agree that including the two parameters in the bearer token specification makes no sense at all.

I would like to suggest you take the proposed language, expand it buy including more details guidelines for the binding of the client_id to the assertion, and define at least one useful profile based on your current deployment such as a SAML 2.0 client assertion. This will be published in a new I-D with a well defined security consideration section focused solely on the use of client assertions for authenticating the client. Once you have this document published, the working group can have a quick consensus call to do one of three options:

 1.  Decide to incorporate the draft into v2 given its sufficient details, specificity, examples, and security considerations. We have about 2-3 months window to make this change before shipping the spec to an IETF LC. This will require a draft published within a month.
 2.  Decide to keep it as a standalone extension, but as a WG item.
 3.  Decide to keep it as an individual submission (with IANA registration of the two new parameters).

I am open to all three options and will do my best to provide feedback and assistance, as soon as a new text is proposed that includes the above details.

EHL

On 1/28/11 11:55 AM, "Anthony Nadalin" <[email-masked]> wrote:

EHL

EHL

Using assertions requires the client to obtain an assertion (such as a SAML (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) <#OASIS.saml-core-2.0-os> [OASIS.saml‑core‑2.0‑os] assertion) from an assertion issuer or to self-issue an assertion. The assertion format, the process by which the assertion is obtained, and the method of validating the assertion are defined by the assertion issuer and the authorization server, and are beyond the scope of this specification.

  POST /token HTTP/1.1
  Host: server.example.com

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 28 Jan 2011 14:06:31 -0700

FWIW, I plan to include an OAuth client authentication binding in my MAC specification in the next version.

EHL

On 1/28/11 12:16 PM, "Phil Hunt" <[email-masked]> wrote:

Tony,

Phil
[email-masked]

EHL

EHL

Using assertions requires the client to obtain an assertion (such as a SAML (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) <x-msg://93/#OASIS.saml-core-2.0-os> [OASIS.saml‑core‑2.0‑os] assertion) from an assertion issuer or to self-issue an assertion. The assertion format, the process by which the assertion is obtained, and the method of validating the assertion are defined by the assertion issuer and the authorization server, and are beyond the scope of this specification.

  POST /token HTTP/1.1
  Host: server.example.com <http://server.example.com/>
 Content-Type: application/x-www-form-urlencoded

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Sat, 29 Jan 2011 00:02:43 +0000

Code impact was that assertion_type was moved/changed to grant_type, we actually need client_assertion and client_assertion_type and not have to overload the grant_type as assertion_type, I can why this was done for allowing one to use assertions in general for authentcations

From: Phil Hunt [mailto:[email-masked]]
Sent: Friday, January 28, 2011 12:17 PM
To: Anthony Nadalin
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials

Tony,

Phil
[email-masked]<mailto:[email-masked]>

EHL

EHL

Using assertions requires the client to obtain an assertion (such as a SAML (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.)<x-msg://93/#OASIS.saml-core-2.0-os>[OASIS.saml‑core‑2.0‑os] assertion) from an assertion issuer or to self-issue an assertion. The assertion format, the process by which the assertion is obtained, and the method of validating the assertion are defined by the assertion issuer and the authorization server, and are beyond the scope of this specification.

  POST /token HTTP/1.1

  Host: server.example.com<http://server.example.com/>

EHL

---

From: Phil Hunt <[email-masked]>
Date: Fri, 28 Jan 2011 17:17:48 -0800

Thanks. I don't believe grant_type can or should indicate how a client must authenticate. The two are unrelated (which is what I think you mean by overloading). Especially since for any particular grant type one could be supporting multiple different ways to authenticate a client.

I know Eran has suggested that client developers would consult deployment documentation. But I don't agree that this is sufficient.

In a token request failure, if the client has failed to authenticate (e.g. due to unsupported authentication type),  the responses should be  a 401 Unauthorized) message indicating acceptable methods (assuming they are all registered).  This is more appropriate since the server did not authenticate the client. It also follows the failure pattern of any other web resource.

Note: I would interpret "unauthorized_client" in 4.1.2.1 as meaning client authenticated but not authorized to perform the operation.

Typically clients should not get 401 unauthorized responses (since, as Eran indicates, they usually know how to authenticate to begin with),  but it would be useful, especially if a deployed site changed it's security policies or configuration. 

Phil
[email-masked]