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

David Recordon <recordond@gmail.com> Thu, 12 August 2010 20:04 UTC

Return-Path: <recordond@gmail.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 9BB9C3A68CF for <oauth@core3.amsl.com>; Thu, 12 Aug 2010 13:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.419
X-Spam-Level:
X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599]
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 jnaD53yU-Lgk for <oauth@core3.amsl.com>; Thu, 12 Aug 2010 13:04:12 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 6447F3A65A5 for <oauth@ietf.org>; Thu, 12 Aug 2010 13:04:12 -0700 (PDT)
Received: by bwz7 with SMTP id 7so886965bwz.31 for <oauth@ietf.org>; Thu, 12 Aug 2010 13:04:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BBPveHYoufB+Er5L7WGs1RR5Hi5rmZnvWB2NwKaDHx4=; b=LXjGBbjpdQZFGjXUwQlzlASV5TizjLHumvc68THhmvoz21F4KbXyM2Wg0F+NfW/yqv 7qcWjC8mXkjbwQ87aHW3bZamb7kWZXctQj9j26PZjbzoekb8v4QZhvV9Mxd6JJxRKXzA 56a4aayixJlK9SncQh78PjjfZNtNb4C/pdPhY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PVyZlfiKT7EcqhfGOVa9Nph/Ggu/wKqJzJChYq7Jm0L9UVOiTlwYY2Y5qCOc6GAFTN U6Hsl9iZ1Aqu+DAwmuY24bQNEP1bXHiI9sJVAMFHrswZ4nF92nuoY7mKvBOvfcTLT4cL bFXFvT/wJFlV5P2d5XcMy0/tp9cppWHIY/fx4=
MIME-Version: 1.0
Received: by 10.204.56.84 with SMTP id x20mr415959bkg.68.1281643488990; Thu, 12 Aug 2010 13:04:48 -0700 (PDT)
Received: by 10.204.132.155 with HTTP; Thu, 12 Aug 2010 13:04:48 -0700 (PDT)
In-Reply-To: <AANLkTik0n-ki3d06wr=sAZCzUDq4KQ-Ahy3wwPXagG6S@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> <AANLkTik0n-ki3d06wr=sAZCzUDq4KQ-Ahy3wwPXagG6S@mail.gmail.com>
Date: Thu, 12 Aug 2010 16:04:48 -0400
Message-ID: <AANLkTikQc0-yh3B8ikF+VZVoj-h9qt=dR_rKVfHK_x1A@mail.gmail.com>
From: David Recordon <recordond@gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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:04:13 -0000

Given that, would you strongly object to these proposals being written
in a separate document than the core spec? The device flow is a good
example of where we're doing this. We really think that it will be
useful, are working on implementations, but it hasn't yet been proven
in production.

On Thu, Aug 12, 2010 at 4:01 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
> 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
>>
>