The only change I'm aligned with is being more specific about repeating parameters and potentially allowing the assertion parameter to repeat. That's it for the core spec. The SAML spec should be more specific about allowing or not multiple assertions for the given type URI.
EHL > -----Original Message----- > From: David Recordon [mailto:record...@gmail.com] > Sent: Thursday, August 12, 2010 12:36 PM > To: Chuck Mortimore > Cc: Eran Hammer-Lahav; Brian Campbell; oauth > Subject: Re: [OAUTH-WG] more than one assertion? > > 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
