Re: [OAUTH-WG] Clients authenticating with assertions
Eran Hammer-Lahav <eran@hueniverse.com> Fri, 25 June 2010 18:31 UTC
Return-Path: <eran@hueniverse.com>
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 <oauth@core3.amsl.com>; 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 <oauth@core3.amsl.com>; 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 <oauth@ietf.org>; 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 <eran@hueniverse.com>
To: Yaron Goland <yarong@microsoft.com>, "oauth@ietf.org" <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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2010 18:31:52 -0000
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 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-WG] Clients authenticating with assertions Yaron Goland
- Re: [OAUTH-WG] Clients authenticating with assert… Eran Hammer-Lahav