WFM.
> -----Original Message----- > From: Brian Campbell [mailto:bcampb...@pingidentity.com] > 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...@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-boun...@ietf.org [mailto:oauth-boun...@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%2Fa > sse > >> 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
