RE: [xacml] Minutes of XACML TC Meeting, 16 March 2006

["Daniel Engovatov" <dengovatov@bea.com>]

Sorry I could not join.  I take resolution 2 as an action item to
produce a full draft in the direction of my draft's draft. :)   Will do
that by the next week.   I will post work in progress.

Should I just edit the Word version of the 2.0 - or something else?

Daniel;


-----Original Message-----
From: Bill Parducci [mailto:bill.parducci@simulalabs.com] 
Sent: Thursday, March 16, 2006 8:42 AM
To: xacml
Subject: [xacml] Minutes of XACML TC Meeting, 16 March 2006

Minutes of March 16, 2006

Attendees:
   Hal Lockhart (Co-chair)
   Abbie Barbir
   Erik Rissanen
   Bill Parducci (Co-chair, minutes)
   Anne Anderson
   David Staggs
   Ron Williams
   Kamalendu Biswas (new member)


Quorum was achieved (51% per Kavi)

1. Approval of minutes from March 2
    http://lists.oasis-open.org/archives/xacml/200603/msg00001.html

     Approved unanimously

2. Attribute Categories
     http://lists.oasis-open.org/archives/xacml/200603/msg00002.html
     http://lists.oasis-open.org/archives/xacml/200603/msg00003.html

     Daniel (author of the proposal) was not on the call.

     Hal: It is appears Daniel is essentially proposing to push
          attributes out of XML and into URIs.

     Anne: Attribute Categories would be identified by a URI,
           they are no longer fixed element names.

     Hal: What is the benefit to this approach?

     Anne: We have already accepted that we need to add Delegate and
           Indirect Delegate. As long as we have to add two more
           groups why not generalize the attribute model since
           there may be more in the future?

     Erik: Subject, Resource, Action doesn't always fit in the model for
           many implementations (e.g. Erik uses a dummy payload
           for Action in his implementation).

     Hal:  If a message itself has to be passed to provide
           information needed in the policy decision, he currently
           recommends passing it as an Attribute of the Action.

     Anne: But if users can identify a new URI that precisely
           identifies what is being passed, that would be more
           clear.

     Hal:  Is it just easier to add Categories rather than modify the
           model?

     Erik: URI based Categories allow implementers to define new
           Categories without requiring modifications to the
           specification.

     The general consensus is that we should pursue Daniel's
     model, beginning with the identification of new Categories.

     Anne had two questions about the proposal concerning
     specifying "Multiple resource groups" (2.2) and preserving
     the <Resource> and <ResourceContent> elements (4.1).  She
     will post her questions to the list.

3. Issues

     #3 Should elements in a policy target and the request
        context be open?

        This is Daniel's proposal for Attribute Categories.

        STATUS: OPEN and active

     #4 PDP references in policies.

        A concrete proposal is required.  There are two potential
        use cases where the problem can't be solved by simply
        passing referenced policies to one PDP: 1) Not all PDPs
        may be XACML PDPs in a federated authorization model such
        as Frank's Grid environment, 2) Some PDPs may have private
        policies that cannot be passed to one central PDP.

        STATUS: DEFERRED until Administration Policy is completed.

     #5 Policy statements [and attribute assertions] in the
        request context

        Erik will update this issue to rephrase it to refer only
        to Policy in the Request Context.  The issue of whether
        extra attributes possibly needed for delegates should be
        passed in the request context is related to #31 and will
        be moved there.

        STATUS: OPEN and active.

     #6 Identity attributes

        This is a precondition for #31 to work. This will be
        merged into #31

        STATUS: CLOSED.  merged with #31.

     #8 Alternate Owner-Policy-Statement to determine sentinel

        This has to do with cases where PDP can't have its own
        privately configured single Trusted Issuer.
        1) Related to #4: if there are multiple PDPs, each may
           have its own Trusted Issuer.
        2) Requesters may also want to specify the Trusted Issuer
           they want the PDP to use.  The processing model needs
           to know when/how to do match.  Erik suggested as a
           possibility that the RequestContext could contain a
           <TrustedIssuer> that contains a <Delegate> element from
           policy schema; processing model could say to use that
           to do the matching.

        STATUS: OPEN and active.

    #10 Obligations

        Draft 10 addresses Obligations by treating all obligations
        found in policies that are used to reduce an access
        policy as if they appeared in the access policy.  Erik
        will update this issue to reflect current draft.

        STATUS: PENDING REVIEW.

    #23 Access permitted

        Hal is working on a proposal for this that he hopes to
        send out soon.

        STATUS: OPEN and active.  Champion: Hal

4. Next meeting

    Will be on 30 March.  Members encouraged to post Admin Policy
    and Attribute Categories comments by e-mail before then.  The
    meeting on the 30th will continue today's discussion starting
    with Issue#11.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.