Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

From: Mike Jones <[email-masked]>
Date: Tue, 18 Jan 2011 17:35:52 +0000

Having spoken to a number of people implementing the spec here, I've encountered strong objections to removing Client Assertion Credentials and the OAuth2 HTTP Authentication Scheme.  It's also not clear to me why we would make substantial breaking changes to the specification when it is essentially ready for approval.  I've summarized the reasons I believe we should keep these two features below.
Client Assertion Credentials:  Many of the scenarios we care about require this capability. They were key motivators for the Assertion Profile in WRAP (see § 5.2), have been part of OAuth 2 for quite a while, and we have running code that requires this support. For example, the Azure Access Control Service is a cloud Authorization server that supports several protocols, including parts of OAuth 2.0 draft 10 (autonomous and web server profiles). We are happy to update our implementation to subsequent drafts & agree that the spec leaves a lot of ambiguity.
In our implementation of the autonomous and web server profiles, ACS allows clients to authenticate using a signed assertion as well as with a username/password. The username/pwd option is for clients that don't mind sending credentials over the wire, while the signed assertion mechanism is for clients that are more reticent to send raw credentials and for scenarios where it isn't possible. To illustrate an example where username/pwd isn't viable, consider the case of a client that needs to use an enterprise identity to gain access to a cloud service. In many cases, corporate policy demands that a client use an identity managed by the organization. This means that the client should obtain an assertion from an enterprise identity provider (Active Directory, Tivoli, etc.) and use that assertion to obtain an access token which grants access to various web service APIs. Many of our key MSFT customers and internal partner teams rely on this mechanism and reverting exclusively to username/pwd isn't an option for us.

'OAuth2' HTTP Authentication Scheme:  Simply put, dropping this seems like a huge step away from interoperability.  As one data point, Microsoft implements this in our WIF OAuth2 protected resource code.  All up, clients need a way to authenticate to the protected resource.  Also, existing WRAP implementations need this functionality to migrate to OAuth2.   For all these reasons, we support retaining this functionality in OAuth2.

                                                            Thanks,
                                                            -- Mike

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 18 Jan 2011 17:42:07 +0000

Agree that these would be code breaking changes and cause interoperability issues late in the specification cycle

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, January 18, 2011 9:36 AM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

                                                            Thanks,
                                                            -- Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 18 Jan 2011 11:12:42 -0700

I agree that at this stage, we should do our best to avoid making breaking changes. But first, we need to establish what is going to break and how.

The argument that removing the client assertion credentials affects interoperability or breaks implementations is without merit.

As currently specified, the text is useless for any level of interoperability or implementation. This means you must have your own specification providing the actual meaningful information. At most, removing this section will require you to register the two parameter names it defines. Since neither is being used for a new purpose, removing this section creates no conflict. Hopefully, your parameter registration will provide more meaningful information about them than currently offered.

If you are going to object to my conclusions, you first need to show where my arguments are wrong. I have seen nothing to contradict a single point I have made about both issues. This goes for both the client assertion credentials and OAuth2 scheme.

Just in case, I'll repeat my points.

Client assertion credentials:

 1.  The mechanism is under specified, especially in its handling of the client_id identifier (when used to obtain end-user authorization).
 2.  It does not contain any implementation details to accomplish any level of interoperability or functionality.
 3.  The section is a confused mix of security considerations sprinkled with normative language.
 4.  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. Which open source library supports or plan to support it?

'OAuth2' WWW-Authenticate header:

 1.  Draft oauth-v2 is clearly not an authentication protocol. It *utilizes* client authentication. It offers one fully defined method for client authentication (which is basically HTTP Basic+), provides a half-baked client assertion authentication hook, and leaves all end-user authentication out of scope.
 2.  The WWW-Authenticate header has absolutely no value, interoperability-wise or otherwise. Discovery was rules to be beyond the scope of this specification. Having a protected resource declare it supports authentication using some unspecified credentials obtained using some unspecified client flow is confusing at best.
 3.  OAuth is agnostic to token authentication, and we already have three discrete token type proposals - all with active deployment plans in the coming months.
 4.  HTTP *authentication* is not an appropriate facility to negotiate *authorization*. OAuth authorization discovery can be added to HTTP authentication schemes as attributes, but makes no sense as a scheme of its own. The issues we are having with 'realm' is one of the examples showing that we are abusing the header.

EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 9:36 AM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

                                                            Thanks,
                                                            -- Mike

---

From: Francisco Corella <[email-masked]>
Date: Tue, 18 Jan 2011 12:26:39 -0800 (PST)

Mike,

As assertion use is described in the spec, a client assertion does not provide any security whatsoever.  How do you handle subject confirmation in your implementation?  (See section 2.4.1.1 of the SAML specification.)  In other words, how does the authorization server know that the client sending the assertion is actually the subject of the assertion?

Francisco

--- On Tue, 1/18/11, Mike Jones <[email-masked]> wrote:

From: Mike Jones <[email-masked]>
Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme
To: "Eran Hammer-Lahav" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tuesday, January 18, 2011, 5:35 PM

Having spoken to a number of people implementing the spec here, I’ve encountered strong objections to removing Client Assertion Credentials and the OAuth2 HTTP Authentication Scheme.  It’s also not clear to me why we would make substantial
 breaking changes to the specification when it is essentially ready for approval.  I’ve summarized the reasons I believe we should keep these two features below. 
 
Client Assertion Credentials:  Many of the scenarios we care about require this capability. They were key motivators for the Assertion Profile in WRAP (see § 5.2), have been part of OAuth 2 for quite a while, and we have running
 code that requires this support. For example, the Azure Access Control Service is a cloud Authorization server that supports several protocols, including parts of OAuth 2.0 draft 10 (autonomous and web server profiles). We are happy to update our implementation
 to subsequent drafts & agree that the spec leaves a lot of ambiguity. 
 
In our implementation of the autonomous and web server profiles, ACS allows clients to authenticate using a signed assertion as well as with a username/password. The username/pwd option is for clients that don’t mind sending credentials
 over the wire, while the signed assertion mechanism is for clients that are more reticent to send raw credentials and for scenarios where it isn’t possible. To illustrate an example where username/pwd isn’t viable, consider the case of a client that needs
 to use an enterprise identity to gain access to a cloud service. In many cases, corporate policy demands that a client use an identity managed by the organization. This means that the client should obtain an assertion from an enterprise identity provider (Active
 Directory, Tivoli, etc.) and use that assertion to obtain an access token which grants access to various web service APIs. Many of our key MSFT customers and internal partner teams rely on this mechanism and reverting exclusively to username/pwd isn’t an option
 for us. 
   
'OAuth2' HTTP Authentication Scheme:  Simply put, dropping this seems like a huge step away from interoperability.  As one data point, Microsoft implements this in our WIF OAuth2 protected resource code.  All up, clients need a way
 to authenticate to the protected resource.  Also, existing WRAP implementations need this functionality to migrate to OAuth2.   For all these reasons, we support retaining this functionality in OAuth2. 
   
                                                            Thanks, 
                                                            -- Mike 

-----Inline Attachment Follows-----

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 18 Jan 2011 14:44:32 -0800

(apologies if this is a re-post, for some reason it was previously bounced)

I've been arguing as well to keep client assertion or some other stronger alternative to 3.1.  Re-reading the introduction to section 3, I see that the last paragraph says:

The authorization server MAY authenticate the client using any appropriate set of credentials and authentication schemes. The client MUST NOT include more than one set of credentials or authentication mechanism with each request.

I would suggest the following.  That we replace 3.2 with this paragraph expressed as an alternative (move it from the introduction and a little massaging).  The idea would be to make it clear that using normal web authentication methodologies is perfectly acceptable.  Further, I would also suggest that if an OOB authentication is use (and preferred), that the client_id might still be sent.  This handles case where mapping between client_id and the client credentials is not obvious (or easy). 

How about:

3.2. Client Web (OOB) Credentials

The client MAY be authenticated using any appropriate set of credentials and web authentication scheme supported by the authorization server. In cases where the client_id cannot be mapped by the authorizing server from the client credential, the client_id MUST be provided.[should client_id always be provided?]

I would even include language that makes Client Web Credential authentication the preferred methodology or at least list it first.

This makes the spec more consistent in that OAuth is not involved in the authentication of the user or the client. -- it makes it more consistent.

This approach will allow assertion based authentications (SAML, STS, etc) or other approaches without having to get hung up on how it should work inside of OAuth.

Phil
[email-masked]

On 2011-01-18, at 12:26 PM, Francisco Corella wrote:

> Having spoken to a number of people implementing the spec here, I’ve encountered strong objections to removing Client Assertion Credentials and the OAuth2 HTTP Authentication Scheme.  It’s also not clear to me why we would make substantial breaking changes to the specification when it is essentially ready for approval.  I’ve summarized the reasons I believe we should keep these two features below.
> 
> 
> In our implementation of the autonomous and web server profiles, ACS allows clients to authenticate using a signed assertion as well as with a username/password. The username/pwd option is for clients that don’t mind sending credentials over the wire, while the signed assertion mechanism is for clients that are more reticent to send raw credentials and for scenarios where it isn’t possible. To illustrate an example where username/pwd isn’t viable, consider the case of a client that needs to use an enterprise identity to gain access to a cloud service. In many cases, corporate policy demands that a client use an identity managed by the organization. This means that the client should obtain an assertion from an enterprise identity provider (Active Directory, Tivoli, etc.) and use that assertion to obtain an access token which grants access to various web service APIs. Many of our key MSFT customers and internal partner teams rely on this mechanism and reverting exclusively to username/pwd isn’t an option for us.
> 
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 18 Jan 2011 23:32:21 +0000

You wrote:  "Those who still want to advocate for it need to show not only consensus for keeping it...".  This seems backwards to me.  In particular, given the industry consensus that draft 10 was "nearly done", the onus to establish consensus should fall on advocates of any proposals to remove features - not the other way around - particularly so when the features are implemented and in use.

It's also pertinent that the implementation call went out for draft 11.  Therefore, we should not be removing draft 11 features without decisive consensus for doing so.

                                                            -- Mike

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 10:13 AM
To: Mike Jones
Cc: [email-masked]
Subject: RE: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

EHL

                                                            Thanks,
                                                            -- Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 18 Jan 2011 21:23:57 -0700

Thanks Phil.

The problem with this text is that it doesn't add anything new and I am not sure what Client Web Credentials even mean. I have argued against under-specified features and will continue to object their inclusion. When I initially agreed to include Yaron's text for client assertion it was based on the assumption that it will provoke discussion and will mature into a fully baked feature. It has not. Instead, it sits there without enough details to produce even a single working implementation, not to mention any level of interoperability what-so-ever.

The specification clearly allows any kind of client authentication. How is that not enough? How is providing two parameters that are useless without further profiling in any way useful? If you need stronger alternatives to 3.1 you are very welcome to define and publish such in companion specifications. It feels like we are going in circles where a few people are arguing to keep a feature that does not accomplish their reasons for its inclusion.

EHL

From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 2:45 PM
To: [email-masked]
Cc: Eran Hammer-Lahav; Mike Jones; [email-masked]; Karen P. Lewison
Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

How about:

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

Mike,

As assertion use is described in the spec, a client assertion does not provide any security whatsoever.  How do you handle subject confirmation in your implementation?  (See section 2.4.1.1 of the SAML specification<http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.)  In other words, how does the authorization server know that the client sending the assertion is actually the subject of the assertion?

Francisco

--- On Tue, 1/18/11, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme
To: "Eran Hammer-Lahav" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 18, 2011, 5:35 PM

                                                            Thanks,

                                                            -- Mike

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

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 18 Jan 2011 21:33:53 -0700

First, there was no 'implementation call' or any official process calling any draft final. I consider it stable, and close to finish, but that doesn't mean every word is now sacred. Playing the 'who needs to get consensus' game is counterproductive. I offered specific concerns about the text, both functionality-wise and prose-wise. You have agreed it is incomplete.

Your *sole* argument is that since it is already in the specification and Microsoft implemented it, it must say. That argument does not stand. I asked direct questions which you consistently ignored. I'll try one more time:

1.       How does the current language provides interoperability or even enough detail for any kind of running-code?

2.       Who else besides Microsoft implemented client credentials based on this section (or plans to), and where is their required addition specifications?

3.       How will removing this language break any running code (given that the two parameters will then become perfectly legal extensions)? How is this *any* different from moving the 'assertion' parameter from the framework specification to the SAML assertion specification (as we agreed on the list already and is partially published)?

