The single assertion use case is well defined. If you need to support multiple assertions in a single request, you will need to define a way to group them together and include them using the single assertion parameter or define an extension for additional assertions. Either way, this sounds like something that belongs in its own spec.
EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Anthony Nadalin > Sent: Tuesday, August 03, 2010 3:29 PM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 > draft > > This is a use case we are seeing from the various government agencies (UK, > USA, BC), I agree it add complexity but with having to satisfy several claims > (i.e. over 21 and being a resident of sate) this seems to be pretty common > these days. > > -----Original Message----- > From: Brian Campbell [mailto:bcampb...@pingidentity.com] > Sent: Tuesday, August 03, 2010 1:12 PM > To: Anthony Nadalin > Cc: oauth > Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 > draft > > Seems like a much more complicated scenario. Allowing more than one > assertion, off the top of my head, would necessitate some major changes to > this profile: > > * Define how multiple assertions are encoded into the single "assertion" > form control (samlp:Response, concatenated, something > else?) > * Deal with subject equality across the assertions > * Define the processing rules for multiple assertion (from different > issuers) and the expected behavior when some but not all are valid. > > That seems like it would add significant complexity to the existing draft > (that > I'm trying to keep simple) for a particular scenario that I'm not sure is very > common. But maybe I'm wrong. Is this something > that others anticipate needing? If so, does it belong here? > > > On Mon, Aug 2, 2010 at 4:26 PM, Anthony Nadalin > <tony...@microsoft.com> wrote: > > So the scenario we have is where there are multiple tokens from attribute > and identity providers need to be delivered to an OAuth authorization server > to satisfy the resource owner's policy of required claims. So this is a case > where a single SAML token/assertion is not enough to satisfy the claim, we > still expect that the signature verification is out of scope. > > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Brian Campbell > > Sent: Monday, August 02, 2010 2:53 PM > > To: oauth > > Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth > > 2.0 draft > > > > I guess I'd need to understand the scenario better before I'd have an > > opinion one way or the other. However, I will say that In this > > profile I was specifically looking to avoid the complexity that exists in > > SAML > Web SSO by allowing for multiple assertions and multiple subject > confirmations. > > > > On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin > <tony...@microsoft.com> wrote: > >> There are many cases where we need to have more than 1 SAML > assertion be used to represent the authorization token, so would want a > provision for multiple SAML tokens and not sure it makes sense to have a > separate profile for that or add it as an option here. > >> > >> -----Original Message----- > >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >> Behalf Of Brian Campbell > >> Sent: Thursday, July 15, 2010 1:50 PM > >> To: oauth > >> Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 > >> draft > >> > >> I'm gong to join the growing list of people attaching a potential I-D > >> to an email due to he cut off time for the I-D submissions. Attached > >> is a draft that aims to tightly define the particular format of a > >> SAML > >> 2.0 bearer assertion in requesting an access token using the > >> assertion grant_type. I've been working with Chuck at > >> Salesforce.com on this and the primary goal is to have some > >> documentation or specification that is sufficient to facilitate > >> interoperability between independently developed implementations or > products. This, of course, wouldn't preclude using SAML in other ways - it > would only provide one concrete definition to implement against. > >> > >> I intend to submit this as an I-D when the submission process reopens. > >> Any feedback from this group would be appreciated as well as thoughts > about this eventually becoming a working group draft. > >> > >> Thanks, > >> Brian Campbell > >> > > _______________________________________________ > > 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
