OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xacml] REST Profile - PAP Issues

> How is a cohort of policies not a policyset? Your statements read
> perfectly well if you replace "cohort" with "policyset".  The only
> difference I can think of is a cohort does not appear to define a
> combining algorithm, but if a PDP is evaluating requests against a
> cohort of multiple policies, there must be some sort of default
> combining algorithm in play for the cohort.  So why not just say
> policyset?

First of all, in a environment with only Access Policies (no Admin Policies) the Cohort is allowed to contain a bunch of Policies and PolicySets which do not have a common root PolicySet. In this case the PDP is required to treat each tree (free standing policy or top level PolicySet and its children) as a member of a virtual top level policy set. The Policy Combining Algorithm for this virtual Policy Set is a PDP-wide parameter which can be advertized via Metadata (once we do the Metadata Profile).

With Admin policies, things get a good bit more complex. First, the Admin policies themselves form an actual or virtual tree of policies separate from Access Policies. (Or are the multiple trees for multiple issuers? Erik can you help me here?)

Also, Admin policies enable the use of per-decision policies which are provided at decision time and combined with the Cohort for the duration of that particular decision. When we developed the Admin profile, there was discussion of use cases where the per-decision policies could sensibly be leaf policies, higher level policy sets or even Admin policies. Therefore there can be gaps in the tree at various points.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]