I took the time and effort to write a thoughtful proposal and raise valid concerns. I would be greatly appreciated if you did the same and actually addressed my concerns instead of using process argument. Process-wise, it is within my prerogative as editor to remove a section of the specification and pass it to the chairs to determine consensus.  I rather have a thoughtful debate instead.

EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 3:32 PM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: RE: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

                                                            -- Mike

EHL

                                                            Thanks,
                                                            -- Mike

---

From: Phil Hunt <[email-masked]>
Date: Tue, 18 Jan 2011 21:23:10 -0800

Eran,

Yes, I agree it feels like we're going in circles.  Might I point out who it was that started this round? ;-)  Still, I think the discussion is useful and important.

3.0 introduces the concept (that any client authentication is acceptable) but then specifies 2 acceptable methods (3.1 and 3.2) and leaves out other forms of client authentication.  The specification can be interpreted that the "any types" of methods supported are 3.1 and 3.2 ONLY.  It just seems that the current spec has awkward phrasing.

My suggestion was simply to drop client_assertion and replace with some text indicating what "any client authentication" is.  Assertion based authentication would then be supported via the new paragraph 2 which allows for  any kind of client authentication (SAML, Kerberos, STS, whatever).

Just to add another loop, what about cutting out the entire section 3 and keep client_id as a required parameter in 4 and 5 (related to but not directly tied to authentication) -- and getting OAuth out of authentication methods entirely (other then to specify it as a requirement)?
  
Phil
[email-masked]

On 2011-01-18, at 8:23 PM, Eran Hammer-Lahav wrote:

> Thanks Phil.
>  
> The problem with this text is that it doesn’t add anything new and I am not sure what Client Web Credentials even mean.
> I have argued against under-specified features and will continue to object their inclusion. When I initially agreed to include Yaron’s text for client assertion it was based on the assumption that it will provoke discussion and will mature into a fully baked feature. It has not. Instead, it sits there without enough details to produce even a single working implementation, not to mention any level of interoperability what-so-ever.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 18 Jan 2011 23:06:15 -0700

Yes! This is exactly what I proposed if you combine removing Basic together with the assertion credentials. Basically, provide the parameter based approach as the only one specified, make it clear that *any* suitable client authentication is allowed, and then use HTTP Basic as an example of such other methods. I am even happy to explicitly mention the use of assertions for client authentication in the prose. I just don't think another sub-section is needed.

Would that be what you had in mind?

EHL

From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 9:23 PM
To: Eran Hammer-Lahav
Cc: [email-masked]; Mike Jones; [email-masked]; Karen P. Lewison
Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

Eran,

Phil

Thanks Phil.

The problem with this text is that it doesn't add anything new and I am not sure what Client Web Credentials even mean.
I have argued against under-specified features and will continue to object their inclusion. When I initially agreed to include Yaron's text for client assertion it was based on the assumption that it will provoke discussion and will mature into a fully baked feature. It has not. Instead, it sits there without enough details to produce even a single working implementation, not to mention any level of interoperability what-so-ever.

EHL

From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 2:45 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Eran Hammer-Lahav; Mike Jones; [email-masked]<mailto:[email-masked]>; Karen P. Lewison
Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

How about:

Phil

Mike,

Francisco

                                                            Thanks,

                                                            -- Mike

---

From: Phil Hunt <[email-masked]>
Date: Tue, 18 Jan 2011 22:37:27 -0800

I can agree with this.

However if you keep client password (3.1) around I would prefer another section (3.x) that indicates "or any other client authentication method meeting the security requirements of the authentication server" to make it clear and easy to scan.

Phil
[email-masked]

On 2011-01-18, at 10:06 PM, Eran Hammer-Lahav wrote:

> Yes! This is exactly what I proposed if you combine removing Basic together with the assertion credentials. Basically, provide the parameter based approach as the only one specified, make it clear that *any* suitable client authentication is allowed, and then use HTTP Basic as an example of such other methods. I am even happy to explicitly mention the use of assertions for client authentication in the prose. I just don’t think another sub-section is needed.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 18 Jan 2011 23:53:10 -0700

WFM.

EHL

From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 10:37 PM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

I can agree with this.

Phil

EHL

