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

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

  
This sounds fair enough.
-----Original Message-----
From: Tim Moses 
  [mailto:]
Sent: Wednesday, April 10, 2002 5:14 
  PM
To: Beznosov, Konstantin; 
  
Subject: 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:] 
  
Sent: Wednesday, April 10, 2002 10:19 AM 
To:  
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:] 
  
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:  
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>