RE: [xacml] Possible future XACML TC work

[Michiharu Kudoh <KUDO@jp.ibm.com>]

More items for possible future work...

1-e) Condition reference: it is often the case that a policy writer repeats
the same expression in <Condition> element. To avoid this repetition, XACML
provides a condition definition block in addition to the policy
specification block. From the policy, a specific condition expression is
referred to by using condition ID that is defined in the condition
definition block. This is also useful for improving performance.

1-f) Property: when you create a new combining algorithm, the algorithm
would need some place to specify domain-specific information. My suggestion
is to allow a policy writer to add <Property> element with type:value pair
at arbitrary place he wants to specify in the policy, rule, context etc..
Since this is only for the extended combining algorithm it never affect the
semantics of predefined combining algorithms such as deny-overrides. This
extension is needed because the current XACML schema is very strict and it
does not allow such additional elements.

1-g) Obligation in rule element: allow each rule to have obligations (of
course optional). It is straight-forward to provide the semantics by
reusing the semantics for the policy-level obligation specification in the
current spec.

Michiharu

----- Forwarded by Michiharu Kudoh/Japan/IBM on 2003/02/13 19:27 -----
                                                                                                                                       
                      Michiharu                                                                                                        
                      Kudoh/Japan/IBM@I        To:       XACML TC <xacml@lists.oasis-open.org>                                         
                      BMJP                     cc:                                                                                     
                                               Subject:  RE: [xacml] Possible future XACML TC work                                     
                      2003/02/13 16:38                                                                                                 
                                                                                                                                       
                                                                                                                                       




Can I add one other item for possible future work?

2. Profiles and bindings

  - f) Define a set of domain-specific identifiers (action, combining
algorithm etc.) that are used in well-known domains e.g. UNIX ACL, Windows,
database ...

Michiharu




                      Carlisle Adams

                      <carlisle.adams@e        To:
"'Anne.Anderson@Sun.com'" <Anne.Anderson@Sun.com>

                      ntrust.com>              cc:       XACML TC
<xacml@lists.oasis-open.org>
                                               Subject:  RE: [xacml]
Possible future XACML TC work
                      2003/02/13 05:15






Hi Anne,


Thanks for putting this list together!


Can I add one other item for possible future work?


7. Exploration of whether and how XACML can be used to express privacy
policies.


On first glance, this might seem out of scope for our charter, but I don't
think it is.  If a corporate entity writes a policy saying "A requester can
only see the pre-release quarterly report if the requester is an executive
of the company", and a person writes a policy saying "A requester can only
see my health record if the requester is a doctor", then these both seem
like access control policies and they use similar syntax.  But the latter
would generally be regarded as a privacy policy and the former wouldn't.
In practice, there may be little or no difference between a privacy policy
and any other kind of access control policy, and so XACML might be an
appropriate fit in the privacy world.  I think this is probably worth
exploring a little bit to see if I'm way off base...


Carlisle.





-----Original Message-----
From: Anne Anderson [mailto:Anne.Anderson@Sun.com]
Sent: Wednesday, February 12, 2003 2:33 PM
To: XACML TC
Subject: [xacml] Possible future XACML TC work


Here is a list of suggestions for future XACML TC work.  I
believe all of this is within our charter.


1. XACML 1.0+: RFE's based on actual usage
   a) Fully specify hierarchical resources
   b) Define new combining algorithms for deterministic
      Obligations.
   c) ebXML: Allow references to Rules (as we now allow for
      policies and policy sets)
   d) Incorporate fixes for errata
2. Profiles and bindings
   a) SAML: revised AuthorizationDecisionStatement,
      AuthorizationDecisionQuery, Response to support XACML
      Request and Response Context [Anne and Hal working on this]
   b) XMLDSig: how to sign XACML policies, requests, responses
      [Anne working on this]
   c) LDAP:
      1) how to store and retrieve policies using LDAP
      2) how to store and retrieve attributes using LDAP [already
         defined?  Simon?]
   d) ebXML:
      1) how to store and retrieve policies using ebXML
      2) how to store and retrieve attributes using ebXML
   e) Transport protocols (in addition to SAML wrapper)
3. Additional Conformance Tests
4. XACML Extensions
   a) WS-Policy [Tim's proposal]
   b) Information about how/where to obtain policies and
      attributes; how to authenticate them (e.g. trust anchors)
5. XACML Primer [Hal and Konstantin working on this]
6. XACML Implementer's Guide


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>