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

Brian Campbell <bcampbell@pingidentity.com> Tue, 10 August 2010 16: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 8B0EE3A695A for <oauth@core3.amsl.com>; Tue, 10 Aug 2010 09:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.494
X-Spam-Level:
X-Spam-Status: No, score=-5.494 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6, 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 GzfB3OY2w7S7 for <oauth@core3.amsl.com>; Tue, 10 Aug 2010 09:02:56 -0700 (PDT)
Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by core3.amsl.com (Postfix) with SMTP id EAE993A695B for <oauth@ietf.org>; Tue, 10 Aug 2010 09:02:55 -0700 (PDT)
Received: from source ([74.125.82.174]) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTGF4UhGJg+OafrGws2A71mdolmJxwGrU@postini.com; Tue, 10 Aug 2010 09:03:31 PDT
Received: by mail-wy0-f174.google.com with SMTP id 32so1115186wyb.33 for <oauth@ietf.org>; Tue, 10 Aug 2010 09:03:30 -0700 (PDT)
Received: by 10.216.179.20 with SMTP id g20mr15348941wem.45.1281456209250; Tue, 10 Aug 2010 09:03:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.71.5 with HTTP; Tue, 10 Aug 2010 09:02:56 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F1243FB@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <AANLkTinkTA4uSvUB64u2cdnzmYpxjfTTn43PuB9aMo6M@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3F1243FB@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 10 Aug 2010 10:02:56 -0600
Message-ID: <AANLkTimPJ2-HQqC+wsxEsrfw89AhsPUcZNq-=GAYE-na@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 <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: Tue, 10 Aug 2010 16:02:57 -0000

To be honest, I somehow overlooked that particular text - my mistake
and apologies. Reading it again, it probably does preclude parameters
from repeating, however, I can see some room for varied
interpretations as to if that's a strong normative requirement or a
looser suggestion about an error code that could be used in that
circumstance.

Perhaps it could be made more clear by adding some wording about it to
the end of the first part of sections 3&4 where it says: "Parameters
sent without a value MUST be treated as if they were omitted from the
request.  The authorization server SHOULD ignore unrecognized request
parameters."?

That said, does it make sense to relax the ban on repeating parameters
in some situations, like for the assertion parameter, to facilitate
easy encoding of multiple assertions?   Anthony (Tony?) Nadalin
suggested that multiple assertions might be a common use case and I
think allowing for that via repeating assertion parameters is a
cleaner and more reusable way to do it.

The text at the bottom of section for could say something like:

"Parameters sent without a value MUST be treated as if they were
omitted from the request.  The authorization server SHOULD ignore
unrecognized request parameters.  Parameters MUST NOT repeat unless
otherwise noted in the parameter definition."

Then in 4.1.3. the assertion parameter could be something like this:

  "assertion
         REQUIRED.  The assertion(s).  This parameter MAY be repeated
in the request,  if more than one
          assertion is needed for the access grant"


Obviously Eran could improve on the actual text but hopefully that
gets the concept across?



On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> Do we need to clarify 4.3.1 "repeats a parameter" description for "invalid_request" error code does not preclude parameters from repeating? I'm not sure.
>
> EHL
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Brian Campbell
>> Sent: Monday, August 09, 2010 12:34 PM
>> To: oauth
>> Subject: [OAUTH-WG] more than one assertion?
>>
>> The question of allowing for multiple assertions in the SAML profile came up
>> recently.  See http://www.ietf.org/mail-
>> archive/web/oauth/current/msg04068.html and several subsequent
>> messages in the thread.
>>
>> I pushed back on the idea at first due to added complexity.  There are a
>> number of things that need to be addressed that aren't present in
>> the single assertion case.   One of the sticker ones, to me, was how
>> to encode the assertions into the request.   A SAML <Response> element
>> is a nice container for multiple assertions but using it in this context seemed
>> awkward at best.  A new schema could be defined or a special deliminator
>> character could be used but that seems excessive and kludgy respectively.
>>
>> What about pushing it up into the HTTP layer and allowing for multiple
>> occurrences of the assertion=XXX parameter in the POST body?  I don't see
>> anything in core OAuth that would necessarily preclude doing this.
>>  It seems cleaner and more lightweight than some of the other options.
>>  And perhaps it could be a more general (not just SAML) method of sending
>> multiple assertions in a single assertion grant type request?
>>
>> It'd look something like this:
>>
>>   POST /token.oauth2 HTTP/1.1
>>   Host: authz.example.net
>>   Content-Type: application/x-www-form-urlencoded
>>
>>    grant_type=assertion&assertion_type=http%3A%2F%2Foauth.net%2Fasse
>>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=[...1st
>> assertion...]&assertion=
>>    [...2nd assertion...]&assertion=[...3nd assertion...]
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>