The following is proposed language for a new section, 2.2, in the spec. This is 
part of the spec that deals with client authentication. This proposal is 
completely orthogonal to anything in section 4 such as grant types. At Eran's 
suggestion I added in an example into the text to help readers understand both 
what the feature is for and how it is used.

Eran also suggested that we should probably introduce a client_cred_type 
parameter (since we are explicitly support multiple types of client parameters) 
just to be consistent with grant_type. I don't have strong feelings on the 
subject and am happy to go with whatever the group wants.

                Thoughts?

                                Thanks,

                                                Yaron

2.2 Assertion Client Credentials

In scenarios where security is at a premium one wants to avoid sending secrets 
across the Internet, even on encrypted connections. Instead one wants to send 
values derived from the secret that prove to the receiver that the sender is in 
possession of the secret without actually sending the secret. Typically the way 
derived values are created is by generating an assertion that is then either 
HMAC'd or digitally signed using an agreed upon secret. By validating the HMAC 
or digital signature on the assertion the receiver of the assertion can prove 
to themselves that the entity that generated the assertion was in possession of 
the secret without actually communicating the secret directly.

So, for example, a client can establish a secret using an out of band mechanism 
with a resource server. As part of this out of band communication the client 
and resource server agree that the client will authenticate itself using a SAML 
assertion with agreed upon parameters that will be signed by the provisioned 
secret.

Later on the client interacts with an end-user and uses the end-user 
authorization process with the resource server to get an authorization code. 
The client then sends an access token request to the token endpoint for the 
resource server and includes, along with the authorization code, a SAML 
assertion it signed with the previously agreed key and parameters. The SAML 
assertion proves to the token endpoint the identity of the client and the 
authorization code provides the link to the end-user authorization. If the 
access token request comes back with a refresh token then in the future the 
client can get new access tokens by submitting an access token request 
containing both a properly signed and formatted SAML assertion as well as the 
refresh token.

The following defines how to send an assertion as client credentials. If the 
assertion client credentials are used then the client MUST include the 
credentials using the following request parameters:

client_id
                REQUIRED. The client identifier.
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 (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=refresh_token&client_id=s6BhdRkqt3&
                client_assertion=PHNhbWxwOl...[omitted for brevity]...ZT4%3D&
                
client_assertion_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&
                refresh_token=n4E90119d

The client MUST NOT include the client credentials using more than one 
mechanism. If more than one mechanism is used regardless whether the 
credentials are identical or valid, the server MUST reply with an HTTP 400 
status code (Bad Request) and include the "multiple_credentials" error code.

Token endpoints can differentiate between client assertion credentials and 
other client credential types by looking for the presence of the 
client_assertion and client_assertion_type attributes which will only be 
present with client assertion credentials.


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Yaron 
Goland
Sent: Friday, June 25, 2010 3:33 PM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: [OAUTH-WG] Proposal for text for section 2

Motivating Scenario: A client makes a request to a token endpoint. It uses an 
authorization token to authenticate itself and a refresh token to authenticate 
it's delegated right. This approach to authenticating clients is used in 
enterprises all the time because it's good security practice to send values 
derived from a secret (e.g. an HMAC, digital signature, etc.) rather than the 
secret itself across the wire, even if the wire is encrypted.

Proposed Text:
2.2  Assertion Client Credentials

The assertion client credentials include a client identifier, assertion and 
assertion type. If the assertion client credentials are used then the client 
MUST include the credentials using the following request parameters:

client_id
                REQUIRED. The client identifier.
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 (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=refresh_token&client_id=s6BhdRkqt3&
                client_assertion=PHNhbWxwOl...[omitted for brevity]...ZT4%3D&
                
client_assertion_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&
                refresh_token=n4E90119d

The client MUST NOT include the client credentials using more than one 
mechanism. If more than one mechanism is used regardless whether the 
credentials are identical or valid, the server MUST reply with an HTTP 400 
status code (Bad Request) and include the "multiple_credentials" error code.


From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Friday, June 25, 2010 11:31 AM
To: Yaron Goland; oauth@ietf.org
Subject: RE: Clients authenticating with assertions

We never had support for two assertions in one request.

The client authenticates itself and can include an assertion (or use type 
'none'). The client credentials are the "client assertion" and the assertion is 
about the resource owner.

Also, you can define an assertion type that's a composite assertion (of one 
more more).

EHL

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Yaron 
Goland
Sent: Friday, June 25, 2010 11:26 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Clients authenticating with assertions

If a client wants to authenticate itself to a token endpoint to get an access 
token using an assertion how should it do it?

Grant_Type = assertion doesn't seem right because that assertion should be from 
the resource owner who delegated the permission, not from the client, right? In 
other words one can end up with an access token request with two assertions, 
one from the client and one from the resource owner. How is this done?

                Thanks,

                                Yaron

P.S. I looked for something like client_assertion and client_assertion_type in 
section 2 of -08 but didn't see it. Sorry if I missed it.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to