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 <cmortim...@salesforce.com> 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...@hueniverse.com> wrote: > > 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 > > > _______________________________________________ > 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
