OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
Expand all | Collapse all

Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

  • 1.  Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 10-22-2013 06:18
    Submitter's message This is the initial draft for the Related and Nested Entities Profile - my response to the Attributes of Relations email thread. I changed from Embedded to Nested in the title because it better suggests the idea that entities can be embedded in other entities to any depth. A nested entity is what I have previously called a compound attribute. As well as the ForAny and ForAll expressions that I have discussed on the mailing list I have defined a Select _expression_ as a convenience to policy writers who like to think in SQL terms. The examples go beyond simply addressing the Attributes of Relations concerns. -- Dr. Steven Legg Document Name : XACML v3.0 Related and Nested Entities Profile Version 1.0 Description It is not unusual for access control policy to be dependent on attributes that are not naturally properties of the access subject or resource, but rather are properties of entities that are related to the access subject or resource. This profile defines the means to reference such attributes from within XACML policies for processing by a policy decision point. Download Latest Revision Public Download Link Submitter : Dr. Steven Legg Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2013-10-21 23:17:29


  • 2.  RE: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 10-22-2013 23:44
    Hello Steven,   Thanks for assembling the draft profile.  You have put a great deal of work into this.   Given that “domain” has fairly standard meaning in IT, would it be possible to use the term “scope” instead?  I think it would work in this context, and prevent unnecessary confusion.  “Realm” also might be a less-used and less confusing term, but I think “scope” fits best.   In the examples in section 5.2, I see “relationship-kind”, which seems to be quite a bit like urn:oasis:names:tc:xacml:3.0:ipc:subject:subject-to-organization-relationship. There is also “start-date”, which is similar to urn:oasis:names:tc:xacml:3.0:ipc:resource:effective-date   For the sake of consistency, could we use the IPC style attributes, even in the examples, so  we can keep those aligned?   The examples in 5.3.1 regarding an “approved-export” table actually hint at the existence of behind-the-scenes attribute flattening, since in order to build such a table, the list has to be compiled from interpretation of regulations, exceptions, and individual licenses.  Is the intent to demonstrate a capability to import complex tables associated with regulations (such as the US Commerce Control List), and make the table content available to policy authors?    Thanks again for the contribution,   John     From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Steven Legg Sent: Monday, October 21, 2013 11:18 PM To: xacml@lists.oasis-open.org Subject: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded   Submitter's message This is the initial draft for the Related and Nested Entities Profile - my response to the "Attributes of Relations" email thread. I changed from "Embedded" to "Nested" in the title because it better suggests the idea that entities can be embedded in other entities to any depth. A nested entity is what I have previously called a compound attribute. As well as the ForAny and ForAll expressions that I have discussed on the mailing list I have defined a Select _expression_ as a convenience to policy writers who like to think in SQL terms. The examples go beyond simply addressing the "Attributes of Relations" concerns. -- Dr. Steven Legg Document Name : XACML v3.0 Related and Nested Entities Profile Version 1.0 Description It is not unusual for access control policy to be dependent on attributes that are not naturally properties of the access subject or resource, but rather are properties of entities that are related to the access subject or resource. This profile defines the means to reference such attributes from within XACML policies for processing by a policy decision point. Download Latest Revision Public Download Link Submitter : Dr. Steven Legg Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2013-10-21 23:17:29  


  • 3.  Re: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 10-23-2013 03:26
    Hi John, On 23/10/2013 10:44 AM, Tolbert, John W wrote: Hello Steven, Thanks for assembling the draft profile. You have put a great deal of work into this. Thanks for reading it and providing feedback. Given that “domain” has fairly standard meaning in IT, would it be possible to use the term “scope” instead? I think it would work in this context, and prevent unnecessary confusion. “Realm” also might be a less-used and less confusing term, but I think “scope” fits best. Domain of discourse is what it's called in the terminology of existential and universal quantification, which I shortened to "domain". Would "domain of discourse" or "quantifier domain" work for you ? In the examples in section 5.2, I see “relationship-kind”, which seems to be quite a bit like urn:oasis:names:tc:xacml:3.0:ipc:subject:subject-to-organization-relationship. Firstly, I'd like to make sure you are clear that the profile doesn't standardize any attributes. The attributes in the examples are in the urn:example namespace and it would be completely bogus to use these attributes in a real XACML deployment. If you didn't pick up on that then I need to say something about it the terminology section. The reasons why I didn't use subject-to-organization-relationship are that it's a flattened attribute in the context of the IPC profile, and it's defined to be a subject attribute but I would be using it in a relationship entity (admittedly that's a nested entity in a subject entity, but the example could just as well have used related entities). If I had used it, it would not be in a way that is conformant with the IPC profile, so it would have seemed more a case of "abuse" than "use". From the aesthetic standpoint, the attribute URI is quite long and its values are URIs so it would have added clutter and ugly line-wrapping to the examples. There is also “start-date”, which is similar to urn:oasis:names:tc:xacml:3.0:ipc:resource:effective-date The reasons for not using effective-date are similar: - EC-US also defines an effective-date attribute. Which one would I favour ? - Both effective-date attributes are defined as resource attributes and I am not using start-date anywhere near a resource entity. - Both effective-date attributes are flattened (from entities that aren't anything to do with the relationship between a subject and an organization). For the sake of consistency, could we use the IPC style attributes, even in the examples, so we can keep those aligned? I could make the URIs the same, but they would still be semantically different attributes. I would have thought that would be counter-productive to both profiles. The examples in 5.3.1 regarding an “approved-export” table actually hint at the existence of behind-the-scenes attribute flattening, since in order to build such a table, the list has to be compiled from interpretation of regulations, exceptions, and individual licenses. Is the intent to demonstrate a capability to import complex tables associated with regulations (such as the US Commerce Control List), and make the table content available to policy authors? The main motivation was to demonstrate a way to do the dynamic template reduction that Jean-Paul was talking about. Export control was his use case. In general, I expect a table to be a sufficiently faithful representation of any external input. Entities can be nested to any depth and have any cardinality so there is no impediment to representing complex real-world structures. The example is obviously a simplification of reality, but if it gives the impression that flattening is going on then I need to work on the prose. Regards, Steven Thanks again for the contribution, John *From:*xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] *On Behalf Of *Steven Legg *Sent:* Monday, October 21, 2013 11:18 PM *To:* xacml@lists.oasis-open.org *Subject:* [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded /Submitter's message/ This is the initial draft for the Related and Nested Entities Profile - my response to the "Attributes of Relations" email thread. I changed from "Embedded" to "Nested" in the title because it better suggests the idea that entities can be embedded in other entities to any depth. A nested entity is what I have previously called a compound attribute. As well as the ForAny and ForAll expressions that I have discussed on the mailing list I have defined a Select expression as a convenience to policy writers who like to think in SQL terms. The examples go beyond simply addressing the "Attributes of Relations" concerns. -- Dr. Steven Legg *Document Name*: XACML v3.0 Related and Nested Entities Profile Version 1.0 < https://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=51130 > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- *Description* It is not unusual for access control policy to be dependent on attributes that are not naturally properties of the access subject or resource, but rather are properties of entities that are related to the access subject or resource. This profile defines the means to reference such attributes from within XACML policies for processing by a policy decision point. Download Latest Revision < https://www.oasis-open.org/apps/org/workgroup/xacml/download.php/51130/latest/xacml-3.0-related-entities-v1.0-wd01.doc > Public Download Link < https://www.oasis-open.org/committees/document.php?document_id=51130&wg_abbrev=xacml > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- *Submitter*: Dr. Steven Legg *Group*: OASIS eXtensible Access Control Markup Language (XACML) TC *Folder*: Specifications and Working Drafts *Date submitted*: 2013-10-21 23:17:29


  • 4.  Re: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 10-31-2013 05:08
    On 23/10/2013 2:26 PM, Steven Legg wrote: Given that “domain” has fairly standard meaning in IT, would it be possible to use the term “scope” instead? I think it would work in this context, and prevent unnecessary confusion. “Realm” also might be a less-used and less confusing term, but I think “scope” fits best. Domain of discourse is what it's called in the terminology of existential and universal quantification, which I shortened to "domain". Would "domain of discourse" or "quantifier domain" work for you ? How about "range" (of the quantified variable) ? Regards, Steven


  • 5.  RE: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 10-31-2013 17:14
    I would prefer quantifier-range first, or quantifier-domain second. Thanks


  • 6.  RE: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 10-30-2013 05:00
    Thanks Steven for the well-written document.   I had some minor comments and some issues to discuss:   S2.1P4: "Evaluation of the _expression_ MAY terminate at the first value from the domain for which the iterant _expression_ evaluates to “true”." I think the meaning of "first" here is ambiguous and might be misleading as according to the spec, bags are unordered. I suggest either editing this to remove the word “first” or adding a sentence to emphasize that the implementation must not assume any particular order for processing of bags, and first means the first entity encountered regardless of the order of processing.   S2.1P4 and S2.2:  I suggest that, since there is no formal definition of these quantifiers, we explicitly clarify the value of ForAny and ForAll for an empty Domain.   There are also two issues for discussion:   -         As someone said before on the list, in case of large data sets, there should be a mechanism to notify the PEP or PAP to include in the request only part of the related entities that are consequential in the PDP’s decision. For example, if the policy is to allow access “if the resource owner has a friend who is over 18”, this will require including all of the resource owner’s friends in the request. Finding some way to communicate what is sufficient to be included in the request is at least worth mentioning as an implementation issue. -         There should be some sort of discussion about the completeness of the set of operators defined in the profile. Right now, it appears that the supported operators are similar to those of description logic, but can/should we support more operators? For example, operators for “reflexive transitive closure” (e.g. friend-of-friend-of-friend-…), “cardinality” (number of related entities that satisfy a predicate), or inverse relations?   Regards, Mohammad Jafari, Ph.D. Security Architect, Edmond Scientific Company       From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Steven Legg Sent: Tuesday, October 22, 2013 12:18 AM To: xacml@lists.oasis-open.org Subject: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded   Submitter's message This is the initial draft for the Related and Nested Entities Profile - my response to the "Attributes of Relations" email thread. I changed from "Embedded" to "Nested" in the title because it better suggests the idea that entities can be embedded in other entities to any depth. A nested entity is what I have previously called a compound attribute. As well as the ForAny and ForAll expressions that I have discussed on the mailing list I have defined a Select _expression_ as a convenience to policy writers who like to think in SQL terms. The examples go beyond simply addressing the "Attributes of Relations" concerns. -- Dr. Steven Legg Document Name : XACML v3.0 Related and Nested Entities Profile Version 1.0 Description It is not unusual for access control policy to be dependent on attributes that are not naturally properties of the access subject or resource, but rather are properties of entities that are related to the access subject or resource. This profile defines the means to reference such attributes from within XACML policies for processing by a policy decision point. Download Latest Revision Public Download Link Submitter : Dr. Steven Legg Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2013-10-21 23:17:29  


  • 7.  Re: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 10-31-2013 05:04
    Hi Mohammad, On 30/10/2013 3:59 PM, Mohammad Jafari wrote: Thanks Steven for the well-written document. I had some minor comments and some issues to discuss: S2.1P4: "Evaluation of the expression MAY terminate at the first value from the domain for which the iterant expression evaluates to “true”." I think the meaning of "first" here is ambiguous and might be misleading as according to the spec, bags are unordered. I suggest either editing this to remove the word “first” or adding a sentence to emphasize that the implementation must not assume any particular order for processing of bags, and first means the first entity encountered regardless of the order of processing. Terminating at the "first" value is actually more specific than necessary, so I think I'll change this to: Evaluation of the expression MAY terminate when the iterant expression evaluates to "true". Likewise for the other quantified expressions. S2.1P4 and S2.2: I suggest that, since there is no formal definition of these quantifiers, we explicitly clarify the value of ForAny and ForAll for an empty Domain. I think the empty domain case is adequately covered by the final "otherwise" in the specification of the evaluation of the expressions, but I'll add an explicit statement anyway. Something like this for ForAny: Note that the ForAny expression evaluates to "false" if the domain is an empty bag. Likewise for the other quantified expressions. There are also two issues for discussion: -As someone said before on the list, in case of large data sets, there should be a mechanism to notify the PEP or PAP to include in the request only part of the related entities that are consequential in the PDP’s decision. For example, if the policy is to allow access “if the resource owner has a friend who is over 18”, this will require including all of the resource owner’s friends in the request. Finding some way to communicate what is sufficient to be included in the request is at least worth mentioning as an implementation issue. I assume you meant PIP rather than PAP. I expect the context handler and the PIP(s) to do most of the work of fetching entities in a typical deployment. It is more efficient to deal with it once on the context handler side than to impose extra duties on every one of the PEPs. The SAML profile describes an AttributeQuery, which is the basic functionality that a PIP needs to provide, but it seems like no one supports it and the boundary between context handler and PIP is rather fuzzy in practice. What that means is that implementations are free to make their PIP handlers smarter in whatever way they see fit. Standardizing an efficient, entity-aware exchange between context handler and PIP seems a bit pointless if everyone is ignoring the standard we already have. When it comes to communicating to a PEP about missing attributes, the MissingAttributeDetail element is adequate for reporting a missing attribute in a related entity, but can't describe a missing attribute in a nested entity. Adding an otherwise unnecessary URI identifier to nested entities, or creating an extended missing attribute detail element, would fix that deficiency, but I haven't given the issue much attention because I don't expect the average PEP to have the ability to conjure up the attributes of an arbitrary entity in response to a missing attribute error. Rather I expect that a comprehensive application profile would describe the different kinds of entities, the entity attributes (including link attributes), which entities are nested and which attributes and entities the PEP is expected to provide (with a distinct bias towards as little as possible). If a PEP sends everything it is expected to, then a missing attribute error is not something it needs to followup on. A PEP strategy of leaving out some expected information on the assumption that it can satisfy missing attribute errors in a followup is likely to be counter-productive. Describing a sufficient set of attribute values would not be trivial either, especially trying to do it in one go. For instance, the missing attribute detail could indicate that "only friends over 18" are required, but what if another policy wants to count the total number of friends ? And the PEPs would have to be as accomplished at evaluating expressions as the PDP. -There should be some sort of discussion about the completeness of the set of operators defined in the profile. Completeness with respect to what criteria ? Right now, it appears that the supported operators are similar to those of description logic, but can/should we support more operators? For example, operators for “reflexive transitive closure” (e.g. friend-of-friend-of-friend-…), I specifically excluded doing anything about transitive closure because I figure getting acceptance of the profile is hard enough without adding transitive closure into the mix. If I were to do something about transitive closure it would need a better motivating example than the transitive closure of the "friends-of" relation, which would likely include everybody except new users who hadn't yet built a network of friends. From the perspective of authorization that isn't a particularly interesting result. > “cardinality” (number of related entities that satisfy a predicate), Applying the type-bag-size function to the result of a Select expression gives a number that can be compared. Did you have anything more exotic in mind ? or inverse relations? There's nothing stopping an application profile from defining reciprocating links between entities, though following links leading away from the access subject and resource entities will generally lead to simpler, more efficient expressions, which is why all the examples are structured that way. I would not want to make reverse links mandatory, or define the means to use any forward link as a backward link, because it means adding extra support in PIP handlers or PEPs for attributes that would rarely, if ever, be used in policies. Regards, Steven Regards, Mohammad Jafari, Ph.D. Security Architect, Edmond Scientific Company *From:*xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] *On Behalf Of *Steven Legg *Sent:* Tuesday, October 22, 2013 12:18 AM *To:* xacml@lists.oasis-open.org *Subject:* [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded /Submitter's message/ This is the initial draft for the Related and Nested Entities Profile - my response to the "Attributes of Relations" email thread. I changed from "Embedded" to "Nested" in the title because it better suggests the idea that entities can be embedded in other entities to any depth. A nested entity is what I have previously called a compound attribute. As well as the ForAny and ForAll expressions that I have discussed on the mailing list I have defined a Select expression as a convenience to policy writers who like to think in SQL terms. The examples go beyond simply addressing the "Attributes of Relations" concerns. -- Dr. Steven Legg *Document Name*: XACML v3.0 Related and Nested Entities Profile Version 1.0 < https://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=51130 > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- *Description* It is not unusual for access control policy to be dependent on attributes that are not naturally properties of the access subject or resource, but rather are properties of entities that are related to the access subject or resource. This profile defines the means to reference such attributes from within XACML policies for processing by a policy decision point. Download Latest Revision < https://www.oasis-open.org/apps/org/workgroup/xacml/download.php/51130/latest/xacml-3.0-related-entities-v1.0-wd01.doc > Public Download Link < https://www.oasis-open.org/committees/document.php?document_id=51130&wg_abbrev=xacml > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- *Submitter*: Dr. Steven Legg *Group*: OASIS eXtensible Access Control Markup Language (XACML) TC *Folder*: Specifications and Working Drafts *Date submitted*: 2013-10-21 23:17:29


  • 8.  Re: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 11-20-2013 14:47
    Hi Steven, Thanks for the work on this. It looks to me to solve the issues it is designed to solve. Here are a few small comments: - Did you intend the whole introduction section to be normative? I guess it's ok as it is, but one could perhaps split of some of the exposition into a non-normative section so that this material does not clutter the normative content with potential ambiguities or mistakes. - I think it should say that the schema fragments in the document are non-normative. Word can easily auto-suggest and break technical content in the document and we don't want to specify the same thing twice (once in the fragment and once in the full schema) - In section 2, in the first paragraph after the QuantifiedExpressionType schema fragment, it says that the domain evaluates to a bag of a primitive data-type . Shouldn't this be atomic data-type ? I read primitive data type to mean a non-entity data type, but what I believe you mean is that the value must not be a bag. - I think the schema file should be split out from the word document. Word can easily auto-suggest and break technical content and it is more convenient for implementers and others to have an official schema file to use directly. - Are there any concerns to worry about when we define additional content into the existing XACML 3.0 namespace and schema? I am not well enough knowledgeable in XML schema best practices, so I am just asking. ;-) Best regards, Erik On 2013-10-22 08:17, Steven Legg wrote: Submitter's message This is the initial draft for the Related and Nested Entities Profile - my response to the Attributes of Relations email thread. I changed from Embedded to Nested in the title because it better suggests the idea that entities can be embedded in other entities to any depth. A nested entity is what I have previously called a compound attribute. As well as the ForAny and ForAll expressions that I have discussed on the mailing list I have defined a Select _expression_ as a convenience to policy writers who like to think in SQL terms. The examples go beyond simply addressing the Attributes of Relations concerns. -- Dr. Steven Legg Document Name : XACML v3.0 Related and Nested Entities Profile Version 1.0 Description It is not unusual for access control policy to be dependent on attributes that are not naturally properties of the access subject or resource, but rather are properties of entities that are related to the access subject or resource. This profile defines the means to reference such attributes from within XACML policies for processing by a policy decision point. Download Latest Revision Public Download Link Submitter : Dr. Steven Legg Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2013-10-21 23:17:29


  • 9.  Re: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 11-21-2013 07:37
    Hi Erik, On 21/11/2013 1:47 AM, Erik Rissanen wrote: Hi Steven, Thanks for the work on this. It looks to me to solve the issues it is designed to solve. Here are a few small comments: - Did you intend the whole introduction section to be normative? Not really. I guess it's ok as it is, but one could perhaps split of some of the exposition into a non-normative section so that this material does not clutter the normative content with potential ambiguities or mistakes. The normative bits are about URI references to related entities. I'll see what I can do about separating that out, perhaps into a new section before Section 3. - I think it should say that the schema fragments in the document are non-normative. Agreed. > Word can easily auto-suggest and break technical content in the document and we don't want to specify the same thing twice (once in the fragment and once in the full schema) - In section 2, in the first paragraph after the QuantifiedExpressionType schema fragment, it says that the domain evaluates to a bag of a "primitive data-type". Shouldn't this be "atomic data-type"? I read primitive data type to mean a non-entity data type, but what I believe you mean is that the value must not be a bag. I define the entity data-type to be "primitive" in Section 3, basically to be aligned with the core specification that talks about primitive values and bags of primitive values. If the entity data-type isn't "primitive", then parts of the core specification would need to be redefined to accommodate the concept of a bag of entities. If we choose to clean up the terminology in the core with errata, then I'm happy to align with any revised terminology. By the way, I don't consider x500Name to be all that "primitive" either, but it is described as such in the core. As far as Section 2 is concerned, the domain (to be renamed "range") is a bag of values. Those values can be of any data-type. I could simply say "a bag of values of any data-type", but the issue of alignment with the core would still remain. - I think the schema file should be split out from the word document. Word can easily auto-suggest and break technical content and it is more convenient for implementers and others to have an official schema file to use directly. I intend to do that, once I work out the naming conventions and packaging requirements. I stuck the full schema in an appendix as a temporary measure. Appendix B will go away. - Are there any concerns to worry about when we define additional content into the existing XACML 3.0 namespace and schema? I am not well enough knowledgeable in XML schema best practices, so I am just asking. ;-) XML Schema seems to allow it by the include mechanism, but whether all commonly used XML tools can handle it is another matter. I would be interested in any feedback from implementors as to whether or not it proves troublesome. Thanks, Steven Best regards, Erik On 2013-10-22 08:17, Steven Legg wrote: /Submitter's message/ This is the initial draft for the Related and Nested Entities Profile - my response to the "Attributes of Relations" email thread. I changed from "Embedded" to "Nested" in the title because it better suggests the idea that entities can be embedded in other entities to any depth. A nested entity is what I have previously called a compound attribute. As well as the ForAny and ForAll expressions that I have discussed on the mailing list I have defined a Select expression as a convenience to policy writers who like to think in SQL terms. The examples go beyond simply addressing the "Attributes of Relations" concerns. -- Dr. Steven Legg *Document Name*: XACML v3.0 Related and Nested Entities Profile Version 1.0 < https://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=51130 > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --- *Description* It is not unusual for access control policy to be dependent on attributes that are not naturally properties of the access subject or resource, but rather are properties of entities that are related to the access subject or resource. This profile defines the means to reference such attributes from within XACML policies for processing by a policy decision point. Download Latest Revision < https://www.oasis-open.org/apps/org/workgroup/xacml/download.php/51130/latest/xacml-3.0-related-entities-v1.0-wd01.doc > Public Download Link < https://www.oasis-open.org/committees/document.php?document_id=51130&wg_abbrev=xacml > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --- *Submitter*: Dr. Steven Legg *Group*: OASIS eXtensible Access Control Markup Language (XACML) TC *Folder*: Specifications and Working Drafts *Date submitted*: 2013-10-21 23:17:29


  • 10.  Re: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 11-21-2013 08:46
    Hi Steven, Ok, I guess "primitive" does not mean what I thought, so we can let it be like that. Or you could perhaps change it to "non-bag values"? Best regards, Erik On 2013-11-21 08:36, Steven Legg wrote: Hi Erik, On 21/11/2013 1:47 AM, Erik Rissanen wrote: Hi Steven, Thanks for the work on this. It looks to me to solve the issues it is designed to solve. Here are a few small comments: - Did you intend the whole introduction section to be normative? Not really. I guess it's ok as it is, but one could perhaps split of some of the exposition into a non-normative section so that this material does not clutter the normative content with potential ambiguities or mistakes. The normative bits are about URI references to related entities. I'll see what I can do about separating that out, perhaps into a new section before Section 3. - I think it should say that the schema fragments in the document are non-normative. Agreed. > Word can easily auto-suggest and break technical content in the document and we don't want to specify the same thing twice (once in the fragment and once in the full schema) - In section 2, in the first paragraph after the QuantifiedExpressionType schema fragment, it says that the domain evaluates to a bag of a "primitive data-type". Shouldn't this be "atomic data-type"? I read primitive data type to mean a non-entity data type, but what I believe you mean is that the value must not be a bag. I define the entity data-type to be "primitive" in Section 3, basically to be aligned with the core specification that talks about primitive values and bags of primitive values. If the entity data-type isn't "primitive", then parts of the core specification would need to be redefined to accommodate the concept of a bag of entities. If we choose to clean up the terminology in the core with errata, then I'm happy to align with any revised terminology. By the way, I don't consider x500Name to be all that "primitive" either, but it is described as such in the core. As far as Section 2 is concerned, the domain (to be renamed "range") is a bag of values. Those values can be of any data-type. I could simply say "a bag of values of any data-type", but the issue of alignment with the core would still remain. - I think the schema file should be split out from the word document. Word can easily auto-suggest and break technical content and it is more convenient for implementers and others to have an official schema file to use directly. I intend to do that, once I work out the naming conventions and packaging requirements. I stuck the full schema in an appendix as a temporary measure. Appendix B will go away. - Are there any concerns to worry about when we define additional content into the existing XACML 3.0 namespace and schema? I am not well enough knowledgeable in XML schema best practices, so I am just asking. ;-) XML Schema seems to allow it by the include mechanism, but whether all commonly used XML tools can handle it is another matter. I would be interested in any feedback from implementors as to whether or not it proves troublesome. Thanks, Steven Best regards, Erik On 2013-10-22 08:17, Steven Legg wrote: /Submitter's message/ This is the initial draft for the Related and Nested Entities Profile - my response to the "Attributes of Relations" email thread. I changed from "Embedded" to "Nested" in the title because it better suggests the idea that entities can be embedded in other entities to any depth. A nested entity is what I have previously called a compound attribute. As well as the ForAny and ForAll expressions that I have discussed on the mailing list I have defined a Select expression as a convenience to policy writers who like to think in SQL terms. The examples go beyond simply addressing the "Attributes of Relations" concerns. -- Dr. Steven Legg *Document Name*: XACML v3.0 Related and Nested Entities Profile Version 1.0 < https://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=51130 > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *Description* It is not unusual for access control policy to be dependent on attributes that are not naturally properties of the access subject or resource, but rather are properties of entities that are related to the access subject or resource. This profile defines the means to reference such attributes from within XACML policies for processing by a policy decision point. Download Latest Revision < https://www.oasis-open.org/apps/org/workgroup/xacml/download.php/51130/latest/xacml-3.0-related-entities-v1.0-wd01.doc > Public Download Link < https://www.oasis-open.org/committees/document.php?document_id=51130&wg_abbrev=xacml > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *Submitter*: Dr. Steven Legg *Group*: OASIS eXtensible Access Control Markup Language (XACML) TC *Folder*: Specifications and Working Drafts *Date submitted*: 2013-10-21 23:17:29


  • 11.  RE: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 12-09-2013 17:33
      |   view attached
    Steven,   Let me first congratulate you on an excellent piece of work. I consider this to be one of only two or three significant extensions of the XACML processing model since its inception. (The others being the delegation profile and perhaps the schema generalization on which it depends and builds.) Like the others, it provides valuable new functionality in a way that is consistent with both the mechanisms and style of the original. I am particularly pleased that this profile will tend to make policy intent clearer than other alternatives considered and I believe will preserve the properties of the language which enable semantic analysis.   You have not only solved the recently discussed problem of representing entities which do not fall cleanly into the traditional Subject, Resource, Action & Environment Categories, and showed how the solution can meet the requirements for which Policy Templates were proposed by TSCP in 2012, but your solution will also enable better handling of various longstanding issues with the policy model. For example, the case of multiple Intermediary Subjects can be handled by making each Intermediary’s Attributes a Nested Entity under the Intermediary Subject.   I think the main opportunity for improvement is to make the Profile a little more accessible to those who may be new to the problem space. Refactoring the Introduction will help. Adding a couple of diagrams may also help. I also found that after trying to grasp the details, I lost the forest for the trees. I suggest a brief, high level summary which shows how the new functions and expressions relate to the entities.   I have attached some ideas for diagrams, please treat them as no more than a suggestion. It might also be good to have a diagram which suggests how the nested and related abstractions relate to the physical layout of the request context.   Here is some draft language which might appear at the beginning or the end of the introduction. Again please take it as only a suggestion.   In summary, this profile defines a way of representing Nested and Related Entities in the Request Context and alternatives to existing XACML 3.0 mechanisms to access and traverse these Entities. Nested Entities are represented by a new datatype (…:data-type:entity) which carries all the attributes of the entity as its value. The Nested Entity appears in the Request Context as a sub-element of the containing Entity. Related Entities are represented by means of an Attribute of type URI which acts as a pointer to the Related Entity. The Related Entity appears elsewhere in the Request Context as a Peer Entity with a Category of the corresponding URI value. In both cases, the policy author does not need any knowledge of the Entity’s Category in order to reference it. The Profile also defines Designator and Selector functions which do the same thing as the corresponding elements in XACML 3.0, but understand Nested and Related Entities. The Profile also defines Quantified expressions which perform the same role as the higher-order bag functions of XACML 3.0, of manipulating bags of values without the need for an explicit looping construct. However by declaring an explicit Quantified variable, the Quantified expressions may be nested without ambiguity.   With regard to the comments made by others:   I think Domain is the right word and I don’t think anyone will confuse it with Security Domain or Policy Domain. If you think of a bag as a function, with the independent variable being the member of the bag and the value of the function being the value of the corresponding member, then in standard mathematical terminology the set of all values of the independent variable is the Range and the collection of all values of the function is the Domain. I think calling the Domain the Range would be particularly unfortunate. Calling it the quantifier Domain is acceptable, but seems unnecessarily verbose.   I think keeping to details of the examples distinct from any other Profile is a good idea.   With respect to including the Schema or fragments of it, I note the following. XACML has traditionally inserted schema fragments into the text at the point where the elements are discussed and provided the entire schema as a separate file. Other TCs provide only the separate file or provide the schema as an appendix. I am happy with any of these. In particular, it is not clear to me how helpful the schema fragments are to readers. Finally note that OASIS TC process requires:   Computer Language Definitions. All normative computer language definitions that are part of the Work Product, such as XML instances, schemas and Java(TM) code, including fragments of such, must be well formed and valid.   I agree we should stick with “primitive” datatype to indicate scalar types. Non-primitive types include not only multi-value attributes (represented as bags) but also attributes represented as complex types in XML. The term comes from XML Schema Part 2: Datatypes Section 2.5.2, although I admit that in cases like X.500Name and URI we have stretched it a bit.   Hal     From: Steven Legg [mailto:steven.legg@viewds.com] Sent: Tuesday, October 22, 2013 2:18 AM To: xacml@lists.oasis-open.org Subject: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded   Submitter's message This is the initial draft for the Related and Nested Entities Profile - my response to the "Attributes of Relations" email thread. I changed from "Embedded" to "Nested" in the title because it better suggests the idea that entities can be embedded in other entities to any depth. A nested entity is what I have previously called a compound attribute. As well as the ForAny and ForAll expressions that I have discussed on the mailing list I have defined a Select _expression_ as a convenience to policy writers who like to think in SQL terms. The examples go beyond simply addressing the "Attributes of Relations" concerns. -- Dr. Steven Legg Document Name : XACML v3.0 Related and Nested Entities Profile Version 1.0 Description It is not unusual for access control policy to be dependent on attributes that are not naturally properties of the access subject or resource, but rather are properties of entities that are related to the access subject or resource. This profile defines the means to reference such attributes from within XACML policies for processing by a policy decision point. Download Latest Revision Public Download Link Submitter : Dr. Steven Legg Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2013-10-21 23:17:29   Attachment: Entities Diagrams.pptx Description: application/vnd.openxmlformats-officedocument.presentationml.presentation

    Attachment(s)

    pptx
    Entities Diagrams.pptx   46 KB 1 version


  • 12.  Re: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 12-12-2013 06:11
    Hi Hal, Thanks for the feedback and detailed proposals. Comments below. On 10/12/2013 4:32 AM, Hal Lockhart wrote: Steven, Let me first congratulate you on an excellent piece of work. I consider this to be one of only two or three significant extensions of the XACML processing model since its inception. (The others being the delegation profile and perhaps the schema generalization on which it depends and builds.) Like the others, it provides valuable new functionality in a way that is consistent with both the mechanisms and style of the original. I am particularly pleased that this profile will tend to make policy intent clearer than other alternatives considered and I believe will preserve the properties of the language which enable semantic analysis. You have not only solved the recently discussed problem of representing entities which do not fall cleanly into the traditional Subject, Resource, Action & Environment Categories, and showed how the solution can meet the requirements for which Policy Templates were proposed by TSCP in 2012, but your solution will also enable better handling of various longstanding issues with the policy model. For example, the case of multiple Intermediary Subjects can be handled by making each Intermediary’s Attributes a Nested Entity under the Intermediary Subject. I think the main opportunity for improvement is to make the Profile a little more accessible to those who may be new to the problem space. Refactoring the Introduction will help. Adding a couple of diagrams may also help. I also found that after trying to grasp the details, I lost the forest for the trees. I suggest a brief, high level summary which shows how the new functions and expressions relate to the entities. I have attached some ideas for diagrams, please treat them as no more than a suggestion. It might also be good to have a diagram which suggests how the nested and related abstractions relate to the physical layout of the request context. Turning the diagrams on their side (with the attribute names running down the left side) will make them relate more directly to the layout in the request context. Presenting the same information in both a diagram and XML, with boxes around the entities and highlighted attribute names and values, should make the correspondence clear. Here is some draft language which might appear at the beginning or the end of the introduction. Again please take it as only a suggestion. In summary, this profile defines a way of representing Nested and Related Entities in the Request Context and alternatives to existing XACML 3.0 mechanisms to access and traverse these Entities. Nested Entities are represented by a new datatype (…:data-type:entity) which carries all the attributes of the entity as its value. The Nested Entity appears in the Request Context as a sub-element of the containing Entity. Related Entities are represented by means of an Attribute of type URI which acts as a pointer to the Related Entity. The Related Entity appears elsewhere in the Request Context as a Peer Entity with a Category of the corresponding URI value. In both cases, the policy author does not need any knowledge of the Entity’s Category in order to reference it. The Profile also defines Designator and Selector functions which do the same thing as the corresponding elements in XACML 3.0, but understand Nested and Related Entities. The Profile also defines Quantified expressions which perform the same role as the higher-order bag functions of XACML 3.0, of manipulating bags of values without the need for an explicit looping construct. However by declaring an explicit Quantified variable, the Quantified expressions may be nested without ambiguity. Also taking into account Erik's comments about the introduction, I see two possibilities. I could add something like the suggested text to the end of the introduction after pulling out the normative bits into an immediately following section, or I could rework the text into a sort of executive summary of the profile as the new introduction followed by some background discussion (essentially, the current introduction minus the normative bits) and then the normative bits. I'm leaning towards the latter. With regard to the comments made by others: I think Domain is the right word and I don’t think anyone will confuse it with Security Domain or Policy Domain. If you think of a bag as a function, with the independent variable being the member of the bag and the value of the function being the value of the corresponding member, then in standard mathematical terminology the set of all values of the independent variable is the Range and the collection of all values of the function is the Domain. I think calling the Domain the Range would be particularly unfortunate. Calling it the quantifier Domain is acceptable, but seems unnecessarily verbose. I think that means "domain" is slightly ahead of "range" as the preferred term. I think keeping to details of the examples distinct from any other Profile is a good idea. With respect to including the Schema or fragments of it, I note the following. XACML has traditionally inserted schema fragments into the text at the point where the elements are discussed and provided the entire schema as a separate file. I'm going to do that. > Other TCs provide only the separate file or provide the schema as an appendix. I am happy with any of these. In particular, it is not clear to me how helpful the schema fragments are to readers. Finally note that OASIS TC process requires: Computer Language Definitions. All normative computer language definitions that are part of the Work Product, such as XML instances, schemas and Java(TM) code, including fragments of such, must be well formed and valid. I agree we should stick with “primitive” datatype to indicate scalar types. Non-primitive types include not only multi-value attributes (represented as bags) but also attributes represented as complex types in XML. The term comes from *XML Schema Part 2: Datatypes***Section 2.5.2, although I admit that in cases like X.500Name and URI we have stretched it a bit.** I was thinking of changing to "bags of values" instead of "bags of a primitive data-type" to avoid the anachronism where possible. Thanks, Steven Hal *From:*Steven Legg [ mailto:steven.legg@viewds.com ] *Sent:* Tuesday, October 22, 2013 2:18 AM *To:* xacml@lists.oasis-open.org *Subject:* [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded /Submitter's message/ This is the initial draft for the Related and Nested Entities Profile - my response to the "Attributes of Relations" email thread. I changed from "Embedded" to "Nested" in the title because it better suggests the idea that entities can be embedded in other entities to any depth. A nested entity is what I have previously called a compound attribute. As well as the ForAny and ForAll expressions that I have discussed on the mailing list I have defined a Select expression as a convenience to policy writers who like to think in SQL terms. The examples go beyond simply addressing the "Attributes of Relations" concerns. -- Dr. Steven Legg *Document Name*: XACML v3.0 Related and Nested Entities Profile Version 1.0 < https://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=51130 > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- *Description* It is not unusual for access control policy to be dependent on attributes that are not naturally properties of the access subject or resource, but rather are properties of entities that are related to the access subject or resource. This profile defines the means to reference such attributes from within XACML policies for processing by a policy decision point. Download Latest Revision < https://www.oasis-open.org/apps/org/workgroup/xacml/download.php/51130/latest/xacml-3.0-related-entities-v1.0-wd01.doc > Public Download Link < https://www.oasis-open.org/committees/document.php?document_id=51130&wg_abbrev=xacml > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- *Submitter*: Dr. Steven Legg *Group*: OASIS eXtensible Access Control Markup Language (XACML) TC *Folder*: Specifications and Working Drafts *Date submitted*: 2013-10-21 23:17:29


  • 13.  RE: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

    Posted 12-12-2013 15:54
    > > I have attached some ideas for diagrams, please treat them as no more > than a suggestion. It might also be good to have a diagram which > suggests how the nested and related abstractions relate to the physical > layout of the request context. > > Turning the diagrams on their side (with the attribute names running > down the left side) will make them relate more directly to the layout > in the request context. Presenting the same information in both a > diagram and XML, with boxes around the entities and highlighted > attribute names and values, should make the correspondence clear. > You might want to consider first a simple diagram to illustrate the difference between Nested and Related located near the introduction and a little later a diagram which shows the how these abstractions related to the Request Context layout. > Also taking into account Erik's comments about the introduction, I see > two possibilities. > I could add something like the suggested text to the end of the > introduction after pulling out the normative bits into an immediately > following section, or I could rework the text into a sort of executive > summary of the profile as the new introduction followed by some > background discussion (essentially, the current introduction minus the > normative bits) and then the normative bits. I'm leaning towards the > latter. > I think either could work, but I also lean towards the latter. > I was thinking of changing to "bags of values" instead of "bags of a > primitive data-type" > to avoid the anachronism where possible. > Sounds good. Hal