Right, and one of the main ways you'd use the chaining grant is by parsing the incoming token as an assertion of some type. They're all blocks that are made to fit together.
-- Justin On Jul 19, 2013, at 3:32 PM, Brian Campbell <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> wrote: FWIW, the 3 assertion documents are more targeted at cross domain type use cases. For example, assuming a trust (and liklely legal) relationship is in place, some corporate system acting as the client can trade a SAML token in at the AS of a SaaS provider for an OAuth access token, which can then be used to do things at the SaaS's RSs 'on behalf' of the subject identified in the assertion. That's not the only way it could be deployed but was one of the main motivating use cases. General access tokens are undefined so one could structure them in a way that works with one of the assertion grants. On Fri, Jul 19, 2013 at 10:40 AM, Manfred Steyer <manfred.ste...@gmx.net<mailto:manfred.ste...@gmx.net>> wrote: Hi Nadalin, that means, that I would use an existing OAuth-2-Token as the assertion for requesting another OAuth-2-Token, right? Section 5.2. „General Assertion Format and Processing Rules” of this draft says, that the assertion has to contain an Issuer as well as an audience. The OAuth-2-Token doesn’t have such fields by definition, but one can argue, that it is associated with an issuer (= auth-server) as well with a scope, which could be seen as the audience in this case. Am I right? Wishes, Manfred Von: Anthony Nadalin [mailto:tony...@microsoft.com]<mailto:[mailto:tony...@microsoft.com]> Gesendet: Freitag, 19. Juli 2013 18:12 An: Prateek Mishra; Manfred Steyer Cc: oauth@ietf.org<mailto:oauth@ietf.org> Betreff: RE: [OAUTH-WG] SAML-like ActAs You can accomplish the ActAs semantics with Assertions profile, while a bit clumsy the basics are in place, the only issue is that you don’t have any way to indicate the formal semantics From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org]<mailto:[mailto:oauth-boun...@ietf.org]> On Behalf Of Prateek Mishra Sent: Friday, July 19, 2013 9:03 AM To: Manfred Steyer Cc: oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] SAML-like ActAs Hi Manfred, This is an area of interest to us and we have done some profiling in our implementation. Generally speaking, we work with the assertion profiles as a starting point. They allow for WS-Trust like token exchanges and (implicitly) support ActAs or OnBehalfOf. But they do need additional profiling to offer genuine interoperability in this area. https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ What use-cases do you have in mind? I am not sure I follow what you mean by "a resource server could delegate a subset of the delegated rights to another resource server". - prateek Hi, are there plans for supporting delegation-styles like ActAs or OnBehalfOf in SAML? If this was possible, a resource server could delegate a subset of the delegated rights to another resource server. This could be a very important thing, when one wants to use OAuth 2 within an enterprise-environment. I know, that OAuth 2 has been created for web-scenarios, but it’s a fact that OAuth 2 is used as a “REST-friedly” alternative to WS-* in the area of service-security. Would it be the right way, to define an Extension Grants for such a scenario? Wishes, Manfred _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
