RE: [xacml] problem understanding resolution for issue PM-2-06

[Tim Moses <tim.moses@entrust.com>]

Title: RE: [xacml] problem understanding resolution for issue PM-2-06

Konstantin - According to my understanding, we are currently attempting to get "agreement in principle".  A particular resolution may have implications throughout the specification.  So, it seems more efficient to allow the editor one attempt to update the specification in accordance with the resolutions.  After that, we should turn our attention to crafting the text.  Naturally, if disagreements arise over the specific text of the next version of the specification, then we should reexamine the resolutions.

So, I propose that, once we have nailed down this batch of issues, I will produce a v13.  Then let's see if we can progress by commenting on the actual text of that version.  Any objections?  All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183

-----Original Message-----
From: Beznosov, Konstantin [mailto:Konstantin.Beznosov@Quadrasis.com]
Sent: Wednesday, April 10, 2002 10:19 AM
To: xacml@lists.oasis-open.org
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

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>