[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Minutes of XACML TC Meeting, 16 March 2006
Daniel, Perhaps we should have a complete review of your draft draft first. I would hate to see you do all the work for a spec revision, only to have big changes proposed. We approved the general idea of your draft, but it has not been reviewed thoroughly yet. Thank you very much for writing this up! Regards, Anne Daniel Engovatov wrote On 03/16/06 12:57,: > 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. > > --------------------------------------------------------------------- > 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 > -- 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] | [List Home]