From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 9:23 PM
To: Eran Hammer-Lahav
Cc: [email-masked]<mailto:[email-masked]>; Mike Jones; [email-masked]<mailto:[email-masked]>; Karen P. Lewison
Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

Eran,

Phil

Thanks Phil.

EHL

How about:

Phil

Mike,

Francisco

                                                            Thanks,

                                                            -- Mike

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 20 Jan 2011 13:08:22 -0800

On Tue, Jan 18, 2011 at 10:12 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> 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.

Google has plans to use client assertions as well. We have two use
cases, one indeed would require an additional extension to specify
details about the content and format of the assertion. But the other
would work with what currently exists in v11.

In both cases the client cannot send the secret as authentication
(either for technical or security reasons) and instead it sends an
assertion.

In the fist case the client is self issuing an assertion, and in this
case we need more details.

In the second case the client gets an assertion from a local IdP. In
this case the local IdP and the remote OAuth 2 Authorization Server do
need to agree on keys and formats, but the client does not need to
understand any of that.

Marius

---

From: Brian Campbell <[email-masked]>
Date: Thu, 20 Jan 2011 14:25:09 -0700

I'd argue that, for reliable interoperability, both of those cases would
require an extension or at least some level of agreement about the format
and validation rules of the assertion.

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 20 Jan 2011 13:38:08 -0800

> and validation rules of the assertion.

I do agree that an extension would be useful for the second case, but
I don't think the client needs to know about it. I think it is
somewhat similar with the situation of the scope parameter.

Marius

---

From: Phillip Hunt <[email-masked]>
Date: Thu, 20 Jan 2011 14:14:14 -0800

The client does need to know how to authenticate. But given that it already has to know a lot about the service, you would think acceptable authentication types are well known to the client. 

What is the problem with the client authenticating like any normal web service client? (IE outside of oauth) 

Why involve oauth in any authentication for User or client?

I have some thoughts but interested in yours. 

Phil

Sent from my phone.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 20 Jan 2011 15:25:19 -0700

Okay, sorry, I see the distinction you were making.  The client could
potentially be told the client_assertion_type and given the assertion
(assuming it's properly encoded for all the hops) by some IdP/STS and make
use of the use of the spec, as it is written in -11.  Maybe then some
clients could support stronger forms of authentication for OAuth without
knowing about or being coded for an extension.  Maybe.  But they still would
need to know how to get the assertion and URI which is another animal all
together.

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 20 Jan 2011 14:28:04 -0800

> The client does need to know how to authenticate. But given that it already has to know a lot about the service, you would think acceptable authentication types are well known to the client.

Yes, true.

> Why involve oauth in any authentication for User or client?

What is a normal web service client? Since the client has to POST a
bunch of parameters as form encoded, it is simpler to also send
authentication parameters there. Providing alternate methods of
authentication is just asking for trouble. Of course, the spec could
require that authentication is only sent through some other method,
but I think it is way too late for such a change.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 20 Jan 2011 14:29:37 -0800

> need to know how to get the assertion and URI which is another animal all

That's right, the client would have to know how to interact with the
local IdP (and possibly how to authenticate with it).

Marius

---

From: Brian Campbell <[email-masked]>
Date: Thu, 20 Jan 2011 15:39:11 -0700

Francisco,

While a proper profiling of subject confirmation is generally needed for a
secure/interoperable SAML exchange, it's worth noting that assertions as
used in OAuth (client assertions or URI/assertion grant types) are not
necessarily SAML assertions.  The term assertion is used more generally.  To
be honest, I think token might have been be a less confusing term to use in
place of assertion in the framework spec.  But token is widely used in other
contexts thought out the framework spec too.  So I dunno, maybe that would
be even more confusing.

If you are interested/knowledgeable about SAML subject confirmation, please
feel free to review and comment on the SAML Bearer Assertion Grant Type
Profile: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-00  :)

-Brian

On Tue, Jan 18, 2011 at 1:26 PM, Francisco Corella <[email-masked]>wrote:

