OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Groups - xacml-3.0-obligation-v1-wd-03.zip uploaded

This is a major rewrite of the obligation families profile.

Summary of changes:

- Use <xs:any> for extension rather than xsi:type
- Define a response formet for each family. Insertion in the core response
remains to be done.
- Include the "Chronicle" attribute proposed by David Chadwick back in May
2007. Though I am calling it "Timing"
- Due to the Timing attribute include some text defining properties about
obligation enforcement under failure.

Detailed discussion of changes follows.

I changed the way the schema was set up. I used to defined an abstract
ObligationFamily type which the concrete obligation family types extended.
I dropped this inheritance of schema types because it leads to the use of
the xsi:type attribute which as Hal pointed out during the next to the
previous TC call, is annoying in XML signatures since you have to define an
inclusive namespace in the signature to make sure the xmlns:xsi is not
dropped during exclusive c14n.

Instead I made it like this:

<xs:element name="ObligationFamiliesDecl"
    <xs:complexType name="ObligationFamiliesDeclType">
    <xs:choice minOccurs="0" maxOccurs="unbounded">
    		<xs:element ref="obl:ExclusiveDecl"/>
    		<xs:element ref="obl:SequentialDecl"/>
    		<xs:any namespace="##other" processContents="lax"/>

The xs:any allows for extension of families by us or by users. I chose this
approach by imitation of the WS-Policy schema. (I hope I got it right.)
This approach means that a family is identified by its element name
(including the namespace of the element). This is not problematic in
signatures. This also means that there is no need for a URI for identifying
the families since the element name is enough.

I have defined a response format for the two families which are defined,
but I have not defined yet how these XML fragments are inserted in the
request context since this change may affect the core schema.

There are two ways I can think of. One is to change the 3.0 core schema so
it allows obligation families in the response. This is my preference. It
would like this:

  <Result Decision="Permit">

Another option is that the PDP creates a special obligation, which contains
the families. The second option is a bit more verbose, but does not require
a special construct in the core schema.

  <Result Decision="Permit">
       <Obligation ObligationId="urn:oasis:...:obligation-families">
        ... Other obligations here ...

I have added the "Chronicle" attribute proposed by David Chadwich back in
May 2007. This attribute tells whether the PEP should enforce the
obligation before, during or after access control enforcement. As we have
discussed previously, I put it in the obligation families profile rather
than the core schema. However, this way it is less granular than the
original proposal by David, in which individual obligation instances in
policies could be marked with the Chronicle attribute.

I think this is better since I would like to have the obligation families
as the method of defining obligation metadata because the obligation family
concept is used to isolate mutually inconsistent meta data types from each
other. Also, the families concept contains an extension point so additional
meta data can be defined in the future.

If we put the Chronicle attribute in the core schema obligation we get two

1. If we want to add some other meta data attribute in the future, we have
to change the core schema again.

2. As we keep adding more and more meta data attributes to the core, the
meta data types will eventually start to conflict with each other and
various combinations of metadata explode and defininig the semantics will
be difficult and prone to inconsistensies and security issues.

We already have an example of such a conflict: the chronicle metadata would
conflict with the Sequantial obligation family. The sequential obligation
family is used to say in what order obligations are enforced. Here is a
simple example of how this can conflict with the Chronicle attribute:

Two obligations: A and B

Chronicle says on A: before access control enforcement
Chronicle says on B: after access control enforcement

Sequential family says: B has to be enforced before A

So, in order to avoid issues like these, I propose that all obligation
metadata is put in the families where applicable. The metadata available
within each family is limited in scope and can be kept consistent so it is
not possible to define conflicting metadata, or at least the scope of
conflicts can be kept to a minimum so the conflict resolution can be

BTW, If someone wants to do what David proposes, it can be done already by
making the Chronicle an <AttributeAssignment> within the obligation like

<Obligation OligationId="http://foo/bar";>
  <AttributeAssignement AttributeId="http://foo/Chronicle";>
    <AttributeValue DataType="...#string">Before</AttributeAssignment>
  ... Any other AttributeAssignments ...

The PEP can extract the Chronicle value from there before obligation
enforcement. This of course could lead to conflicts with other metadata,
but there isn't much we can do about this. At least the "official" metadata
schemes from the TC will be consistent.

Finally, I changed the name of the attribute to "Timing" rather than
Chronicle and I made the values "BeforeAccess", "WithAccess",
"AfterAccess". I though these names are more easily understood. Let me know
if you disagree.

Because I have added the timing attribute to the obligation families, I was
concerned about whether it is possible to implement such guarantees. I
wrote up a simple analysis of it. Please review that so I didn't make a
mistake. And we might consider moving that to the core spec instead of this
profile since some of it applies to obligations in general.

I added another piece of metadata to the sequential family which I thought
would be useful: a mode of failure for enforcement of the sequence
obligations. Previously it was undefined what should happen if some of the
obligations fail. There are noew three modes: Atomic, FailFast and

I have not written the examples yet. I would like to reach consensus on
these new major changes in the TC before I put effort into detailed
writeups of examples.

Personally I feel like this is pretty much the obligation family profile
completed from a technical point of view. It just needs the examples and
some editorial work to make it look good. Oh, and of course fixing any
errors. :-)

 -- Erik Rissanen

The document named xacml-3.0-obligation-v1-wd-03.zip has been submitted by
Erik Rissanen to the OASIS eXtensible Access Control Markup Language
(XACML) TC document repository.

Document Description:

View Document Details:

Download Document:  

PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]