OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Minutes 26 March 2009 TC Meeting

Time: 10:00 am EDT
Tel: 512-225-3050 Access Code: 65998

Minutes for 26-Mar-09 XACML TC Meeting:

10:00 - 10:05 Roll Call & Approve Minutes

    Note: we are going back to bi-weekly schedule.
	Next meeting is April 9.

  Voting Members

    Erik Rissanen  	Axiomatics AB
    Rich Levinson 	Oracle Corporation
    Hal Lockhart 	Oracle Corporation
    Anil Saldhana 	Red Hat
    Dilli Arumugam 	Sun Microsystems
    John Tolbert 	The Boeing Company


    Anthony Nadalin 	IBM 	Group Member

    Dilli (should have been) promoted to voting member 
     before the call. 
    Tony became a voting member after the call.

	not sure if quorum

   19 March 2009 TC Meeting minutes to approve:

    above links are identical
    hold off approval to next mtg (4/9) in case we're not at quorum

10:05 - 10:10 Administrivia

   Volunteers for editorial cleanup request

    Hal: fair amount of work to pass Mary's test.

     John Tolbert: core and saml
     Dilli also volunteers

    Hal: looking to go to cd 2 weeks from today (goal)
    Rich: aggressive?
    Hal: goal, maybe month

    Erik: try for 2 weeks

    Hal: we will try to have docs ready for April 9 mtg.

    John: how are we going to make changes? post to list?
    Hal: people signup for docs, post new drafts
    Rich: what is list of operations?
    Hal: oasis checklist, plus internal inconsistencies, fixing is
     easy when found.
    Rich: need care on identifiers
    Hal: identifiers all stay same; new are version 3.
    Hal: up front URIs can be left until we are ready for cd, oasis
     will assign us URI(s);
     Links on "members only" page; follow link to tech details: following
       links to oasis spec info/reqts for updates in prep for CD.


   v3.0 Core, Draft 10 uploaded

    Erik: corrections, plus Category on Obligations

   v3.0 XACML/SAML Profile, Draft 7 Uploaded

    Hal: added new section in request section
	ws-fed: common claims dialect: indicated could do on xacml
	ws-trust: provides alternative both quite similar, should
	 be easy to support both in parallel

    Hal: will add an example in ws-trust section

   v3.0 Hierarchical Profile, Draft 6 uploaded
    cover email for hierarchical

    Hal: attempted to make changes based on earlier proposal 
     that Hal emailed;

     Hierarchical URI
     ancestor attributes: self, parent, ancestor, ancestor-or-self;
      also can use any xacml data type
     concern: the "one true name"; Hal thinks it is general issue,
      discussed in core security considerations;

     Rich's comments will be probably be incorporated at first glance

   Misc topics:
    Anil S: (arrived late): There is interop (next week) in Chicago 
	that he, David, Duane, others? working on.

10:10 - 11:00 Issues

   Obligation Question: "AttributeAssignment@Issuer"

     Rich: optional Issuer attr add to Obligation: agreed w Erik.

   Discussion on WD 4 of Muliple Resource Profile

     Erik: we don't send multiple response even though we have
      multiple requests
     Erik: If list is incorrect, there is only one Result.
     Rich: partial results should be reported
     Erik: basically ok

   Discussion on WD 6 of  Hierarchical Profile

    Rich: multiple hierarchies should be described in some
	tangible manner so that operational bullets can be
	described clearly. 

    Hal: thinks we are in agreement will try to make some
	clarifications based on comments.

    Rich: below is some more detail on "what the concept is".
     Specific means of presenting the concept is not of concern,
     just that the concept gets across. One sidepoint is that
     within a given "hierarchy" there is no problem if that
     single hierarchy is a DAG w multiple roots. The only concern
     is that the DAG properties of one hierarchy not "spill over"
     into other hierarchies. Since the DAG, itself, may be the
     result of combining multiple hierarchies, that may be where
     the confusion originated. In this case if multiple original
     hierarchies are combined into a DAG for some subset (M<=N) of 
     thetotal set of original hierarchies, that is no problem. 
     There will then be a new set of "original hierarchies consisting
     of the DAG plus the N-M remaining hierarchies that were not
     combined into the DAG. In this case in the description below
     the resources originally would have had N slots. Now they
     would have N-M+1 slots. 

	  For example, if a resource can be envisioned as 
	  having a set of "slots", each of which is assigned 
	  to one of N possible hierarchy memberships, then
	  if the resource has an entry in some subset of those
	  slots, then the value would be its "identifier" 
	  within that particular hierarchy.

	  Whenever the organization managing the resources
	  decided it had some new hierarchical structure that
	  it wanted to use with some or all of the resources,
	  then a new "slot" would be created identifying the
	  new hierarchy. i.e. these "slots" would have two
	  components: 1. a unique identifier for the hierarchy
	  with which the slot is associated. 2. an identifier
	  for the resource by which it is known in that 
	  hierarchy, which as discussed can be of any xacml
	  datatype. Each hierarchy has its own rules for its
	  own members in terms of naming.

	  Also, a resource typically would only need to hold
	  the slots for which it is a member. If it only belonged
	  to one hierarchy, it would have one slot with the
	  name of the hierarchy, and its name within the

	  My point is not to go overboard on how a resource's
 	  membership in multiple hierarchies is implemented,
	  just the notion that there is some kind of mechanism
	  that serves the overall purpose. Another analogy would
	  be the credit cards in a person's wallet. If you had
	  3 credit cards you'd be a member of 3 credit card
	  hierarchies, each separate and distinct, but their
	  identifiers are all collected together conveniently
	  in your wallet. Similar for resources: they would
	  have a wallet of "slots" etc. 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]