> Mike,
>
> As assertion use is described in the spec, a client assertion does not
> provide any security whatsoever.  How do you handle subject confirmation in
> your implementation?  (See section 2.4.1.1 of the SAML specification<http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.)
> In other words, how does the authorization server know that the client
> sending the assertion is actually the subject of the assertion?
>
> Francisco
>
> --- On *Tue, 1/18/11, Mike Jones <[email-masked]>* wrote:
>
>
>  Having spoken to a number of people implementing the spec here, I’ve
> encountered strong objections to removing Client Assertion Credentials and
> the OAuth2 HTTP Authentication Scheme.  It’s also not clear to me why we
> would make substantial breaking changes to the specification when it is
> essentially ready for approval.  I’ve summarized the reasons I believe we
> should keep these two features below.
>
> *Client Assertion Credentials:*  Many of the scenarios we care about
> require this capability. They were key motivators for the Assertion Profile
> in WRAP (see § 5.2), have been part of OAuth 2 for quite a while, and we
> have running code that requires this support. For example, the Azure Access
> Control Service is a cloud Authorization server that supports several
> protocols, including parts of OAuth 2.0 draft 10 (autonomous and web server
> profiles). We are happy to update our implementation to subsequent drafts &
> agree that the spec leaves a lot of ambiguity.
>
> In our implementation of the autonomous and web server profiles, ACS allows
> clients to authenticate using a signed assertion as well as with a
> username/password. The username/pwd option is for clients that don’t mind
> sending credentials over the wire, while the signed assertion mechanism is
> for clients that are more reticent to send raw credentials and for scenarios
> where it isn’t possible. To illustrate an example where username/pwd isn’t
> viable, consider the case of a client that needs to use an enterprise
> identity to gain access to a cloud service. In many cases, corporate policy
> demands that a client use an identity managed by the organization. This
> means that the client should obtain an assertion from an enterprise identity
> provider (Active Directory, Tivoli, etc.) and use that assertion to obtain
> an access token which grants access to various web service APIs. Many of our
> key MSFT customers and internal partner teams rely on this mechanism and
> reverting exclusively to username/pwd isn’t an option for us.
>
>
>
> *'OAuth2' HTTP Authentication Scheme:*  Simply put, dropping this seems
> like a huge step away from interoperability.  As one data point, Microsoft
> implements this in our WIF OAuth2 protected resource code.  All up, clients
> need a way to authenticate to the protected resource.  Also, existing WRAP
> implementations need this functionality to migrate to OAuth2.   For all
> these reasons, we support retaining this functionality in OAuth2.
>
>
>
>                                                             Thanks,
>
>                                                             -- Mike
>
>
>
> [email-masked] <http://mc/compose?to=[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 20 Jan 2011 14:50:49 -0800

I don't think this is a case of providing alternative methods.  It is just a case of allowing ANY method that the Authentication server deems sufficient. Kerberos, SAML, SSO token, basic auth, mutual SSL, etc.

Thus you don't need to put specific authentication methods in the spec other than to simply REQUIRE that the client be authenticated -- either inbound with the POST as you suggest or OOB during a previous exchange.

It may be a good idea to define one mandatory to implement methodology, but to define more than one suggests limiting authentication approaches to specific methods. I don't think this is the intent here.

Phil
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Thu, 20 Jan 2011 14:57:56 -0800

Sorry, typo ... see clarification below. 

Phil
[email-masked]

On 2011-01-20, at 2:50 PM, Phil Hunt wrote:

> Thus you don't need to put specific authentication methods in the spec other than to simply REQUIRE that the client be authenticated -- either inbound with the POST as you suggest or
handled OOB (SSL mutual, SSO token etc).

---

From: Francisco Corella <[email-masked]>
Date: Thu, 20 Jan 2011 21:11:52 -0800 (PST)

Brian,

Thank you for pointing me to the SAML Bearer Assertion Grant Type Profile.  I understand now.  Maybe the spec would be clearer if it said that the client assertion is a bearer assertion.

Francisco

--- On Thu, 1/20/11, Brian Campbell <[email-masked]> wrote:

From: Brian Campbell <[email-masked]>
Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme
To: [email-masked]
Cc: "Eran Hammer-Lahav" <[email-masked]>, "Mike Jones" <[email-masked]>, "[email-masked]" <[email-masked]>, "Karen P. Lewison" <[email-masked]>
Date: Thursday, January 20, 2011, 10:39 PM

Francisco,

