[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] problem understanding resolution for issue PM-2-06
Yes, Anne's explanation is very helpful. At the same time, if the resolution text to be included verbatime in the spec, then it seems to me that the resolution text needs some work to make the point more clear and less ambiguous. On the other hand, if Tim, or somebody else, is going to come up with another version of the wording for the spec, then the resolution will suffice. This makes me wonder what should be an end result of an issue resolution. Something tells me that any issue resolution should result in the spec changes since XACML spec is the only (at least the key) outcome, visible to the external parties, that this TC has. If this premise is correct, then spec changes that correspond to a resolution should be part of the resolution and not left up to the editor or anybody else because nobody can guarantee correctness of a translation from a resolution to the changes in the spec. If you are still with me, then may I suggest that all issue resolutions are made in a form that clearly states what changes should be done to the spec text and the schema, i.e. what text is deleted/inserted/modified. For example, one would expect that resolution of issue PM-2-06 says something like "Add the following paragraph right after line XXX of 0.12 draft: ..." Regards Konstantin -----Original Message----- From: Anne Anderson [mailto:Anne.Anderson@Sun.com] Sent: Wednesday, April 10, 2002 9:36 AM To: Beznosov, Konstantin Cc: Anne Anderson Subject: Re: [xacml] problem understanding resolution for issue PM-2-06 On 9 April, Beznosov, Konstantin writes: [xacml] problem understanding resolution for issue PM-2-06 > I'm having a problem to understand the proposed resolution for PM-2-06: > > =============================================== > PM-2-06: Encapsulation of XACML policy (Anne) > Proposed Resolution: The XACML syntax will not contain its own > security features. An XACML rule has no XACML-specified > encapsulation. An XACML policyStatement or > policyCombinationStatement MAY be encapsulated in a SAML > assertion. > ================================================ > First, since the issue documentation in the issue list does not have the > description of the issue, I'm not sure what the problem to be addressed > is. Maybe this leads me to the failure to grasp the proposed resolution. > Could somebody explain in plain and non-normative English what the issue > is and what the proposed resolution text means? [I still can't send to the list (my mail system was reconfigured), so could you forward this to the list for me. -aha] The issue was whether we would define, as part of the XACML policy specification, elements for signature, signer name, algorithm, etc., or whether we would rely on embedding an XACML policy inside a SAML assertion (which can have that type of security information) if such security was desired. Initially, the concern was that, unless the elements were in XACML itself, policy writers could not condition access on things like whether the policy was signed by a particular person. We resolved that concern by allowing a reference to a policy statement to be a reference to an entire SAML assertion in which the policy statement was embedded. In this case, a policy combiner could choose a policy based on signer, etc. Does that help? Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC