[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Response to action item #13
>13.[Michiharu]: provide the patent # for the Obligations patent that has
issued
>in the U.S.
Patent number is 6,647,388. Refer to the following URL.
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,647,388.WKU.&OS=PN/6,647,388
&RS=PN/6,647,388
Best,
Michiharu
Bill Parducci
<bill.parducci@ov
erxeer.com> To
xacml <xacml@lists.oasis-open.org>
2004/05/04 05:54 cc
Subject
[xacml] Minutes for New Orleans F2F
below are the minutes for the face to face in new orleans. as usual the
written
summary can't do justice to the thought process (much less the passion by
which
the ideas were presented ;o), but the combined efforts of anne and i should
give
those of you who were unable to attend a good idea of where we stand on the
remaining v2 issues.
b
=======================================================
= Meeting Minutes for April 28, 2004 F2F, New Orleans =
=======================================================
Attending:
(v) Mike McIntosh, IBM
(v) Michiharu Kudoh, IBM
(v) Ed Coyne, Veterans Health Administration
(v) Hal Lockhart, BEA
(p) Don Choi, US Defense Information Systems Agency
(v) Simon Godik, Overxeer
(v) Polar Humenn, self
(v) Bill Parducci, Overxeer
(v) Anne Anderson, Sun
(v) Daniel Engovatov, BEA
(v) Tim Moses, Entrust
(o) Thomas Bui, Boeing
ACTION ITEMS:
1. [Simon]: provide Tim with reference for the canonical time format.
2. [TC]: supply Bill with list of things to include in the
changes/backwards
compatibility section.
3. [Anne]: produce revised Hierarchical Resources proposal. This is the
only
item somewhat committed for 2.0 that has not yet been
resolved.
4. [Polar]: produce a working draft with absolutely no Haskell of a
proposed
solution for delegation.
5. [Anne]: MAY produce a non-normative introductory document that
duplicates
much of what is in Sections 2-4.
6. [Daniel]: produce well-written, clear proposal for Hierarchical
Resources.
7. [Michiharu]: describe how resource-ids are generated from RequestContext
is
generated, in case of XML documents.
8. [Anne]: get Tim her comments, proposed corrections on Functional
Requirements
section.
9. [Tim]: based on Anne's notes and existing Base Policies section,
describe the
three levels of PEP conformance.
10.[Anne]: SAML Attribute Profile for XACML draft.
11.[Frank]: provide proposal for environment attributes related to time
intervals.
12.[Michiharu,Mike]: find out what the licensing requirements are for
Obligations. May be in the form of a contact person and telephone number.
We
know they are RAND. We need to know what the royalties will be.
13.[Michiharu]: provide the patent # for the Obligations patent that has
issued
in the U.S.
14.[Tim]: provide Anne with leaf names of the two schema URLs.
15.[Anne]: ask OASIS webmaster for and provide Tim with 2 fixed URLs that
terminate in the two leaf schema names.
==========
Meeting began 9:00am, quorum reached.
Agenda review.
==========
SAML and XACML Attribute Convergence:
[Anne] presented draft SAML profile for XACML to cover requests between PEP
<-->
PDP <--> PRP
[Tim] discussed current draft from SSTC on the topic.
The two current options for attribute type-casting: in-band (instance) and
meta
data exchange, the latter a current mechanism supported by SAML. The
general
consensus is that the TC work to provide a profile for each. SSTC has a
document
in progress that Anne and Tim will work with the appropriate SSTC members
to
derive a solution that is mutually acceptable to both TCs.
==========
XACML constraints on PEP:
Upon discussion, the TC arrived at three conforming PEP models: Base,
Deny-Biased, Permit-Biased.
Base conformance:
* Permit access if Response is "Permit". If Obligations are presented,
then
Permit only if understand, can discharge, and will discharge any
Obligations
returned with the response.
* Deny access if Response is "Deny". If Obligations are presented, then
Deny
only if understand, can discharge, and will discharge any Obligations
returned
with the response.
* Not Applicable Response: access behavior is undefined.
* Indeterminate Response: access behavior is undefined.
Deny-biased conformance:
* Permit access ONLY if Response is "Permit". If Obligations are
presented,
then Permit only if understand, can discharge, and will discharge any
Obligations returned with the response.
All other Responses result in the denial of access to Subject.
Note: other actions--consultation of additional PDPs,
reformulation/resubmission
of query, etc.--are not prohibited.
Permit-biased conformance:
* Deny access ONLY if Response is "Deny". If Obligations are presented,
then
Deny only if understand, can discharge, and will discharge any Obligations
returned with the response.
All other Responses result in the permission of access to Subject.
Note: other actions--consultation of additional PDPs,
reformulation/resubmission
of query, etc.--are not prohibited.
==========
Base Policy discussion:
The concept of a Base Policy was discussed. The following definition
emerged:
Section 7.2: For purposes of this specification, in relation to a
particular
Request, a given PDP is defined as a Policy Combining Algorithm and a set
of
policies and/or policy sets. The PDP SHALL return a Response as if it
evaluates
a single policy set consisting of this Policy Combining Algorithm and the
set of
policies and policy sets.
TBD: align with Section 2.10
We would move the remaining existing text in 7.2 that describes various
"MAY"
models - collecting applicable policies in response to the contents of the
Request into a PolicySet template that has a pre-defined
PolicyCombingAlgorithm,
etc. - into Sections 2-4.
Note that this might affect Conformance Tests.
==========
Are XACML policies portable?
[Polar] Can't expect any particular attributes from the request. If could
depend on getting subject-id, resource-id, action-id, and the standard
environment attributes, then could write a policy that would always apply.
But
this could be done with a profile document.
==========
Hierarchical Resources:
(see also “Alternate Hierarchical Resource Proposal” below)
The policy considerations necessary to protect hierarchical resources was
discussed. Anne began the discussion with a review of her proposed
solution.
After significant discussion the matter, a number of issues remain:
* Support normative, but not mandatory?
* Do we need a new DataType for "xpath-expression" (see possible uses
below)?
Requires DataType to be evaluated to see if it is valid. Probably
sufficient to
say "#string, limited to 'must be an XPath expression'". There is no
currently
defined data type for an "XPath" expression, so we would have to define
one.
* What information is supplied in the Request Context in order to request
access
to a hierarchical resource?
PROPOSAL:
<Resource>
<Attribute AttributeId="...:xpath" DataType="...:xpath-expression???">
<AttributeValue DataType="...:xpath-expression???">
[expression]
</AttributeValue>
</Attribute>
<ResourceContent>
[an XML document representing the hierarchical resource]
</ResourceContent>
</Resource>
* Do we retain existing XACML 1.1 support for "scope"? [Daniel] wants it.
* Does the PDP iterate through each node in the requested node set,
returning
one <Result> element in the <Response> for each such node?
PROPOSAL: Yes, or equivalent to. Each <Result> element includes the
ResourceId
of the node to which it applies (what DataType?? xpath-expression that
evaluates
to exactly that node?) and <Decision> (Permit, Deny, Indeterminate,
NotApplicable) for that node.
* Does PDP return <Result> elements only for leaf nodes? Probably yes.
* Is there an easy way to optimize, so that minimal re-evaluation of XPath
expressions is done?
* Is there a standard way to create an XML document from a hierarchy that
is not
an XML document to begin with?
USE CASE: Unix File System
PROPOSAL: Create document in which XML tags are the values of the
IDENTITIES of
the nodes in the hierarchy.
Directory subtree:
//aaa/b/c/d
//aaa/e
//aaa/f/g/h
//aaa/f/i/j
becomes:
<aaa>
<b>
<c>
<d/>
</c>
</b>
<e/>
<f>
<g>
<h/>
</g>
<i>
<j/>
</i>
</f>
</aaa>
* Are there hierarchies we want to support that do not have identifiers for
each
node that can be used as tags in this way?
* Do we need to be able to attach attributes such as "owner" to nodes in
the
hierarchy.
* Is there a simpler syntax to use for specifying paths and subtrees in the
hierarchy than XPath [Daniel Action Item].
* Do we need any hierarchy-specific functions other than the existing
xpath-node-match? Probably not.
===========
Veteran’s Health Administration Presentation:
[Ed] presented CCOW Health care Implementation.
* user-centered technique for integrating applications
* HL7 context management
* Context manager: sentillion
Want to have multiple applications view same patient context information.
Change patient being viewed in one, and it changes in others. Applications
come
from different vendors, have different interfaces, etc.
Want to use Tivoli for the transport, communication between entities, which
they
hope will be enabled to use XML.
Planning to use XACML and XACML Profile for RBAC. Tim pointed out that
XACML
RBAC alone does not support Separation of Duty. XACML can handle if, for
example, once Action A is performed by Subject A, the application writes
Subject
A into the document as the entity that performed Action A. Then XACML can
be
used to say Subject for Action B must not match the identity of the entity
that
performed Action A by making an AttributeSelector into that field of the
document.
===========
Presentation
Obligations in Rules:
Michiharu presented a simple Use Case to illustrate the use of Obligations
in Rules
1st Rule: Simon can eat weeds on weekdays.
2nd Rule: Simon can eat weeds on weekends.
1st Rule: Simon can eat weeds on weekdays,
but Obligation=charge $5
2nd Rule: Simon can eat weeds on weekends,
but Obligation=charge $10
In XACML 1.0 have to create two Policies to achieve same effect.
[Bill] To handle "conflicting obligations", just define one big Obligation
($5
on weekdays, $50 on holidays) and let the PEP interpret it. Obligations are
opaque to the PDP so there doesn’t seem to be any value to the XACML
specification to add this overhead to the policy decision device.
[Polar] If we add Obligations to Rules, we have no difference between
Policy and
Rule.
Tentative conclusion: drop this work item for 2.0. [Michiharu] is
comfortable
with this.
=======================================================
= Meeting Minutes for April 29, 2004 F2F, New Orleans =
=======================================================
Attending:
(v) Mike McIntosh, IBM
(v) Michiharu Kudoh, IBM
(v) Ed Coyne, Veterans Health Administration
(v) Hal Lockhart, BEA
(p) Don Choi, US Defense Information Systems Agency
(v) Simon Godik, Overxeer
(v) Polar Humenn, self
(v) Bill Parducci, Overxeer
(v) Anne Anderson, Sun
(v) Daniel Engovatov, BEA
(v) Tim Moses, Entrust
(v) Frank Siebenlist
==========
Meeting began 9:00am, quorum reached.
Agenda review.
==========
Distributed Administration:
[Frank] presented his proposal for distributed administration. After
several
hours of discussion there weren’t any immediate objections to pursuing the
general model further.
[Hal] concerned that Issuer is only constrained by Subject, however didn’t
feel
that this will necessarily be a problem in practical terms
[Daniel] concerned that revocation is not addressed
[Polar] concerned that they model may “get away” from the intended
implementation.
[Tim] is concerned that the complexity of a fully generalized model may
take a
long time to resolve and that we may wish to add some constraints that will
limit this.
[Hal] Since this will not make it into the 2.0 specification that we
shouldn’t
consider limitations yet. Also, called for examples of cases that are
either not
covered or are more fully explanatory.
Submissions should be presented as Working Drafts (vs. simple e-mail
threads).
==========
WI #68 ? Attribute assertion:
After significant discussion, the conversation distilled to [Frank] asking
for a
mechanism that allows a Subject to query a PDP for conditions by which
access is
granted to a resource in a time interval.
It was the general consensus of the TC that XACML is not designed to behave
in
this fashion. Hal proposed that a time-interval attribute mechanism be
defined
as a potential mitigation alternative. Frank agreed that this would be of
value.
Action Item: [Frank] will formulate a specific proposal to address this.
==========
[Polar] The current spec mentions the PDP as being the source for current
time
and that this should be the Context Handler. It is generally agreed this is
the
correct and that the retrieval of time and date information is done by the
Context Handler and not by the PDP.
==========
[Simon] Proposed that all time values referenced in XACML must be in the
Canonical format defined by XML Schema.
==========
WI 52 ? Section on differences between XACML v1.1 and v2.0
[Bill] requested input on format and granularity of content. Areas of
interest
include:
* Backwards compatibility
* Loss of “Any”
* Semantics of missing components have changed
* Variable Definition & Reference Combining Parameters
* Expression substitution groups
* Look in SAML diff doc as a template
* Version in Policy
==========
WI 65 ? Addition layer of aggregation to XACML
[Daniel] taken care of by work underway with SAML. Work Item closed.
==========
Alternate Hierarchical Resource Proposal
[Daniel] revisited Hierarchical resource topic since he is concerned that
only a
single ResourceId represents multiple [child] resources in a single
request.
[Daniel] proposed two independent mechanisms.
1) A shortcut for submitting multiple Request Contexts in one to a
Context
Handler. The Context Handler is responsible for decomposing those into
separate RequestContexts, each about one resource in the original RC.
The PDP
will make its decisions based on one decomposed <resource> at a time, and
will
never be able to see more than one <resource> at a time.
Following syntax is from [Anne]. [Daniel] presented a somewhat
different
syntax for this that would require the PDP itself to decompose the multiple
requests.
<resources>
<resource>
resource1
</resource>
<resource>
resource2
</resource>
[...]
</resources>
Before the PDP sees this RequestContext, it is modified by the Context
Handler into a sequence of RequestContexts, which are presented to the
PDP one
at a time. Each such RequestContext contains one of the <resource>
elements
from the original. The <Result> from each decision is included in the
<Response> to the original many-in-one RequestContext.
This mechanism MAY be used to request multiple elements in a hierarchy,
but
it is not limited to that.
The XPath approach allows one statement for expressing the set of
resources
for which individual decisions are requested. It is limited to
hierarchies, and
works best with XML resources.
2) Orthogonally, [Daniel] has proposed a mechanism for supplying the
ancestors/parents of a resource, by supplying an Attribute containing a bag
of
the resource's ancestors/parents. It does not require any particular
syntax for
expressing the ancestors, and the ancestors do not even need to be in the
same
tree. It loses all information about the chaining of the ancestors. But
is
this information actually useful?
The XPath approach also proposed a mechanism for supplying the position
of a
resource in a hierarchy, by supplying a description of the entire resource
as an
XML document.
With Daniel's proposal, a policy can contain predicates like:
<and>
</a/b/c is in resource-ancestors>
<action-id = read>
</and>
These two mechanisms MAY be combined to produce an alternative way to ask
some
types of questions about hierarchical resources.
<resources>
<resource>
resource-id=/a/b/c/d
resource-ancestors={/a/b/c, /a/b, /a}
</resource>
<resource> <--this resource is not part of the same
hierarchy, but is an example showing
how the proposal is not limited to
describing hierarchical resources
resource2
resource-ancestors={lzq, px}
</resource>
<resource>
resource-id=/a/b/c
resource-ancestors={/a/b, /a}
</resource>
...
</resources>
There is NO requirement that there be any connection between the individual
<resource> elements that are supplied. The PDP will make its decision
based on
only a single <resource> element at a time, and it will not even see the
others.
=============
SAML Attribute Assertions
[Hal] Can a SAML Attribute Assertion refer to anything other than a Subject
in
an XACML RequestContext?
How a SAML Attribute Assertion where the SAML Subject is actually an XACML
Resource would work. How does the Context Handler know whether to plug the
SAML
Attribute value into the Subjects, Resource, Action, or Environment section
of
the RequestContext?
[Anne] If the PDP passes a ResourceAttributeDescriptor to an
AttributeFinderModule, the AttributeFinderModule can use the existing
"resource-id" Attribute value to request a SAML Attribute that has that id
as
its SAML Subject. "Subject" and "Resource" are relative to the context in
which
they are used. A SAML Subject is simply the subject entity of the
attribute
value binding. It does not imply anything about the role that entity plays
in
other contexts, where it might be a resource that is bound to a security
label,
for example.
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]