While a proper profiling of subject confirmation is generally needed for a secure/interoperable SAML exchange, it's worth noting that assertions as used in OAuth (client assertions or URI/assertion grant types) are not necessarily SAML assertions.  The term assertion is used more generally.  To be honest, I think token might have been be a less confusing term to use in place of assertion in the framework spec.  But token is widely used in other contexts thought out the framework spec too.  So I dunno, maybe that would be even more confusing.

If you are interested/knowledgeable about SAML subject confirmation, please feel free to review and comment on the SAML Bearer Assertion Grant Type Profile: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-00  :)

-Brian

On Tue, Jan 18, 2011 at 1:26 PM, Francisco Corella <[email-masked]> wrote:

Mike,

Francisco

To: "Eran Hammer-Lahav"
 <[email-masked]>

 

 

                                                            Thanks, 
                                                            -- Mike 

-----Inline Attachment Follows-----

OAuth mailing list

[email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Fri, 21 Jan 2011 09:45:08 -0700

I think we are generally in agreement on this Phil although there are
legitimate cases where the client doesn't need to authenticate so having the
spec require it is too restrictive.

On Thu, Jan 20, 2011 at 3:50 PM, Phil Hunt <[email-masked]> wrote:

> I don't think this is a case of providing alternative methods.  It is just
> a case of allowing ANY method that the Authentication server deems
> sufficient. Kerberos, SAML, SSO token, basic auth, mutual SSL, etc.
>
> Thus you don't need to put specific authentication methods in the spec
> other than to simply REQUIRE that the client be authenticated -- either
> inbound with the POST as you suggest or OOB during a previous exchange.
>
> It may be a good idea to define one mandatory to implement methodology, but
> to define more than one suggests limiting authentication approaches to
> specific methods. I don't think this is the intent here.
>
> Phil
> [email-masked]
>
>
>
>
> >> The client does need to know how to authenticate. But given that it
> already has to know a lot about the service, you would think acceptable
> authentication types are well known to the client.
> >
> > Yes, true.
> >
> >

---

From: Brian Campbell <[email-masked]>
Date: Fri, 21 Jan 2011 09:45:35 -0700

BTW EHL, I haven't read all of -12 yet but I did read section 2 and, even
though I was among those that originally pushed for the client assertion
stuff, I think that where you've taken it is pretty good.

On Fri, Jan 21, 2011 at 9:45 AM, Brian Campbell
<[email-masked]>wrote:

>> It may be a good idea to define one mandatory to implement methodology,
>> but to define more than one suggests limiting authentication approaches to

---

From: Brian Campbell <[email-masked]>
Date: Fri, 21 Jan 2011 10:06:01 -0700

I guess it's somewhat moot now because client assertions have been removed
from the latest draft.  However, I don't believe there anything saying that
client assertions had to be bearer assertions.  Nor would that really have
been appropriate for the framework spec.

The same is true for extension/URI grant types (formerly known as assertion
grant types).  There is nothing in the core OAuth framework spec saying that
it is, or has to be, a bearer assertion.  The SAML Bearer Assertion Grant
Type Profile is an extension spec that constrains/defines the specific use
of bearer SAML assertion.  To me and some others, that seemed like a useful
enough use-case to write an I-D for, however, the main OAuth spec allows for
other extensions.  A holder of key SAML Assertion, for example, might be
profiled as a grant type.  Or something completely non SAML based.

On Thu, Jan 20, 2011 at 10:11 PM, Francisco Corella <[email-masked]>wrote:

> Brian,
>
> Thank you for pointing me to the SAML Bearer Assertion Grant Type Profile.
> I understand now.  Maybe the spec would be clearer if it said that the
> client assertion is a bearer assertion.
>
> Francisco
>
> --- On *Thu, 1/20/11, Brian Campbell <[email-masked]>* wrote:
>
>
> Cc: "Eran Hammer-Lahav" <[email-masked]>, "Mike Jones" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "Karen P.
> Lewison" <[email-masked]>
> On Tue, Jan 18, 2011 at 1:26 PM, Francisco Corella <[email-masked]<http://mc/compose?to=[email-masked]>
> > wrote:
>
> Mike,
>
> --- On *Tue, 1/18/11, Mike Jones <[email-masked]<http://mc/compose?to=[email-masked]>
> >* wrote:
>
>
> From: Mike Jones <[email-masked]<http://mc/compose?to=[email-masked]>
> >
> To: "Eran Hammer-Lahav" <[email-masked]<http://mc/compose?to=[email-masked]>
> >
> Cc: "[email-masked] <http://mc/compose?to=[email-masked]>" <[email-masked]<http://mc/compose?to=[email-masked]>
> >

---

From: Francisco Corella <[email-masked]>
Date: Fri, 21 Jan 2011 22:28:48 -0800 (PST)

Brian,

> I guess it's somewhat moot now because client assertions
> have been removed from the latest draft.  However, I don't
> believe there anything saying that client assertions had to
> be bearer assertions.  Nor would that really have been
> appropriate for the framework spec.

Ah, so I was right in thinking there was something wrong :-)

