Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E963728C112 for ; Fri, 25 Jun 2010 11:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmcfrirYxnHq for ; Fri, 25 Jun 2010 11:31:45 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 522163A6A2F for ; Fri, 25 Jun 2010 11:31:33 -0700 (PDT) Received: (qmail 21735 invoked from network); 25 Jun 2010 18:31:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jun 2010 18:31:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 25 Jun 2010 11:31:42 -0700 From: Eran Hammer-Lahav To: Yaron Goland , "oauth@ietf.org" Date: Fri, 25 Jun 2010 11:31:24 -0700 Thread-Topic: Clients authenticating with assertions Thread-Index: AcsUhz2iYfrAgGl/Q7+u4YeRqbxaDgADS/YA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC849A8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579CA9D1@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579CA9D1@TK5EX14MBXC117.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC849A8P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Clients authenticating with assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 18:31:52 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC849A8P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron 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 acce= ss token using an assertion how should it do it? Grant_Type =3D assertion doesn't seem right because that assertion should b= e 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 tw= o assertions, one from the client and one from the resource owner. How is t= his 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. --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC849A8P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We never had support for two assertions in one request.<= /o:p>

&nb= sp;

The = client authenticates itself and can include an assertion (or use type ̵= 6;none’). The client credentials are the “client assertion̶= 1; and the assertion is about the resource owner.

 

=

Also, you can define an = assertion type that’s a composite assertion (of one more more).<= /o:p>

&nb= sp;

EHL<= o:p>

 

From:<= /b> oaut= h-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Yaro= n Goland
Sent: Friday, June 25, 2010 11:26 AM
To: oauth= @ietf.org
Subject: [OAUTH-WG] Clients authenticating with asserti= ons

 =

If a client wants to authenticate itself to a toke= n endpoint to get an access token using an assertion how should it do it? <= o:p>

 

Grant_Type =3D assertion doesn’t seem right because that assertion = should be from the resource owner who delegated the permission, not from th= e 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?

 

<= p class=3DMsoNormal>         &= nbsp;      Thanks,

 

     = ;            &n= bsp;            = ;  Yaron

 

P.S. I looked for something like client_assertion and clien= t_assertion_type in section 2 of -08 but didn’t see it. Sorry if I mi= ssed it.

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC849A8P3PW5EX1MB01E_--