[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes 29 January 2009 TC meeting
Time: 10:00 am EDT Tel: 512-225-3050 Access Code: 65998 Agenda: 10:00 - 10:05 Roll Call Voting Members Erik Rissanen Axiomatics AB Bill Parducci Individual Rich Levinson Oracle Corporation Hal Lockhart Oracle Corporation John Tolbert The Boeing Company Duane DeCouteau Veterans Health Administration David Staggs Veterans Health Administration Approve Minutes of 22 January 2009 TC Meeting http://lists.oasis-open.org/archives/xacml/200901/msg00052.html Approve corrected minutes of 15 January 2009 TC Meeting http://lists.oasis-open.org/archives/xacml/200901/msg00069.html approved both no objection 10:05 - 11:00 Issues Administrivia: Federal Register Notice requiring use of XACML by Federal agencies in certain situations http://lists.oasis-open.org/archives/xacml/200901/msg00062.html Dave: recommends reading email and attachment sent out where xacml reqts for fed govt achieved Dave encourages TC members to consider joining XSPA TC, in particular, to consider participating in HIMSS demo. RedHat, Sun have joined xspa tc and plan to participate in himss demo From above email: "The XSPA profile of XACML will be featured in the OASIS-HITSP Demonstration of TP20 at the HIMSS Showcase in early April. There is still time to participate and we still have room in the booth for more participants." -> Rich: post something on web page US gov't announcement of OASIS security standards milestone http://lists.oasis-open.org/archives/xacml/200901/msg00063.html Prelim before issues: Hal: need to take the time so people understand the issues (because possibly people have not been able to get fully cognizant of the details and things can get thru w/o adequate scrutiny by several members - just a concern, no explicit evidence, but encourages people to speak up if they need more time or discussion on issues) Erik: need to combine efficiency of processing as well Hal: - minutes should reflect discussion and scribes should interrupt if not clear New Issues: Deprecation? http://lists.oasis-open.org/archives/xacml/200901/msg00054.html Hal: oasis has no process for this; other stds orgs follow a mix of procedures; no industry consensus. Hal: key issue is 3.0 features are improvement over 2.0 and that we need to continue 2.0 support. Hal: not ITUT "SHALL" was used rather than "MUST".(desirable to align w them) - Hal will check into it. Bill: need verbage for considering deprecation to give people ready alerts Hal: should avoid new policies w old stuff. Erik: uses "deprecation" more in sense of "legacy features". Erik: would like to have 3.0 full list, and say "2.0, as well" is still mandatory Erik: do we want to refer to errata? Hal: yes, errata should be the basis for 3.0. Hal: 2.0 chapter about conformance chapter Erik: need to go thru 2.0 conformance list and see if makes sense and ensure it all is meaningful. Erik/Hal: 2 models: "3.0 builds on 2.0"; in prev discussions 3.0 impls should be able to fcn as 2.0 impls - Hal is it either/or or is it one or other. Erik: doesn't want full 2.0 impl reqt. Discussion will continue, proposals to be submitted to list, incl item from Bill on other stds orgs practices Attribute validity times http://lists.oasis-open.org/archives/xacml/200901/msg00064.html Rich: spec needs to beef up its pointing this out about what characteristics attrs have when submitted to canonical form. i.e. when context handler translates native form to xacml canonical, the attr may have additional context that is meaningful in terms of the validity of the attr - that context may be of interest to admins and may be possible to be included in admin tools such as PAP when attr defns to be included in policies is established. Hal: need to keep a sense retaining accuracy of subject - in the delegation profile - we talked about metadata (Rich: possibly this statement?: "This represents the fact that the context handler can fill in attributes in the request context. (The details of how the context handler found the administrator attribute depend on the PDP implementation and the available attribute sources in the particular implementation.)" Carried over from previous meetings: Request Context in SAML Profile: which attrs should be returned http://lists.oasis-open.org/archives/xacml/200901/msg00014.html - deal w wording next week. Rich pointed out, off list, that adding phrase, "supplied by the PEP" to "A conforming PDP MAY omit those XACML Attributes, supplied by the PEP, ..." would help disambiguate the possibilities of what attrs are being referred to that could be omitted, since there were none left that could be omitted in previous sentence. Hierarchical profile http://lists.oasis-open.org/archives/xacml/200901/msg00033.html Rich: no change - still has action to post to list Multiple Decision Request Proposal Consolidation and refs to emails for current state of proposal: http://lists.oasis-open.org/archives/xacml/200901/msg00055.html Most recent proposal and objection on correlation problem: http://lists.oasis-open.org/archives/xacml/200901/msg00058.html http://lists.oasis-open.org/archives/xacml/200901/msg00060.html Hal: posted scheme and Erik said scheme wouldn't work; 2 issues: 1. correlation; use include in resp attr val in response if inputs not unambiguous it is responsiblity of req builder to put in whatever they need. 2. how do we express what items to create virtual req context for a single decision within multi-request a. use xml refs b. use attrs for matching Hal: just using xml:id more straight forward Erik: correlationId - get multiple results Hal: xpath alternative don't need the ref Erik: can send in pile of attrs where each contains xml Erik: should do xml:id for inputs; for outputs use incl in resp problem in setting up request is doing type matching Erik: 2 correlations: input and output xml:id ok on input but would break on output, that is ok. Hal: we have rough consensus: Erik has some thoughts in mind to put something together RBAC Profile Darran volunteered to create a proposal to address use cases he believes may be pertinent to this 3.0 Profile. Darran will try for next week to have something to consider. XSPA (Comment List) Hal suggested that there is a better source for HL7 reference. Hal: Refs: constructs ref'ing HL7 - is there more authoritative ref than going to interop lists. David: what comments need to be addressed: Hal: only officially comments to public review list and for those need to show disposition of each, w possible short follow up review.