You can only use a bearer assertion (or "could" since
assertions are no longer in the spec).  

If a subject (here, the client) authenticates itself by
sending a single message that contains an assertion, the
assertion cannot be a holder-of-key assertion.  A
holder-of-key assertion is an assertion about the holder of
a private key whose corresponding public key or certificate
is contained in the assertion.  The subject must confirm
that it has the private key.  The subject typically does
that by signing a nonce supplied by the relying party (here,
the authorization server).  That party must send the nonce
in an earlier protocol message.

Actually, an assertion that authenticates the subject by the
mere fact of being presented by the subject is, by
definition, a bearer assertion.  That's what "bearer"
means.  It means "this assertion is about whoever bears
it (carries it, produces it); the bearer does not have to
present any other proof if its identity".

> The same is true for extension/URI grant types (formerly
> known as assertion grant types).  There is nothing in the
> core OAuth framework spec saying that it is, or has to be, a
> bearer assertion.  The SAML Bearer Assertion Grant Type
> Profile is an extension spec that constrains/defines the
> specific use of bearer SAML assertion.  To me and some
> others, that seemed like a useful enough use-case to write
> an I-D for, however, the main OAuth spec allows for other
> extensions.  A holder of key SAML Assertion, for example,
> might be profiled as a grant type.  Or something completely
> non SAML based.

The same would be true for obtaining an access token by
presenting a SAML assertion as an access grant.  It would
have to be a bearer assertion, not a holder-of-key
assertion.

As for a non-SAML token, it would have to be a bearer token,
by definition of the word "bearer".  But it's not just a
matter of definition.  There is a security requirement for
any token to be usable as a bearer token: it must only
become known to the subject and the verifier.  So it must be
sent by the asserting party to the subject, and then from
the subject to the relying party, through channels that
provide confidentiality and authentication of the
destination (such as ordinary TLS connections).  And all
three parties must keep the bearer token secret.

By the way, I saw in the discussion that some existing
implementations are using assertions.  Hopefully they are
using bearer assertions.

Francisco

---

From: Phillip Hunt <[email-masked]>
Date: Sat, 22 Jan 2011 08:23:03 -0800

My understanding is you can still do it. It is covered by the new other auth mechanism paragraph. 

The real question is do we need it for interop purposes or not?

We had other methods that didn't fit draft 11 either. So do u spec them all or just one mandatory to implement?

Phil

Sent from my phone.

---

From: Francisco Corella <[email-masked]>
Date: Sat, 22 Jan 2011 08:59:42 -0800 (PST)

A correction to my previous message below: a holder-of-key assertion can be sent in what seems to be a single message if the message is sent over a TLS connection and the assertion is about the key pair used in the connection.  Of course that's not really a single message, because there are multiple messages involved in the TLS handshake, and it's precisely the TLS handshake that shows that the subject it is the holder of the private key.

Specifically, an assertion sent in the body of an HTTP POST request over a TLS connection can be used to bind a certificate used as TLS client certificate to additional data about the subject of the certificate.  And an assertion sent in the body of a response to an HTTP request over a TLS connection can be used to bind the certificate used as TLS server certificate to additional data about the subject of the certificate.

Francisco

--- On Sat, 1/22/11, Francisco Corella <[email-masked]> wrote:

From: Francisco Corella <[email-masked]>
Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme
To: [email-masked]
Cc: "Karen P. Lewison" <[email-masked]>
Date: Saturday, January 22, 2011, 6:28 AM

Brian,

is contained in the assertion.  The subject must
 confirm

the subject to the relying party, through
 channels that

Francisco