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>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] > *Gesendet:* Freitag, 19. Juli 2013 18:12 > *An:* Prateek Mishra; Manfred Steyer > *Cc:* 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] *On Behalf > Of *Prateek Mishra > *Sent:* Friday, July 19, 2013 9:03 AM > *To:* Manfred Steyer > *Cc:* 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**** > > 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
