On Tue, Dec 22, 2015 at 12:18 PM, Eve Maler <eve@xmlgrrl.com> wrote:
<snip>
- Remember that the RPT that a client brought to the resource server associates that client, its requesting party, the authorization server, and that resource server; the RS may possibly have introspected it to reveal permissions (assume the default "bearer" token profile) that are associated with other resource owners, not just Alice. Any logging of permission data on Alice's behalf has to be privacy-sensitive and stick to what's relevant to her.
<snip>
How and why does the RPT reveal permissions associated with other resource owners? Isn't the interaction between RS and Client always in a specific RO context? Adrian
On Tue, Dec 22, 2015 at 7:14 AM, Lisa Moon < lisa.moon@advocate-consulting.com> wrote:
Allan,
I don't know if this comment will be useful - but here goes.
Your final statement "My Concern is that the RS is ALWAYS the final arbitrator of access control, whether UMA, DAC or MAC. It should be able to modify its behavior based on local business rules and exceptions" exposes part of a much larger problem in consent management...namely, local interpretation of business rules related to privacy, etc.
Local interpretation creates a high degree of variance - making MANY rules difficult to operationalize. Keeping this in mind and finding a common standard, even at a basic technology level would help moderate the variance caused by local interpretation.
Lisa Moon Principal Consultant Advocate Consulting LLC (c) 952-913-7263 lisa.moon@advocate-consulting.com
On Mon, Dec 21, 2015 at 9:38 PM, Allan Foster <allan.foster@forgerock.com
wrote:
Folks, I am concerned about putting specific obligations on the RS and thus subjagating it to the AS.
Specifically to allow for Enterprise MAC with UMA participation, where the End user is a participant in the access control decision, but not the only participant.
1. *Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md>-Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorizing_Party_0.md>: Delegate-Protection* For the period that the Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md> and Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorizing_Party_0.md> have mutually agreed to serve in these respective roles for each other, theResource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md> gains an obligation to the Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorizing_Party_0.md> to delegate protection services to the Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_Operator_0.md> for the set of protectable resources for which it represents this capability to the Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorizing_Party_0.md>, and to respect the authorization data that the Authorization Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_0.md> has associated with an RPT <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Abbreviation/RPT_0.md> when the Resource Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_0.md> subsequently allows or disallows access by the Client <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Client_0.md> that presented that RPT <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Abbreviation/RPT_0.md> .
My concern here is that it delegates "Protection services" to the AS, and this feels a little like an all or nothing. This might not be true in the case where the RO is only one party in the Access control decision.
1. *Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md>-Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_Operator_0.md>: Respect-Permissions* For the period that the Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md> and Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_Operator_0.md> have mutually agreed to serve in these respective roles for each other, the Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md> gains an obligation to the Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_Operator_0.md> to disallow access by a Client <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Client_0.md> presenting an RPT <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Abbreviation/RPT_0.md> in all cases where the authorization data associated by the Authorization Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_0.md> is insufficient for the access attempt..
The RS is obligated to dissallow access in the AS cannot provide sufficient rights - in all cases.
This has several implications. If the RS has additional business rules whereby a party might get access even tho they are not UMA authorized, (break glass?) (Admin or Help Desk) The RS HAS to determine if a user is a special user BEFORE making the request to the AS. Since once it has an answer, it is obligated to deny. This implies that the RS cannot opt out once the request to the AS is made.
It feels a little bit like don't ask don't tell!
My Concern is that the RS is ALWAYS the final arbitrator of access control, whether UMA, DAC or MAC. It should be able to modify its behavior based on local business rules and exceptions.
Allan
-- Simplify Email: Email Charter <http://emailcharter.org/>
[image: ForgeRock Logo] *Allan Foster - ForgeRock * *VP Strategic Partner Enablement* *Location:*San Francisco *p:* +1.214.755.9218 *email:* <allan.foster@forgerock.com>allan.foster@forgerock.com *blogs:* blogs.forgerock.com/GuruAllan *Skype:* Call GuruAllan <http://is.gd/lWVfMG> *www:* www.forgerock.com *www:* www.forgerock.org
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/