IETF Logo Mail Archive

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

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 18 August 2010 07:19 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 C3E363A681A for <oauth@core3.amsl.com>; Wed, 18 Aug 2010 00:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.481
X-Spam-Level:
X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 hNHtdp-DORCc for <oauth@core3.amsl.com>; Wed, 18 Aug 2010 00:19:24 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 9F08A3A6821 for <oauth@ietf.org>; Wed, 18 Aug 2010 00:19:24 -0700 (PDT)
Received: (qmail 3293 invoked from network); 18 Aug 2010 07:20:00 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2010 07:20:00 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 18 Aug 2010 00:20:00 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Brian Campbell <bcampbell@pingidentity.com>, David Recordon <recordond@gmail.com>
Date: Wed, 18 Aug 2010 00:20:07 -0700
Thread-Topic: [OAUTH-WG] more than one assertion?
Thread-Index: Acs7KeM6i9hEwAC6Q5OZrPAVBjVqdgDe8VIA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F1D721E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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> <AANLkTikQc0-yh3B8ikF+VZVoj-h9qt=dR_rKVfHK_x1A@mail.gmail.com> <AANLkTik9GOtMa0AgW1UJcd8vhipBC97c0tY7ua=pq6eX@mail.gmail.com>
In-Reply-To: <AANLkTik9GOtMa0AgW1UJcd8vhipBC97c0tY7ua=pq6eX@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 18 Aug 2010 07:19:25 -0000

The assertion flow has been "upgraded" from an edge case to the way new access grants are defined. It's part of the extensibility model, and as such, is going to stay in the core spec.

EHL

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, August 13, 2010 1:55 PM
To: David Recordon
Cc: oauth
Subject: Re: [OAUTH-WG] more than one assertion?

On Thu, Aug 12, 2010 at 2:04 PM, David Recordon <recordond@gmail.com> wrote:
> 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.

The assertion flow should stay in core (others have expressed this opinion as well).  I've got interop tested code built on that that is about to GA.

As far as the client assertions, I do believe there's real value in having a clean extension point for stronger forms of client authentication.  Yaron's proposed language does a pretty good job I think.  But if it can be done in a simpler way, let's discuss. I'll probably regret saying this, but what about not using the word "assertion" for stronger client auth options?  That might help eliminate some confusion.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

v2.31.3 | Report a Bug | By Email | System Status