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