Re: [Use Case] Subcommittee Meeting Notes

[Michiharu Kudoh <KUDO@jp.ibm.com>]

I could not make a call for today's use cases WG because I was on the road.
I would like to make some comments on the use cases I submitted.

As for sending XML document to PDP for transformation, I agree to that it
is
essentially the PEP's responsibility. I mean that this is just an optional
case, not
a usual case, as I added a word of "optionally"in the sentence.

My intention behind this is the following:
If PEP and PDP are coupled tightly and there is little concern about trust
relationship between them, it would make sense to send the target resource
to PDP in order to have PDP make a data-dependent (dynamic) decision using
values of the target resource. Since PEP can trust PDP's decision and the
result of the transformation, an application (PEP) becomes much simpler.
However, if we define PEP as the agent that is only allowed to handle the
target resource, the above optional case even may not be seen as
communication between PEP and PDP, but just internal protocol in the PEP.

When you assume that the target resource is represented in XML, it would
become much easier to map between application-domain and PDP's domain,
because both domain can be XML. If you let PEP know the semantics of each
actions, e.g. read, write, and several protocol parameters between
PDP and PEP, the PEP's job could be reduced to less things such as
physically
resource retrieving and/or updating. I hope this will stimulate the
discussion.

regards,
Michiharu Kudo
Internet Technology              TEL +81-46-215-4642
Tokyo Research Laboratory    FAX +81-46-273-7428
IBM Japan Ltd.                      Internet: kudo@jp.ibm.com


From: Ken Yagen <kyagen@crosslogix.com> on 2001/09/06 11:20

Please respond to Ken Yagen <kyagen@crosslogix.com>

To:   "XACML (E-mail)" <xacml@lists.oasis-open.org>
cc:
Subject:  [Use Case] Subcommittee Meeting Notes





Use Case Subcommittee Meeting Notes
Wednesday, September 05, 2001 9AM PDT

Attendees
Ken Yagen
Carlisle Adams
Gil Pilz
Bill Parducci
Suresh Damodaran
Hal Lockhart

Agenda
Review Use Cases
Discuss Commonalties
First cut at what is in or out of scope

Action Items
Hal to clarify discretionary vs. non-discretionary access control
Bill to create a single document from the submitted use cases
Carlisle to prepare and present a summary of the use cases, what
commonalities we found and a list of topics to discuss
Additional use cases submitted between now and the F2F should be considered
at the F2F. Gil(WebDAV) and Ken(Policy Analysis) both mentioned they are
working on some.

Static Access Control on XML Resources
There was some discussion about why the XML document is being sent to the
PDP for transformation. It was agreed that this should probably be the
responsibility of the PEP. It would query the PDP for what portions of the
document the user is allowed to see and then enforce that by doing the
transformation. The PEP would also be responsible for mapping the objects
as they are known in the application domain to the resource syntax that the
PDP is familiar with. It was also pointed out that sending the XML document
to the PDP makes it more difficult to keep the document secure and
protected.

Clinical Records
Major point of this use case is that there are multiple policies (patient,
physician, hospital, etc) that pertain to the document and must be
satisfied by the PDP. Carlisle's workflow use case also focuses on this.
This was referred to as a policy for conflict resolution although there was
some discussion surrounding the use of that exact phrase.

Some questions were raised about the key point that the document is not
modifiable after signed. This may be an issue out of scope of XACML. The
Breaking Glass variant was equated to a special credential. If the
authentication mechanism were tied to the access policy (like a big "OR").
Auditing also was raised by this use case and several others. Is auditing
in scope? What about turning it on/off based on the policy. Someone
mentioned that auditing should be a separate policy with different
criteria, but the decision point is the same.

EbXML Registry
From this case, the issue of order within the policy applied was raised.
State is an input to the PDP because the order that actions happen is
important in whether or not they are allowed. This is analogous to a common
question in workflow. Some thought this is more of an application issue,
but the boundaries between authorization logic and application logic are
often blurred.

Online Application Server
The key point here was input attributes that are not subject-related. The
second one also brings up provisioning and whether it is in scope. This was
clarified as an issue relating to a protocol for passing policy to the PDP.
The ebXML use case also spoke about submitting policy. The last use case
asks for XACML to increase the expressiveness of Authorization Decision
requests and responses. This is something SAML is looking to XACML to
provide.

Side discussion arose on discretionary vs. non-discretionary access
control. Discretionary access control refers to objects that have owners
that control access to them (ie filesystem access control). They are often
simpler policies but the reason for that wasn't made clear. This idea
seemed to exist in some of the use cases (ebXML Submitting Organizations,
Groupware authors). Hal agreed to clarify this issue some and perhaps write
a use case for it.

Workflow
Key point is that there may be many different writers of policy. This is
similar to the point raised in the Clinical use case.