Subject: [OAUTH-WG] Client Assertion Credentials (again)

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 18 Feb 2011 20:17:14 +0200

Hi all, 

I asked for feedback regarding the removal of the client assertion credentials earlier this month, see 
http://www.ietf.org/mail-archive/web/oauth/current/msg05261.html

Unfortunately, the feedback did not lead to any new insight other than there are three groups of people: 
1) Those who want the functionality removed from the draft
2) Those who want it to be included. 
3) Those who want something different in the document (namely a stronger version). 

These three groups are equally large (based on the feedback).

I have attached the text from version -11 of the draft. 

So, my suggestion to the group therefore is for those who are interested in this functionality in one way or the other to provide text that the group can agree with in time before we submit the document to the IESG (1). 
If that does not happen the client assertion credential will have to be developed as a separate document (if there is enough energy and interest in the group). 

A note regarding (1): Currently, the security consideration section is missing since otherwise the document is ready for a working group last call (in my view).
So, once that is there and agreed I will start a working group last call. 

Ciao
Hannes

-----

3.2.  Client Assertion Credentials

   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.  In such cases
   it is common to use other mechanisms such as HMAC or digital
   signatures that do not require sending clear-text secrets.  The
   client assertion credentials provide an extensible mechanism to use
   an assertion format supported by the authorization server for
   authentication the client.

   Using assertions requires the client to obtain an assertion (such as
   a SAML [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

   When obtaining an access token using a client assertion together with
   an authorization code (as described in  Section 5.1.1), a mechanism is
   needed to map between the value of "client_id" parameter used to
   obtain the authorization code, and the client assertion.  Such
   mechanism is beyond the out of scope for this specification, but MUST
   be specified for any client assertion type used in combination with
   an authorization code.

   The authorization server MUST reject access token requests using
   client assertion credentials that do not contain HMAC or signed
   values that:

   o  State the assertion was specifically issued to be consumed by the
      receiving endpoint (typically via an audience or recipient value
      containing the receiving endpoint's identifier).

   o  Identify the entity that issued the assertion (typically via an
      issuer value).

   o  Identify when the assertion expires as an absolute time (typically
      via an expiration value containing a UTC date/time value).  The
      authorization server MUST reject expired assertions.

---

From: Phillip Hunt <[email-masked]>
Date: Fri, 18 Feb 2011 10:22:05 -0800

You can put in client_assertion but also leave the 'other' credential option there as well 

Phil

Sent from my phone. 

On 2011-02-18, at 10:17, Hannes Tschofenig <[email-masked]> wrote:

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 18 Feb 2011 12:44:36 -0700

I support this approach.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Friday, February 18, 2011 10:17 AM
> To: OAuth WG
> Subject: [OAUTH-WG] Client Assertion Credentials (again)
> 
> Hi all,
> 
> I asked for feedback regarding the removal of the client assertion credentials
> earlier this month, see http://www.ietf.org/mail-
> archive/web/oauth/current/msg05261.html
> 
> So, my suggestion to the group therefore is for those who are interested in
> this functionality in one way or the other to provide text that the group can
> agree with in time before we submit the document to the IESG (1).
> If that does not happen the client assertion credential will have to be
> developed as a separate document (if there is enough energy and interest in
> the group).
> 
> A note regarding (1): Currently, the security consideration section is missing
> since otherwise the document is ready for a working group last call (in my
> view).

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 18 Feb 2011 12:45:28 -0700

By #3 Hannes meant defining another option in the spec, not just allowing it to be defined elsewhere.

EHL

> Of Phillip Hunt
> Sent: Friday, February 18, 2011 10:22 AM
> To: Hannes Tschofenig
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Client Assertion Credentials (again)
>