Re: [xacml] Groups - xacml-3.0-obligation-v1-wd-03.zip uploaded

[Erik Rissanen <erik@axiomatics.com>]

All,

I just realized that the second option regarding the return value (embed 
the families in an attribute assignment in an obligation) makes this 
profile easily available even on XACML 2.0. So perhaps we could do the 
"cleaner" choice for 3.0 and also support 2.0 using the second choice.

Regards,
Erik

erik@axiomatics.com wrote:
> 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"
> type="obl:ObligationFamiliesDeclType"/>
>     <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"/>
>     </xs:choice>
> </xs:complexType>
>
> 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:
>
> <Response>
>   <Result Decision="Permit">
>     <Status>...</>
>     <Obligations>...</>
>     <ObligationFamilies>
>       <Exclusive>
>         ...
>       </Exclusive>
>       <Sequential>
>         ...
>       </Sequential>
>     </ObligationFamilies>
>   </Result>
> </Response>
>
> 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.
>
> <Response>
>   <Result Decision="Permit">
>     <Status>...</>
>     <Obligations>
>        <Obligation ObligationId="urn:oasis:...:obligation-families">
>          <AttributeAssignment>
>            <AttributeValue>
>              <ObligationFamilies>
>                <Exclusive>
>                  ...
>                </Exclusive>
>                <Sequential>
>                  ...
>                </Sequential>
>              </ObligationFamilies>
>            </AttributeValue>
>          </AttributeAssignment>
>        </Obligation>
>         ... Other obligations here ...
>     </Obligations>
>   </Result>
> </Response>
>
>
> 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
> problems:
>
> 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
> comprehended.
>
> BTW, If someone wants to do what David proposes, it can be done already by
> making the Chronicle an <AttributeAssignment> within the obligation like
> this:
>
> <Obligation OligationId="http://foo/bar";>
>   <AttributeAssignement AttributeId="http://foo/Chronicle";>
>     <AttributeValue DataType="...#string">Before</AttributeAssignment>
>   </AttributeAssignment>
>   ... Any other AttributeAssignments ...
> <Obligation>
>
> 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
> ContinueOnFailure.
>
> 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:
> http://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=27230
>
> Download Document:  
> http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/27230/xacml-3.0-obligation-v1-wd-03.zip
>
>
> 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
>