Hey, I'm always up for a good disquisition ("a long or elaborate essay or discussion on a particular subject"). :-) In fact, I did try new wording in rev 13 already based on the fact that with our set math I couldn't make heads or tails of the MUST wording (note that this comes after the new agreed wording about the AS having a choice to respond with an RPT or a failure if the scopes satisfied are less than the scopes requested):"Note: While a reasonable approach for most scenarios is to implement the classic security stance of default-deny ("everything that is not expressly allowed is forbidden"), corner cases can inadvertently result in default-permit behavior. For example, it is insufficient simply to assume that all resources have some non-zero set of claims required for access, and then accept an empty set of supplied claims as sufficient for access."This was in order to advise anyone starting to build an AS from scratch about some of the best practices and subtleties of policy engine and access control work. Thoughts?On Wed, Jan 25, 2017 at 8:32 AM, James Phillpotts <james.phillpotts@forgerock.com > wrote:______________________________Hi all,Thanks for the reminder to send this email Eve! ;)The paragraph in question is:The authorization server MUST use a default-deny authorization assessment model in adding permissions to RPTs, that is, "everything that is not expressly allowed is forbidden" for resources for which resource servers have requested access permission on behalf of clients. Exercise caution in implementing default-deny because corner cases can inadvertently result in default-permit behavior. For example, it is insufficient simply to assume that all resources have some non-zero set of claims required for access, and then accept an empty set of supplied claims as sufficient for access.I'm not convinced that this paragraph is really very useful, but that may be because it isn't clear at what level the 'deny' is relating to in this context - is it on a per-resource, per-scope, or an RPT level?If per-resource, I think this is a reasonable thing to express, but I'm not sure the paragraph does a particularly good job of it.If per-scope, does this only apply to additional scopes requested by the client?If RPT, then I don't think the idea is correct, as the RPT shouldn't be denied based on the outcome of a particular policy for a particular resource.On one of the calls I thought someone had mentioned that the RPT should only be granted if all of the scopes requested in the permission ticket were able to be granted, but I think it should be perfectly reasonable to grant a subset - e.g. if ticket requests view, edit for resource A and view for resource B but all that can be granted is view for A, then that is a perfectly reasonable response?This was partly triggered by Mike's suggestion of patterned URIs, where I was thinking about the RS wants either view on A, view on B or view on C, because it knows that the actual requested URL is covered by all 3 of those registered resource sets (although as per other email, I wouldn't like that to be a pattern).Sorry if this is slightly rambling.Cheers,James_________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma