Hi Prateek,
thouse drafts go in the right direction, but as you mention, they need additional profiling. The drafts, that Justin mentioned in the mail before (see [1] and [2]), seem to do exactly that. With "a resource server could delegate a subset of the delegated rights to another resource server" I mean the scenario, that is addressed by [1]: 1. Client gets an OAuth-2-Token T1 with the scope A, B, C 2. Client uses T1 to call service A (which expects a token with the scope A) 3. Service A exchanges T1 for another token T2 containing just the scope B (which is a real subset of the scope of T1) 4. Service A uses T2 to access service B (which expects a token with the scope B) [1] goes one step further by allowing claim-mapping, so that the holder of a token can exchange it for a other token with another scope. This would, for instance, allow for a delegation trough the boundary of a security-domain, case you could introduce rules like: Everyone, that has the scope Projekt-A at company X gets the scope Plans-for-A at company Y. [1] <http://tools.ietf.org/html/draft-richer-oauth-chain-00> http://tools.ietf.org/html/draft-richer-oauth-chain-00 [2] <http://tools.ietf.org/html/draft-hunt-oauth-chain-01> http://tools.ietf.org/html/draft-hunt-oauth-chain-01 As mentioned, [1] and [2] are expired, but in my opinion they are just perfect for doing such scenarios with OAuth 2 and so they would deserve to become a standards. What can we do, to achieve this goal? In addition to that, OpenId Connect, which bases on OAuth 2, could provide such scenarios, as mentioned in the mail before. Wishes, Manfred Von: Prateek Mishra [mailto:[email protected]] Gesendet: Freitag, 19. Juli 2013 18:03 An: Manfred Steyer Cc: <mailto:[email protected]> [email protected] Betreff: 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
