Re: [OAUTH-WG] more than one assertion?

Brian Campbell <bcampbell@pingidentity.com> Thu, 12 August 2010 20:02 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 7BBD63A65A5 for <oauth@core3.amsl.com>; Thu, 12 Aug 2010 13:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.786
X-Spam-Level:
X-Spam-Status: No, score=-5.786 tagged_above=-999 required=5 tests=[AWL=0.191, 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 gkmUA0Wau++z for <oauth@core3.amsl.com>; Thu, 12 Aug 2010 13:02:03 -0700 (PDT)
Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id 180153A6995 for <oauth@ietf.org>; Thu, 12 Aug 2010 13:01:46 -0700 (PDT)
Received: from source ([209.85.215.51]) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTGRTTzJ6RZ6f0tw8cfJ1l64SNlijJxel@postini.com; Thu, 12 Aug 2010 13:02:24 PDT
Received: by ewy21 with SMTP id 21so1160008ewy.24 for <oauth@ietf.org>; Thu, 12 Aug 2010 13:02:22 -0700 (PDT)
Received: by 10.216.157.81 with SMTP id n59mr360110wek.84.1281643342315; Thu, 12 Aug 2010 13:02:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.60.136 with HTTP; Thu, 12 Aug 2010 13:01:52 -0700 (PDT)
In-Reply-To: <AANLkTinsTe9vxrWsXK6p9+bfRRSyZTjb2yW8+=ux5tU_@mail.gmail.com>
References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> <C8897C4C.B75E%cmortimore@salesforce.com> <AANLkTinbmx+CBJdMrf5vBuV7wqLwWDLP3vA1N2HcUMHL@mail.gmail.com> <AANLkTinsTe9vxrWsXK6p9+bfRRSyZTjb2yW8+=ux5tU_@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 12 Aug 2010 14:01:52 -0600
Message-ID: <AANLkTik0n-ki3d06wr=sAZCzUDq4KQ-Ahy3wwPXagG6S@mail.gmail.com>
To: Brian Eaton <beaton@google.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] more than one 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: Thu, 12 Aug 2010 20:02:04 -0000

I generally agree more with Chuck, David and Brain E than I don't.
But I do think that someone will find a pragmatic reason for > 1
assertion eventually and I think the proposal earlier in this thread
to allow for multiple occurrences of the assertion parameter in the
core spec will make that easier for a number of instantiations of the
assertion flow (grant type) at a later time.  It adds some complexity
but I don't think a lot.  And specifications or pairwise agreements
building on the assertion flow could easily constrain down to a single
assertion, if it suits the profile.

That's the only change proposal to the core spec that's come out of
discussion around my I-D
http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt (that I can
think of).  I'm still not sure if it makes sense to allow for multiple
assertions in the next draft of that, but allowing for multiple
assertion params in core sure seems like a cleaner way to do it.

Yaron's proposal for a Section 2.2 on Client Assertions is a change to
core as well (latest in that thread:
http://www.ietf.org/mail-archive/web/oauth/current/msg04154.html)
However, even though it uses the term assertion similarly, it's a
distinct issue from the SAML work.  The latter is a SAML based usage
of the assertion grant type while the former I think of it more as a
means of allowing for stronger forms of client authentication than
just a client password/secret.

I guess both could be used in a two-legged style interaction (or used
together) and maybe that's where it starts to get confusing...



On Thu, Aug 12, 2010 at 1:38 PM, Brian Eaton <beaton@google.com> wrote:
> On Thu, Aug 12, 2010 at 12:36 PM, David Recordon <recordond@gmail.com> wrote:
>> I've only been half following the recent assertion threads for this
>> exact reason. I don't understand how these proposals are going to be
>> used and worry about any additional complexity added to the spec.
>
> Likewise.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>