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

[David Recordon <[e-mail]>]

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.

--David


On Thu, Aug 12, 2010 at 1:24 PM, Chuck Mortimore
<[e-mail]> wrote:
> Personally, I’d first like to see more concrete use-cases of how multiple
> assertions are going to be used in practice.   Tony alluded to some abstract
> use-cases, but fuller descriptions would probably help everyone out.
>
> -cmort
>
>
> On 8/10/10 9:15 AM, "Eran Hammer-Lahav" <[e-mail]> wrote:
>
> WFM.
>
>> -----Original Message-----
>> From: Brian Campbell [mailto:[e-mail]]
>> Sent: Tuesday, August 10, 2010 9:03 AM
>> To: Eran Hammer-Lahav
>> Cc: oauth
>> Subject: Re: [OAUTH-WG] more than one assertion?
>>
>> 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
>> <[e-mail]> 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: [e-mail] [mailto:[e-mail]] 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%2Fa
>> sse
>> >>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=[...1st
>> >> assertion...]&assertion=
>> >>    [...2nd assertion...]&assertion=[...3nd assertion...]
>> >> _______________________________________________
>> >> OAuth mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/oauth
>> >
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>