Re: [OAUTH-WG] assertion, client_assertion_type and client_assertion

Brian Campbell <bcampbell@pingidentity.com> Mon, 31 January 2011 14:13 UTC

Return-Path: <bcampbell@pingidentity.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 5480E3A6C04 for <oauth@core3.amsl.com>; Mon, 31 Jan 2011 06:13:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.755
X-Spam-Level:
X-Spam-Status: No, score=-5.755 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
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 zn31FHsyCrvF for <oauth@core3.amsl.com>; Mon, 31 Jan 2011 06:13:31 -0800 (PST)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with ESMTP id 8EAE53A6BFA for <oauth@ietf.org>; Mon, 31 Jan 2011 06:13:29 -0800 (PST)
Received: from source ([209.85.161.41]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTUbESayjy0cWCAL28ixQD4/Q5xLb4McD@postini.com; Mon, 31 Jan 2011 06:16:45 PST
Received: by mail-fx0-f41.google.com with SMTP id 12so6662922fxm.14 for <oauth@ietf.org>; Mon, 31 Jan 2011 06:16:41 -0800 (PST)
Received: by 10.223.101.135 with SMTP id c7mr1101359fao.76.1296483401416; Mon, 31 Jan 2011 06:16:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.160.9 with HTTP; Mon, 31 Jan 2011 06:16:11 -0800 (PST)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2B14@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <AANLkTimcMgFuvXan75UiE0tobMMtbN2UMfV1ehkoM_z4@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB2B14@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 31 Jan 2011 07:16:11 -0700
Message-ID: <AANLkTi=ms9mr1huYJg=Oc4zqwB3LC0c7w5kyWRq0ZuGG@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] assertion, client_assertion_type and client_assertion
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: Mon, 31 Jan 2011 14:13:32 -0000

I'm happy to make that change.  But is it really necessary?   The
assertion parameter in draft-ietf-oauth-saml2-bearer is defined in the
context of using the
"http://oauth.net/grant_type/assertion/saml/2.0/bearer" grant type.
Couldn't it be argued that other URI grant types could make use of it
without issue or conflict?  Does this suggest that the registry isn't
granular enough?  It seems the definition of the assertion parameter
in the context of a new grant type should probably prohibit its use in
other extension mechanisms that might be used along side the grant but
not in other grant definitions (AFAIK, there's no way to present two
grants at the same time).

On Sun, Jan 30, 2011 at 3:58 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>> -----Original Message-----
>> Marius Scurtescu
>>
>> The assertion parameter was in core, but it was removed and now it is
>> defined by SAML 2.0 Bearer Assertion Grant Type Profile. What will the next
>> assertion extension do, let's say JWT? It can either re-define the assertion
>> parameter or it can reference SAML 2.0 Bearer. Does re-defining imply
>> registration as well? How would that work? Having JWT depend on SAML
>> does not make much sense.
>
> It makes no sense to define this parameter in the authorization specification because assertions are no longer discussed. It would be a very odd and out of context definition. The appropriate solution here is for the SAML specification to change its definition of the assertion parameter to be more generally applicable. For example:
>
>   assertion
>         REQUIRED.  The assertion used to obtain an access token. The value of the
>         assertion parameter MUST contain a single assertion. When used with the
>         http://oauth.net/grant_type/assertion/saml/2.0/bearer"  grant type, the
>         assertion MUST be a SAML 2.0 Assertion.  The SAML 2.0 Assertion XML data
>         MUST be encoded using base64url, where the encoding adheres to the
>         definition in Section 5 of RFC4648 [RFC4648] and where the
>         padding bits are set to zero.  To avoid the need for
>         subsequent encoding steps (by "application/
>         x-www-form-urlencoded" [W3C.REC-html401-19991224], for
>         example), the base64url encoded data SHOULD NOT be line wrapped
>         and pad characters ("=") SHOULD NOT be included.
>
> This way, other specifications can simply use this parameter as-is without any additional registrations or updates.