[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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]