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: https://lists.oasis-open.org/archives/xacml/201510/msg00009.html 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 https://lists.oasis-open.org/archives/xacml/201510/msg00010.html hal: no comments rcvd: https://lists.oasis-open.org/archives/xacml/201510/msg00011.html tc-admin: ballot approved: https://lists.oasis-open.org/archives/xacml/201510/msg00013.html hal: Related and Nested Entities Profile now an official Committee Spec TC will consider advancing it to OASIS Std US NIST 1800-3 ABAC original: https://lists.oasis-open.org/archives/xacml/201510/msg00003.html martin: suggested TC comment to NIST: https://lists.oasis-open.org/archives/xacml/201510/msg00012.html john: +1 https://lists.oasis-open.org/archives/xacml/201510/msg00015.html 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 pieces. 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: https://nccoe.nist.gov/projects/building_blocks/attribute_based_access_control discussion today referring specifically to the middle document: https://nccoe.nist.gov/sites/default/files/nccoe/NIST_SP1800-3b_ABAC.pdf 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 https://lists.oasis-open.org/archives/xacml/201510/msg00014.html (Identity Ecosystem Steering Group (IDESG)) (National Strategies for Trusted Identities in Cyberspace (NSTIC)) https://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf 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: http://www.idesg.org/The-ID-Ecosystem/Identity-Ecosystem-Framework/IDEF-Core-Documents III. Issues/Open Discussion (last comment) Default behavior for unrecognized resource attributes? original: Martin: https://lists.oasis-open.org/archives/xacml/201509/msg00026.html martin: re-open discussion: (clarifies: only resource attrs, not user attrs) https://lists.oasis-open.org/archives/xacml/201510/msg00016.html erik: -1: https://lists.oasis-open.org/archives/xacml/201510/msg00017.html ray: -1: https://lists.oasis-open.org/archives/xacml/201510/msg00018.html martin: requests clarification of user vs resource attrs: https://lists.oasis-open.org/archives/xacml/201510/msg00019.html erik: proposes alternative using "tag" attr: https://lists.oasis-open.org/archives/xacml/201510/msg00020.html eriK: suggests it is "outside" xacml std domain: https://lists.oasis-open.org/archives/xacml/201510/msg00021.html martin: gives example to clarify: https://lists.oasis-open.org/archives/xacml/201510/msg00022.html hal: considers unrecog attrs as "not a problem": https://lists.oasis-open.org/archives/xacml/201510/msg00023.html martin: response to hal's points: https://lists.oasis-open.org/archives/xacml/201510/msg00024.html ray: consider "closed world assumption": https://lists.oasis-open.org/archives/xacml/201510/msg00025.html martin: response to ray: clarify "example policies": https://lists.oasis-open.org/archives/xacml/201510/msg00026.html ray: suggests alternative approach to addr problem using PAP: https://lists.oasis-open.org/archives/xacml/201510/msg00027.html martin: agrees there are viable alternatives: wants to focus on core reqt: https://lists.oasis-open.org/archives/xacml/201510/msg00028.html 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: https://lists.oasis-open.org/archives/xacml/201510/msg00030.html 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
Thanks, Rich
Rich Levinson | Internet Standards Security
Architect
Mobile: +1 978 5055017
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Oracle is committed to developing practices
and products that help protect the environment