Justin, Yes, you're right, we should do that. We started discussing the idea of the RS somehow exchanging this token for an RPT, but then the RS would have to push this RPT down to the client (perhaps in the header?). Anyway, it started getting complex, and we decided not to proceed with the token exchange for now. And we rejected #1 as potentially too likely to be misconfigured by users--it could lead to the leak of resource id's to third parties. - Mike On 2015-12-28 13:34, Justin Richer wrote:
How is this different from just getting a plain OAuth token instead? Why do you have to invent something?
Part of what drives this line of questioning for me is that #2 below looks suspiciously close to (but not compatible with) the standard core response from the introspection endpoint in RFC7662. Change “permissions”: [“view”, “manage”] to “scope”: “view manage” and you’re there.
— Justin
On Dec 28, 2015, at 11:12 AM, Mike Schwartz <mike@gluu.org> wrote:
Uma-tarians,
Here at Gluu we've been trying to come up with some options for API access management that leverage our UMA capabilities, while reducing the number of steps associated with the permission ticket flow.
We came up with three options:
1) Eagerly issue an RPT token with permissions for resource sets where all scopes are satisfied.
2) Create a new token which just has the expiration and a list of scopes. Something like: { "active": true, "exp": 1256953732, "iat": 1256912345, "permissions": ["view", "manage" ] } And then the RS can evaluate if these scopes are sufficient for access. Maybe this token can be called the EAT (eager access token) or the GST (Granted Scope Token).
3) The RS takes the token above, and uses the OAuth2 token exchange endpoint, (see draft: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 ) to swap out for a real RPT that specifies the scopes, or returns a permission ticket as normal if the scopes aren't suffcient.
#1 has scale problems... especially if the AS has resource sets registered by RS's in many domains. It seems only appropriate for very small deployments in a single domain.
#2 has minimal overlap with UMA.
#3, I guess you have to wonder if it is really much better than the permission ticket flow. It moves complexity to the client, and in a best case, saves two steps (obtaining permission ticket, returning permission ticket).
- Mike
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org