+1 Brian's profile serves a distinct purpose. I don't see a problem with different assertion profiles for using SAML with OAuth, especcially given the wide usage of SAML.
Regards, Torsten. Am 04.08.2010 um 07:21 schrieb Eran Hammer-Lahav <e...@hueniverse.com>: > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
