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 29 October 2015 TC Meeting

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

 (REMINDER: next mtg begins 2:30 EST (-0500 GMT) mtg starting time)

Minutes for 29 October 2015 TC Meeting

I. Roll Call & Minutes

 Roll Call:

Richard Hill
Steven Legg
Rich Levinson
Hal Lockhart	Chair
Bill Parducci	Chair
Remon Sinnema
Martin Smith

Quorum rule	51% of voting members
Achieved quorum	yes

  bill: we have quorum

  hal: any items to add to agenda? none heard

  hal: reminder next mtg: new time:

	2:30 PM EST (-0500 GMT)

 Approve Minutes 15 October 2015:

    hal: any objections to unan consent?
	none heard;
	minutes approved

II. Administrivia 

  Special Majority Ballot to approve XACML v3.0 Related and Nested Entities Profile Version 1.0
   as a Committee Specification
   hal: no comments rcvd:
   tc-admin: ballot approved:

    hal: Related and Nested Entities Profile now an official Committee Spec
          TC will consider advancing it to OASIS Std

  US NIST 1800-3 ABAC
    martin: suggested TC comment to NIST:
    john: +1

   martin: companies signing up to produce impl solns, but if not part
	   of soln, then out of luck
	  better approach would be abstract requirements, which would
	   allow swap in and out. Only clear how to connect specific
	  where interfaces have stds, should be observed

   hal; just looked at: zips w release notes

   martin: that is probably the "long version";
	   diagram of specific products together

   rich: link to site containing the docs from Martin's fwd'd email:
     discussion today referring specifically to the middle document:

   hal: people should look over the document above and we can discuss if we
	want to comment on it @ next mtg (@ new time)

  IDEF v.1 spec from 
   Fwd: [Idesg_members] Sharing the IDEF v.1 with the world
     (Identity Ecosystem Steering Group (IDESG)) 
     (National Strategies for Trusted Identities in Cyberspace (NSTIC))

    hal: any comments:
    martin: part of NSTIC
             they have approved a 1.0 framework:

    rich: the following link from the email looks like it is the top of the
	  IDEF technical web site:

III. Issues/Open Discussion (last comment)

  Default behavior for unrecognized resource attributes? 
   original: Martin:
   martin: re-open discussion: (clarifies: only resource attrs, not user attrs)
   erik: -1:
   ray: -1:
   martin: requests clarification of user vs resource attrs:
   erik: proposes alternative using "tag" attr:
   eriK: suggests it is "outside" xacml std domain:
   martin: gives example to clarify:
   hal: considers unrecog attrs as "not a problem":
   martin: response to hal's points:
   ray: consider "closed world assumption":
   martin: response to ray: clarify "example policies":
   ray: suggests alternative approach to addr problem using PAP:
   martin: agrees there are viable alternatives: wants to focus on core reqt:

  martin: people on thread pointed out tag alternatives,
	   but if someone putting on tags saying this is nature of product,
	    then that should be part of set of artifacts, that imply that
	    is how the document is protected.
	  issue is how do you go beyond this implicitly specified info

  hal: maybe a tool based on semantic models; posted additional comments before mtg:

  hal: combining algorithms: have defaults, some std logic

  rich: reminds of the SOAP MustUnderstand flag, where if recipient gets
	 msg w something that is not understood then an error should be
	 returned. Maybe that turned out not to be so useful, as it doesn't
	 appear to be showing up in the new json/oauth token specs.
  hal: doesn't think it is analogous

  meeting adjourned 5:05 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]