[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] new issue: PolicyIdentifierList scope and order
Paul, Section 5.42 says that this includes policy sets as well. So it was always intended that they include policy sets as well. I would prefer a separate element for the list and not use the policy(id)reference element. These two purposes are very different and it would be confusing if the same element can be used to two such different uses. It would make the description of these elements in the spec more complex since two different uses need to be described in the same section. I don't know whether it is necessary to keep the "namespaces" of policy and policy set identifiers separate. If so, we should add a second element for the list. And if we would change the schema, I would prefer that the identifiers use XML attributes rather than child elements, like this: <PolicyIdentifier PolicyId="foo" Version="1.0"/> It's more compact and readable. And elements are not needed since each policy identifier has a one to one mapping to the two components. Regarding your proposal that the policy id should be the id which resulted in the decision, then it would be against the explicit design of the original proposal. Also, it is very, very complex issue the define which of the multitude policies was the "significant" one. I wouldn't like to go there. At least not in the 3.0 timeframe. Best regards, Erik Tyson, Paul H wrote: > Hi all, > > When I first saw PolicyIdentifierList in a v3 working draft, I assumed > it included PolicySets as well as Policies. But now that I read cd-1 > section 5.49 closely, I see it only mentions policies. > > My use case requires an ordered list consisting of 0 or more PolicySet > ids and 1 Policy id that were successfully evaluated to return the > decision. But I don't see that PolicyIdentifierList will provide this, > as currently specified. > > I propose that PolicyIdentifierList be specified as an ordered list of > PolicySet and Policy ids that were successfully evaluated to reach the > decision. Each item in the list would have the Policy[Set] id and > version, as currently specified. > > Further specification might be necessary for PolicySets, to avoid > ambiguity in the case where two or more children were evaluated > successfully. In this case, the final id should be the id of the > policyset whose policy-combining-algorithm resulted in the decision that > was returned. I have not analyzed this much, and we do not use exotic > combining algorithms, so more analysis is required. > > It might be possible to use <PolicySetIdReference> and > <PolicyIdReference> in this list, instead of creating new element types. > In this context the EarliestVersion and LatestVersion attributes have no > meaning. > > If the IdReferenceType element types are used, the definition of > PolicyIdentifierList would be: > > <xs:element name="PolicyIdentifierList" > type="xacml:PolicyIdentifierListType"/> > <xs:complexType name="PolicyIdentifierListType"> > <xs:choice minOccurs="1" maxOccurs="unbounded"> > <xs:element ref="xacml:PolicySetIdReference"/> > <xs:element ref="xacml:PolicyIdReference" /> > </xs:choice> > </xs:complexType> > > Section 5.50 and the <PolicyIdentifier> element could be deleted. > > Regards, > --Paul > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]