----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org> To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ... "I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions. Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ... However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just: 1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)" Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma