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 0028D3A6928 for ; Fri, 25 Jun 2010 11:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.623 X-Spam-Level: X-Spam-Status: No, score=-9.623 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 u7uvwkQOb0gW for ; Fri, 25 Jun 2010 11:26:10 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id E3BFA3A6993 for ; Fri, 25 Jun 2010 11:26:09 -0700 (PDT) Received: from TK5EX14CASC131.redmond.corp.microsoft.com (157.54.52.38) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 25 Jun 2010 11:26:13 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14CASC131.redmond.corp.microsoft.com ([157.54.52.38]) with mapi id 14.01.0160.007; Fri, 25 Jun 2010 11:26:14 -0700 From: Yaron Goland To: "oauth@ietf.org" Thread-Topic: Clients authenticating with assertions Thread-Index: AcsUhz2iYfrAgGl/Q7+u4YeRqbxaDg== Date: Fri, 25 Jun 2010 18:26:10 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579CA9D1@TK5EX14MBXC117.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579CA9D1TK5EX14MBXC117r_" MIME-Version: 1.0 Subject: [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:26:13 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579CA9D1TK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_7C01E631FF4B654FA1E783F1C0265F8C579CA9D1TK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 =3D assertion doesn’t seem right be= cause that assertion should be from the resource owner who delegated the pe= rmission, 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?

&nbs= p; Thanks,

&nbs= p; &= nbsp; Yaron

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

--_000_7C01E631FF4B654FA1E783F1C0265F8C579CA9D1TK5EX14MBXC117r_--