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 for 3 September 2015 TC Meeting

Time: 4:30 PM EST (-0400 GMT)
Tel: 1-712-775-7031
Access Code: 620-103-760

Minutes for 3 September 2015 TC Meeting

Note: I tried to capture the comments on the New XACML Profiles
discussion, but probably missed some or didn't attribute the
commenter correctly - please advise if you think any
corrections need to be made. Thanks.

I. Roll Call & Minutes

Mohammad Jafari
Steven Legg
Rich Levinson
Bill Parducci	Co-Chair
Martin Smith
John Tolbert

Achieved quorum	yes
Voting Members: 6 of 10 (60%) (used for quorum calculation) 

  bill: we have quorum

  Approve Minutes 20 August 2015 (updated version):

  bill: any objections to unanimous consent to approve minutes:
	none heard
	minutes approved

II. Administrivia

   XACML v3.0 Related and Nested Entities Profile Version 1.0
     (administrative changes)
    public review has been announced:
     advisement of announcement:

  bill: 30 day review; will close day of next mtg

III. Issues

   Ideas for new XACML profiles:
    comments on proposed profiles:


     items proposed he has proposed solns, and interested in dicussion

      1. dynamic attr authority: role enablement

	  it was prev proposed but removed before rbac profile submitted

	  is this role enabled for access subject
	   can result in many requests to find out about roles,
	    so initial idea inefficient

	  for something better, want to get roles that are actually enabled
	   by the context of the current request, based on attrs

	  would supply list of roles required, send to authority, and
	   let role enablement authority determine which roles on the
	   list are enabled.

	  also want to deny roles, not the whole request

	  inclusion and exclusion obligations

	boils down to send request context to dynamic attr authority,

	similar to advice and obligations authority

	existing rules like commit,deny, policy set conditions are mostly irrelevant.
	 simpler "rule engine" for subsets of policy processing.

    rich: could use missing attrs capability to request role attrs
    steven: sounds like interesting alternative

    1a. using xacml policy for notification svc
	similar to workflow, based on attrs, kick off workflow; can be
	 used for other than access control

    martin: why not use conventional adviser to do business rules? drools open source
	and 4-5 langs used by rules engines; not distinction between access rules
	and other business rules.

    steven: starting w xacml went down path of adapting to other use cases.

     bill: re-reading charter: using xacml to non access control decision IS WITHIN
	THE SCOPE of the charter, just mentioning because in logical realm of xacml
	existing charter

   2. redaction: specify parts of docs thru metadata tags on doc what to incl
	and not incl in returned results.

	policy would effectively tell pep what needs to be redacted

    bill: prev work was based email leaving premises based on labels, strings
	in doc that was being requested to leave premises

   3. separation of duty: 2 forms based on rbac: static: if roles assigned to
	user conflict w roles assigned then reject
	dynamic: user has notional roles, subject to activate @ runtime,
	and potentially have conflicting roles, but if not activated then ok

	to activate roles: within session: user can't activate role in a session,
	 must be done prior
	if active in separate sessions then things won't work; also avoid
	 user activate/deactivate then act/de confliting role, also not allowed
	also need to avoid above scenario in 2 separate sessions.

	analysing concept of session: need to remember what roles are activated
	 during a session. 

	martin: can notion be defined within a transaction? as opposed to session
	 which is based on login/logout

	steven: needs to remember logins

	martin: transaction boundaries, as opposed to login boundaries

	steven: issue is need to recall transaction, or more specifically on the
	 resource you are trying to protect. i.e. don't want to hold conflicting
	 roles when applying actions to a particular resource.

	steven: need to record history of actions performed on resource,
	 simply write xacml policy that the current action doesn't conflict
	 w past actions.

	entity profile would provide constraints for separation of duty
	 info might be in audit log; important thing is when operation
	 is requested for a resource, that the history be available to
	 evaluate constraint on resource entity profile.

	attribute describes history entity as a resource; main reqt is for
	 the pep to store the history

	show to use obligations to enforce the constraints

	steven: summary: 3 proposals: need the 1st one, others are if there is
	 additional interest;

	martin: of the 3, sep of duties has been mentioned as important.

	bill: will continue discussion on list; interesting concepts and
	 worth following up, and others not at today's mtg may also want
	 to provide input

   Trust Elevation
    John: posted the latest draft satisfy trust elevation use cases.

	bill: called for discussion - no comments made

  bill: no other items requested to discuss

    meeting adjourned 5:17 PM EDT

Thanks, Rich

Rich Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803

            Oracle Oracle is committed to developing practices and products that help protect the environment

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