Hi Lisa, This is a really good point. We have been working on an approach for a common consent record format that we call the Minimum Viable Consent Receipt. The aim with this specification is to provide the common components to consent in a framework that is easily localised. The aim I think here is to use this as a base profile for consent and then to develop further from there. We are currently on v0.7 of this specification and aim to have a project kit for making consent profiles that dee with the variability of consent notice requirements which can be operationalised with UMA. To find out more about about the spec, please take a look at the latest draft http://openconsent.github.io/ConsentReceipt/specification/KI-CISWG-Editorial.... We also have a website going up very soon with a demo api and some additional resources via GitHub. Kind Regards, Mark -PS. Eve, just saw your email, will have a look and respond when I get the chance.
On 22 Dec 2015, at 10:14, Lisa Moon
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 mailto:lisa.moon@advocate-consulting.com
On Mon, Dec 21, 2015 at 9:38 PM, Allan Foster
mailto: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.
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. 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/
Allan Foster - ForgeRock VP Strategic Partner Enablement Location:San Francisco p: +1.214.755.9218 tel:%2B1.214.755.9218 email: mailto:allan.foster@forgerock.comallan.foster@forgerock.com mailto:allan.foster@forgerock.com blogs: blogs.forgerock.com/GuruAllan http://blogs.forgerock.com/GuruAllan Skype: Call GuruAllan http://is.gd/lWVfMG www: www.forgerock.com http://www.forgerock.com/ www: www.forgerock.org http://www.forgerock.org/
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma