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: [email protected] [mailto:[email protected]] 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 <[email protected]> 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: [email protected] [mailto:[email protected]] 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
