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

[Eran Hammer-Lahav <[e-mail]>]

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
> >