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: Re: [xacml] New core and multiple resource profile and hierarchical


Hi Rich,

Agreed, some good text to explain the benefits of a simple forest based 
model is something I support.

I also think a security consideration section is something we should put 
in there.

So, for the URI scheme we need to talk about forests. For the ancestor 
scheme I think we can avoid talking about the hierarchy, except to say 
that the hierarchy defined ancestors for the resource being requested, 
and that the ancestor model allows more complex (and possibly dangerous) 
hierarchies.

Best regards,
Erik

Rich.Levinson wrote:
> Hi Erik,
>
> I have made explicit recommendations in the v5-02 proposal. That 
> proposal could be scaled back to not include the introductory context, 
> which might require other introductory context to be corrected 
> accordingly.
>
> What it MUST include however, is the forest model. The reason for this 
> is that the existing profile gives:
>
>     * an explicit multi-hierarchy DAG general model,
>     * and an explicit multi-hierarchy URI concrete forest model
>
> What is missing is
>
>     * an explicit multihierarchy forest general model, which gives
>       meaningful conext to the URI concrete forest model
>
> Without this context, customers are led by the DAG model to dismantle 
> perfectly good functioning URI concrete infrastructures, which can be 
> both counter-productive and increase their security risks.
>
> I suggest that in the next few weeks that we analyze some use cases 
> that use a pure hierarchical model that compares how one would 
> implement a set of policies to protect some resources and specifically 
> analyze the impact of policies using the DAG, forest, and URI models.
>
> This does not have to go in the hierarchical profile itself, but would 
> be an adjunct informatory document, referenced in the hierarchical 
> profile, explaining the operational characteristics of the 
> hierarchical profile. I expect there may be customers who would be 
> interested in managing resources using ONLY the hierarchical profile, 
> and, as such, we have an obligation as a committee to understand what 
> the implications of such a choice can be.
>
> As the profile stands now, with a choice of general DAG and concrete 
> URI, I believe many customers will be unknowingly led into an insecure 
> DAG, when a perfectly reasonable secure forest could be shown to be a 
> clear alternative, with the extra cost, of course, of maintaining the 
> membership in the original hierarchies, which is necessary to 
> generalize the URI scheme.
>
>     Thanks,
>     Rich
>
>
> Erik Rissanen wrote:
>> Hi Rich,
>>
>> I understand the concern, but this is an issue where I would prefer 
>> to stand on my opinion "users need to understand". :-)
>>
>> I would like to leave the definition of the hierarchies outside the 
>> scope of the profile, and I would like to not forbid a DAG since 
>> there are users who are using DAGs, for instance the user who posted 
>> the earlier comment.
>>
>> In the thread started by Hal, entitled "Summary of what I think I 
>> said...", you said that the only change required is a change in 
>> section 3.2, where you want to insert the words "originally" and 
>> "explicitly". Those terms would need to be clarified and defined or 
>> the people coming in after us doing 4.0 will have a similar 
>> discussion about what we meant with that. ;-)
>>
>> If we leave the definition of a hierarchy open, expect that a 
>> hierarchy implies that the resource being accessed may have 
>> "ancestors", and that those ancestors are listed in the request 
>> context, then we don't have to worry about defining the subtle points 
>> of different types of hierarchies.
>>
>> Best regards,
>> Erik
>>
>>
>> Rich.Levinson wrote:
>>> Hi Erik,
>>>
>>> The problem is that the DAG model IS built into the profile. 
>>> "Ancestors" are explicitly defined by the term "each normative 
>>> representation of that ancestor node" in the algorithms of  section 
>>> 3.2, which clearly does not distinguish between hierarchies of which 
>>> the requested resource is a member.
>>>
>>> The DAG is NOT A HIERARCHY in terms that people commonly understand 
>>> hierarchy. It is quite the opposite and has none of the implied 
>>> authority or control of a conventionally understood hierarchy. The 
>>> DAG is a navigation mechanism, not a scope of control mechanism. It 
>>> has no defined scope of control in terms of the scope of the 
>>> original hierarchies from which it is derived.
>>>
>>> The suggestion that you make that people will be able to define 
>>> policies in such a way that they can avoid these subtle inheritance 
>>> characteristics is unrealistic in my opinion. You said:
>>>
>>>     "if someone writes a policy on an ancestor node, they have to
>>>     understand that they are granting rights to a whole section of a
>>>     hierarchy, and they need to understand what this means."
>>>
>>> However, it has taken several weeks of email exchanges to even get 
>>> people to understand what the issue is, never mind having to decide 
>>> how policies are impacted.
>>>
>>> There are serious security risks inherent in the DAG algorithms. It 
>>> only uses a portion of the hierarchical information, and what it 
>>> leaves out creates loopholes both in terms of how ancestors' 
>>> policies impact a specific resource and even renders ambiguous the 
>>> set of nodes that a particular policy will apply to, which can and 
>>> will change when some other hierarchy changes the scope of the 
>>> original hierarchy by simply creating new descendants when a member 
>>> of the original hierarchy becomes a member of the new hierarchy.
>>>
>>> The reason for these problems is that DAG throws away the 
>>> distinction between the hierarchies and creates a uniform 
>>> multi-rooted hierarchy out of collections of resources that are 
>>> defined in the context of distinct single-rooted hierarchies.
>>>
>>> The problem is inherent in the fact that a single-parent (and by 
>>> defn, single-rooted) hierarchy has much different authority and 
>>> control characteristics than when that same hierarchy is embedded in 
>>> a DAG with other hierarchies.
>>>
>>> What is lost is any ability to provide accountability and auditing 
>>> as to the responsibility of the person creating the policy, because 
>>> there is no way to determine what resources that policy will apply 
>>> to, because the DAG is constantly changing the scope as a result of 
>>> policy operations that are totally unrelated to each other.
>>>
>>> My proposals have shown explicitly how to address this situation. 
>>> Your primary response appears to be "people need to understand" what 
>>> the impact of their policies is, yet when I try to put in the text, 
>>> which gives them the tools to understand your reply is that people 
>>> don't need this information, despite the difficulty the TC as a 
>>> whole has had even understanding the issue.
>>>
>>>     Thanks,
>>>     Rich
>>>
>>>
>>>
>>>
>>> Erik Rissanen wrote:
>>>> Hi Rich,
>>>>
>>>> Thanks for this response and the examples. I now think that I 
>>>> finally understand what you mean and what the differences in 
>>>> opinion have all been about. :-)
>>>>
>>>> You are concerned about stray inheritance between different kinds 
>>>> of hierarchies. Like: John is a member of org unit A, which has 
>>>> headquarters in country X, which has Z as the main spoken language. 
>>>> This doesn't necessary mean that John should have the permissions 
>>>> of those who speak Z.
>>>>
>>>> I agree with you that this is a concern in practice, but it has not 
>>>> been in the scope of the hierarchical resource profile. The profile 
>>>> has simply said that "if you have hierarchies, this is how you can 
>>>> model requests/policies for the hierarchies". It doesn't say 
>>>> anything about what kind of hierarchies are meaningful to have, 
>>>> what relationships are relevant and how to manage the hierarchies.
>>>>
>>>> Within the profile there is an implied "relevant" hierarchy. Not 
>>>> any kind of connection or relationship in the real world is 
>>>> reflected as an inheritance relationship in the hierarchy for doing 
>>>> access control.
>>>>
>>>> Another issue relevant to this problem is, and I have already 
>>>> stated this, that if someone writes a policy on an ancestor node, 
>>>> they have to understand that they are granting rights to a whole 
>>>> section of a hierarchy, and they need to understand what this 
>>>> means. If it is the case that there is an organizational hierarchy 
>>>> subdivided by the country, but that the org units themselves may 
>>>> contain employees from other countries, then it is not appropriate 
>>>> to write a policy which says that all those belonging to the US org 
>>>> unit may have a holiday on the 4th of July. It's not an error in 
>>>> the profile. It's an error in policy modeling, using a hierarchy 
>>>> for something it is not appropriate for. It's an error inherent to 
>>>> the example, and no method of doing hierarchical policies could 
>>>> solve it.
>>>>
>>>> But this example also doesn't mean that the profile may never be 
>>>> used on hierarchies like this. It would be entirely appropriate to 
>>>> write a policy which says that anyone in the US org unit may see 
>>>> the common employee instruction documents of the US org unit, since 
>>>> presumably those working in the US org unit would need access to 
>>>> those documents, regardless of which country they are located in.
>>>>
>>>> So, in practice, the issue you are bringing up needs to be handled 
>>>> by being clear about your hierarchies and what they represent and 
>>>> what they do not represent. This is no different from any other 
>>>> kind of XACML attribute. And in practice, it's probably good 
>>>> practice to avoid complex hierarchies and inheritances between 
>>>> them. But all these considerations have been outside the scope of 
>>>> the profile.
>>>>
>>>> I'm not sure if the profile needs any text to handle this issue. 
>>>> Perhaps a security considerations section which says that since 
>>>> permissions are inherited in a hierarchy, it is very important that 
>>>> the hierarchies are well defined and understood and that people 
>>>> should avoid complex hierarchies and inheritance across hierarchies.
>>>>
>>>> Best regards,
>>>> Erik
>>>>
>>>>
>>>> Rich.Levinson wrote:
>>>>> Hi Erik,
>>>>>
>>>>> Responses inline:
>>>>>
>>>>>
>>>>> Erik Rissanen wrote:
>>>>>> Thanks Rich for the response,
>>>>>>
>>>>>> See responses inline.
>>>>>>
>>>>>> Rich.Levinson wrote:
>>>>>>> Hi Erik,
>>>>>>>
>>>>>>> Thanks for the input. I think there are still some fundamental 
>>>>>>> misunderstandings of what exactly the issue is that I have been 
>>>>>>> raising here (maybe not, maybe I am misunderstanding something 
>>>>>>> in which case, I will be happy to close the issue, but not there 
>>>>>>> yet). I will address your comments below after prelim comment:
>>>>>>>
>>>>>>> First, for people who have been observing this seemingly endless 
>>>>>>> sequence of extremely detailed emails, please rest assured that 
>>>>>>> I believe there is a significant issue that needs to be 
>>>>>>> addressed. Here are a couple introductory points to consider:
>>>>>>>
>>>>>>>     * As a result of the natural complexity of the problem of
>>>>>>>       identifying the applicable policies to apply to a requested
>>>>>>>       resource that can be known to policies under more than one
>>>>>>>       "normative hierarchical name" (where the "hierarchical" name
>>>>>>>       either contains the hierarchical info internally, as in 
>>>>>>> the case
>>>>>>>       of URI, or whether the name is an unstructured unique string
>>>>>>>       that uniquely identifies the resource in some external 
>>>>>>> resource
>>>>>>>       collection, whereby the contexthandler before submitting the
>>>>>>>       request is able to identify and collect all the relevant 
>>>>>>> names
>>>>>>>       of "hierarchical" ancestor nodes to the requested resource
>>>>>>>       node), these emails have had to contain enough detail to 
>>>>>>> address
>>>>>>>       some specific somewhat subtle characteristics of the 
>>>>>>> process for
>>>>>>>       collecting the list of ancestor nodes.
>>>>>>>     * To further help frame the issue, it should be commonly
>>>>>>>       understood that when a PEP submits a request, it is first
>>>>>>>       handled by a context handler, which is defined in XACML to
>>>>>>>       handle input requests as follows:
>>>>>>>           o "converts decision requests in the native request 
>>>>>>> format
>>>>>>>             to the XACML canonical form"
>>>>>>>     * Therefore the context handler needs to know, given a 
>>>>>>> requested
>>>>>>>       resource, how to assemble the list of ancestors for that
>>>>>>>       resource to submit with the request as part of its
>>>>>>>       responsibility of converting the request to "XACML 
>>>>>>> canonical form".
>>>>>>>     * The current document, before the modifications I made, had
>>>>>>>       effectively defined two methods of ancestor collection:
>>>>>>>           o an explicit method: defined by the algorithms in 
>>>>>>> section 3.2
>>>>>>>           o an implicit method: implied by the definition in 
>>>>>>> section
>>>>>>>             2.2 of how to form a URI that could be used with the
>>>>>>>             hierarchical profile, and by the anyURI methods 
>>>>>>> described
>>>>>>>             in section 4.3 intended to be used by policies that 
>>>>>>> apply
>>>>>>>             to resources identified using the guidelines of 
>>>>>>> section 2.2
>>>>>>>
>>>>>>
>>>>>> I see the value of the URI scheme, and I think we should add it 
>>>>>> to the profile as a separate section. For those cases where it 
>>>>>> works, it is simpler than the full DAG scheme.
>>>>> In my proposed spec, this is section 3.2.2.1 "The special disjoint 
>>>>> case where URI naming is used".
>>>>>
>>>>>>
>>>>>>>     * As it turns out, as can be understood in detail by 
>>>>>>> reviewing the
>>>>>>>       chain(s) of emails on this subject in Jan-Feb-Mar 2009,
>>>>>>>           o the explicit methods in section 3.2 imply that the
>>>>>>>             resources are collected in a manner that assumes that
>>>>>>>             policies will be written with the "mindset" of 
>>>>>>> protecting
>>>>>>>             a hierarchical resource structured as a DAG.
>>>>>>>           o the implicit methods of sections 2.2/4.3 effectively 
>>>>>>> imply
>>>>>>>             that the resources are collected in a manner that 
>>>>>>> assumes
>>>>>>>             that policies will be written with the "mindset" of
>>>>>>>             protecting a hierarchical resource structured as a 
>>>>>>> forest.
>>>>>>>             (For example, if a node has 2 normative URIs, then 
>>>>>>> it is a
>>>>>>>             member of 2 trees in the forest - policies written 
>>>>>>> using
>>>>>>>             anyURI will be applicable if their scope includes 
>>>>>>> either
>>>>>>>             of the 2 normative URIs
>>>>>>>
>>>>>>
>>>>>> Are you referring to the original profile, or the latest draft? I 
>>>>>> think we should forget about the original profile for now. It is 
>>>>>> clearly not consistent, so let's focus on what we want the new 
>>>>>> profile to be. :-)
>>>>> The above is referring to the original profile. In the proposed 
>>>>> v5-02 profile, section 3.2 has been split into section 3.2.1 
>>>>> (dag), 3.2.2 (forest), 3.2.2.1 (URI-forest).
>>>>>>
>>>>>> When we talk about what we want the profile to be like, I think 
>>>>>> it should support three schemes: the "ancestor scheme", the "XML 
>>>>>> doc scheme" and the new "URI scheme" which you have proposed.
>>>>>>
>>>>> Yes, the devil is in the details. Based on your suggestion, xml 
>>>>> doc scheme has always been in section 3.1. The dag version of the 
>>>>> ancestor scheme has always been in section 3.2. And the URI scheme 
>>>>> has always been in section 2.2/4.3.
>>>>>
>>>>> The problem, as I have stated since the very first email, is that 
>>>>> section 3.2 is a dag scheme, which I, personally believe, is not 
>>>>> suited for most security problems because it breaks down what is 
>>>>> commonly understood to be a "hierarchy". In order to avoid this 
>>>>> breakdown, it is necessary to retain the knowledge of the original 
>>>>> hierarchies, which is what we have been calling the forest scheme 
>>>>> in these emails.
>>>>>
>>>>> I fully understand that dags can be used combining resource trees 
>>>>> in a uniform manner and are very useful for modeling problems like 
>>>>> object multiple inheritance in UML, or resources that belong to 
>>>>> multiple categories in RDF. However, these are primarily 
>>>>> "navigation" hierarchies, where the main interest is in the 
>>>>> connectivity and the viewing and dealing with the resource 
>>>>> collection as a whole.
>>>>>
>>>>> However, for security applications, the fact that one can say that 
>>>>> policies can be viewed in a similar manner, may be true for some 
>>>>> limited applications, however, in general, policies and who is 
>>>>> issuing those policies matters, and so it is necessary that on be 
>>>>> able to trace back a policy to its originator. I think that in the 
>>>>> Delegation Profile you have dealt with a problem in the same 
>>>>> family, however, I have not yet had a chance to review Delegation 
>>>>> in enough depth to say that for sure. However, at a glance, for 
>>>>> example, in section 5 Example, where I see statements like:
>>>>>
>>>>>     "Policy 3 is issued by Mallory, as is indicated by the
>>>>>     <PolicyIssuer> element. The <Match> elements are on non-delegated
>>>>>     categories, so it is an access policy. It grants access to the
>>>>>     printer for Alice. As we will see later on, this policy is
>>>>>     unauthorized since Mallory has not been authorized to allow 
>>>>> access
>>>>>     for this situation (Alice accessing the printer).",
>>>>>
>>>>> this appears to me to be a very similar problem. I think there is 
>>>>> an analogy, as Hal used, that just because a policy has been 
>>>>> applied to one of my ancestors, does not mean that policy applies 
>>>>> to me. Possibly in the delegation case, the analogy is that the 
>>>>> original hierarchies, defined by known trusted sources of 
>>>>> authority, are treated differently from policies issued by 
>>>>> delegates of those authorities. Again, I am not sure the analogy 
>>>>> is correct, but the problem is that with the DAG model that 
>>>>> descendants of policies that apply to the specific resources, are 
>>>>> being applied to the descendants of those resources as well, which 
>>>>> I think, as I've said in several emails, is generally wrong except 
>>>>> in special cases where it is intended.
>>>>>
>>>>>>>     * This is roughly the point I was at when I started raising 
>>>>>>> this
>>>>>>>       issue. The first thing I noticed was that there were 
>>>>>>> effectively
>>>>>>>       2 different ancestor collection methods at work, which had 
>>>>>>> the
>>>>>>>       following curious properties:
>>>>>>>           o the methods in section 3.2 involve collecting 
>>>>>>> ancestors of
>>>>>>>             the resource that are not "direct" ancestors, in the 
>>>>>>> sense
>>>>>>>             that if the resource's parent has a parent that is not
>>>>>>>             directly connected then policies associated with that
>>>>>>>             ancestor apply to the requested resource
>>>>>>>                 + To use the common "sibling" terminology, a 
>>>>>>> "direct"
>>>>>>>                   ancestor would be a bloodline ancestor, such as a
>>>>>>>                   grandparent. In "indirect" ancestor would be
>>>>>>>                   equivalent to a "step-grandparent", i.e. one not
>>>>>>>                   connected by bloodline, but that established a
>>>>>>>                   relation with the bloodline parent "after the 
>>>>>>> fact"
>>>>>>>                   and now has an "indirect" relation with the
>>>>>>>                   "step-grandchild".
>>>>>>>           o So the question which "lights all the fires" on this 
>>>>>>> issue
>>>>>>>             is whether a "step-grandparent" should have an equal
>>>>>>>             relation with the requested resource as a bloodline
>>>>>>>             "grandparent".
>>>>>>>           o It turns out that with the DAG model there is no way 
>>>>>>> for
>>>>>>>             the context handler to differentiate between
>>>>>>>             "grandparents" and "step-grandparents", so the 
>>>>>>> answer is
>>>>>>>             ALWAYS that these are treated equally.
>>>>>>>           o By comparison, it turns out that "by default" (i.e. the
>>>>>>>             contexthandler just collects the set of URIs from the
>>>>>>>             resource with no need to search for ancestors 
>>>>>>> because all
>>>>>>>             the needed URIs are right there) using URIs that only
>>>>>>>             grandparents will be selected. "step-grandparents" 
>>>>>>> could
>>>>>>>             be obtained if desired, but simple out of the box URIs
>>>>>>>             give you only the bloodline ancestors.
>>>>>>>
>>>>>>
>>>>>> I don't think the profile should support telling apart the 
>>>>>> "bloodline" and "step-grandparents". They should all count as 
>>>>>> ancestors. Telling them apart is probably not worth the effort 
>>>>>> and extra complexity which would be introduced.
>>>>> This represents a clear black and white unambiguous disagreement. 
>>>>> It is the distinction between being a member of the original 
>>>>> hierarchy or being an incidental descendant of the combined 
>>>>> hierarchy, which is unavoidable with a DAG since all trace of the 
>>>>> original hierarchies has been erased.
>>>>>
>>>>> However, if what is giving you concern here is what impact this 
>>>>> has on policies or the PDP, there should be none. The significance 
>>>>> is in how the context handler gathers the ancestors to submit in 
>>>>> the request. If it gathers in dag-mode, all the problems I have 
>>>>> described appear. If it gathers in forest mode, those problems 
>>>>> disappear and you have the added benefit that you can still allow 
>>>>> any selected dag-like extensions that you want to explicitly allow.
>>>>>>>     * The reason I am concerned about this issue is that from a
>>>>>>>       security perspective, it makes little sense to me to force
>>>>>>>       commonly understood hierarchies, such as organization charts,
>>>>>>>       geographic breakdowns of organization operations, whether 
>>>>>>> within
>>>>>>>       a building or around the world, to suddenly have policies 
>>>>>>> that
>>>>>>>       are intended only to apply to the resources within these
>>>>>>>       specified domains, suddenly apply to resources outside of 
>>>>>>> these
>>>>>>>       domains.
>>>>>>>
>>>>>>
>>>>>> I don't understand this. Could you try go give an example?
>>>>> One example I gave was that if a manager in the United States, had 
>>>>> subordinates in the org chart in foreign countries, that if an HR 
>>>>> policy was applied to the geographic region, the United States, 
>>>>> such as the 4th of July holiday, then the DAG model would apply 
>>>>> that policy to all the US manager's foreign subordinates. I think 
>>>>> someone made the comment that that could be somehow fixed, but the 
>>>>> problem is that it is the DAG model that introduces the problem in 
>>>>> the first place, and this is just a benign trivial example of what 
>>>>> appears to me to be a total breakdown of security.
>>>>>
>>>>> The point here is that the US manager is in 2 hierarchies: 
>>>>> Geographic US, and org chart and has policies from those two 
>>>>> hierarchies applied the manager accordingly. The question now is 
>>>>> whether those policies cascade to subordinates. Presumably mgmt 
>>>>> policies to the org chart would, but geographic policies to the US 
>>>>> would not. The problem with DAG is it does not know anything about 
>>>>> the policies it is merging so it cannot distinguish these cases in 
>>>>> a meaningful way, and as a result merges them in a 
>>>>> counterproductive way.
>>>>>
>>>>>>
>>>>>>>     * Similarly, resources within these domains will find 
>>>>>>> themselves
>>>>>>>       subject to policies applied to resources outside of these 
>>>>>>> domains.
>>>>>>>           o For example, if I am a manager in the United States, 
>>>>>>> and
>>>>>>>             there is a policy that says employees in the United 
>>>>>>> States
>>>>>>>             may treat the 4th of July as a holiday, then anyone
>>>>>>>             outside the United States who has any superior 
>>>>>>> inside the
>>>>>>>             United States will be subject to this policy.
>>>>>>>           o Why? Because the resources are treated as a DAG. 
>>>>>>> DAGs do
>>>>>>>             not deal with resources individually, they only deal 
>>>>>>> with
>>>>>>>             subtrees.
>>>>>>>
>>>>>>
>>>>>> I don't see why this would happen. If you write a policy which 
>>>>>> says that "every one belonging to the organization of manager 
>>>>>> Rich may have a holiday on the 4th of July", then naturally that 
>>>>>> would apply to even those outside the US if they belong to the 
>>>>>> organization of Rich. If that's not what you intended, don't 
>>>>>> write such a policy. :-) Instead you should write a policy which 
>>>>>> says that everyone who has an attribute "location=US" may have a 
>>>>>> holiday on the 4th of July. Not use a hierarchy which does not 
>>>>>> correspond to the effect you intend.
>>>>> I see it is you who made the above-ref'd comment :). 
>>>>> Unfortunately, you are changing the problem. The problem is stated 
>>>>> that all employees in the US have this holiday. There is also a 
>>>>> policy that a certain permission is allowed to subordinates of the 
>>>>> manager.
>>>>>
>>>>> The manager has 2 attributes, one identifying the manager as 
>>>>> having a specific person-id, say "Rich", and one identifying the 
>>>>> manager has having a specific geographic-id, say "US".
>>>>>
>>>>> Now, without implementing a whole system, lets just say that 
>>>>> employees' membership in the geographic hierarchy is based on 
>>>>> their geographic-id, and that their membership in the org chart is 
>>>>> based on their supervisor-id.
>>>>>
>>>>> With the DAG mode, if the resources were assembled with these two 
>>>>> hierarchies as input, then "Rich" would be a member of the 
>>>>> geography hierarchy, as a descendant of "World", which would be 
>>>>> the top of the geography hierarchy, and "Rich" would be a member 
>>>>> of the org chart as a descendant thru the supervisor chain to "Mr. 
>>>>> CEO".
>>>>>
>>>>> With the DAG model, when ancestors are gathered, applicable 
>>>>> policies are those that apply to any of those ancestors, so 
>>>>> clearly any subordinates of "Rich" would have US geographic 
>>>>> policies applied, based on hierarchical membership alone. Granted 
>>>>> there may be details of those policies that later exclude them as 
>>>>> not applicable, but the point is they should not be included in 
>>>>> the first place.
>>>>>
>>>>> The risk here is that, if, for example, org chart resources were 
>>>>> protected by permit-overrides policies, where there is a deny 
>>>>> default, then it would appear that these policies could be 
>>>>> overridden by granting permits to resources thru the geographic 
>>>>> hierarchy.
>>>>>>
>>>>>>> With that background, let me address Erik's points:
>>>>>>>
>>>>>>>
>>>>>>> Erik Rissanen wrote:
>>>>>>>> Rich and TC,
>>>>>>>>
>>>>>>>> I have reviewed the draft you have posted (wd 05-02) as well as 
>>>>>>>> the recent discussion on the list, and I think the draft needs 
>>>>>>>> some more work.
>>>>>>>>
>>>>>>>> I agree with you that the old profile had lots of ambiguities 
>>>>>>>> and small errors in it, and I think you have done a good job at 
>>>>>>>> spotting them and you have improved the text in many places.
>>>>>>>>
>>>>>>>> However, I also think that the new work you have added in there 
>>>>>>>> complicates matters needlessly. There are two reasons for that:
>>>>>>>>
>>>>>>>> 1. You try to write the profile so it works with multiple 
>>>>>>>> intersecting hieararchies. I think that is the wrong way to do 
>>>>>>>> it. It should be specified for a single hierarchy only. If you 
>>>>>>>> need to apply it on multiple hierarchies, the way to do it is 
>>>>>>>> to preprocess the hierarchies by merging them into a single 
>>>>>>>> hierarchy. This joint hierarchy also needs to meet some 
>>>>>>>> consistency criteria, or the whole thing becomes meaningless 
>>>>>>>> and inconsistent. See more about that below.
>>>>>>> This is an invalid assertion. I leave the profile unchanged, 
>>>>>>> except for distinguishing the DAG and forest/polyarchy 
>>>>>>> distinctions.
>>>>>>
>>>>>> I don't see that there is a distinction which is relevant to the 
>>>>>> profile. I think the "ancestor scheme" should be defined for a 
>>>>>> DAG. Forests and others which are special cases of a DAG would be 
>>>>>> supported as special cases. I don't think the profile should 
>>>>>> support any form of hierarchy which is not a DAG because that 
>>>>>> would expand the scope to more complex models which we (or at 
>>>>>> least I ;-)) don't know how to handle.
>>>>> There are some of us who "know how to handle" common single parent 
>>>>> hierarchies without much difficult, and also the problem of being 
>>>>> the member of several common single parent hierarchies at the same 
>>>>> time.
>>>>>
>>>>> What I don't know how to handle is the case where the hierarchies 
>>>>> have multiple roots as in the case of DAG, which changes their 
>>>>> properties and makes it impossible to specify policies on 
>>>>> resources in one hierarchy that can't be overridden by policies 
>>>>> applied to those same resources from another hierarchy in an 
>>>>> undetectable manner.
>>>>>
>>>>> If the hierarchy from which the policy is being applied is 
>>>>> retained, then you can have conflict resolution after the clash is 
>>>>> detected as you can with a forest, but not if you merge everything 
>>>>> together in a DAG.
>>>>>
>>>>> If you have some process for handling the DAG case, please share 
>>>>> it, because that is the root of this problem. If, as I suspect, 
>>>>> that any such process relies on incorporating information outside 
>>>>> the DAG, then I also suspect that much of such extra processing 
>>>>> could be avoided by retaining forest information, which has an 
>>>>> added benefit of not including extra irrelevant nodes that the DAG 
>>>>> process brings in as ancestors.
>>>>>
>>>>>>
>>>>>>> The DAG is inherently is multiple "overlapping" hierarchies that 
>>>>>>> can be combined into a "single multiroot hierarchy" (see ref 
>>>>>>> prev email) 
>>>>>>> http://en.wikipedia.org/wiki/Directed_acyclic_graph#Properties
>>>>>>> The forest is inherently multiple "intersecting" hierarchies, 
>>>>>>> that can be combined into a "single multiroot disjoint 
>>>>>>> hierarchy" identical in every way to the DAG except that:
>>>>>>>
>>>>>>>    1. it retains the identity of the multiple hierarchies as its
>>>>>>>       disjoint property
>>>>>>>    2. it is not restricted from having "cycles" as long as the 
>>>>>>> circuit
>>>>>>>       travels over at least segments from 2 disjoint hierarchies
>>>>>>>
>>>>>>
>>>>>> I don't understand the above. A DAG by definition has no cycles.
>>>>> Right, but this is an artificial restriction on the DAG structure 
>>>>> that has nothing to do with policy. There is no reason in an 
>>>>> organization why two members cannot be mutual descendants in 
>>>>> different hierarchies, having to do with different business 
>>>>> operations they may be involved with. DAG will prevent such useful 
>>>>> relations from being established in the first place, which, 
>>>>> personally, I believe is counterproductive, but there may be use 
>>>>> cases for subsets of enterprise resources where it is appropriate.
>>>>>>
>>>>>> And a DAG is not inherently multiple hierarchies. It may be the 
>>>>>> case that multiple hierarchies of certain limited form may in 
>>>>>> general be mapped into a single DAG, but I don't think it is 
>>>>>> primarily relevant to the profile. I think we should keep the 
>>>>>> profile algorithms constrained to a single DAG. We can add 
>>>>>> explanatory text about how some special case hierarchies can be 
>>>>>> mapped to a DAG. But we should not try to define algorithms for 
>>>>>> multiple hierarchies because the algorithms become more complex 
>>>>>> to define, and in come cases the combination of multiple 
>>>>>> hierarchies won't lead to a consistent DAG.
>>>>> Whether relevant or not to a particular use case, the basic 
>>>>> property is true - see wiki ref where it gives formula for 
>>>>> factoring out the hierarchies. It is a useful property for the 
>>>>> purposes of analysis, because it reduces the more complex DAG to a 
>>>>> set of more familar "single-parent-rooted-hierarchies", which have 
>>>>> well known properties. It is exactly from this analysis that we 
>>>>> can see how the well known properties of the component single 
>>>>> parent hierarchies break down when combined in a DAG.
>>>>>>
>>>>>> For instance, consider the following:
>>>>>>
>>>>>> Resource A has normative "names" http://example.com/res/A and 
>>>>>> "res_1234".
>>>>>>
>>>>>> Resource B has normative "names" http://example.com/res/A/B and 
>>>>>> "foo_56".
>>>>>>
>>>>>> There exist two hierarchies. In the first hierarchy 
>>>>>> http://example.com/res/A is the parent of 
>>>>>> http://example.com/res/A/B.
>>>>>>
>>>>>> In the second hierarchy "foo_56" is the parent of "res_1234".
>>>>>>
>>>>>> These two hierarchies cannot be combined into a DAG, since the 
>>>>>> two hierarchies contradict each other. And we should not attempt 
>>>>>> to handle these cases in the profile. Instead the profile should 
>>>>>> require that there is a single consistent DAG which forms the 
>>>>>> hierarchy.
>>>>> I think you have proved my case. You are basically saying that 
>>>>> even though there  are resources that exist in hierarchies, they 
>>>>> may not be able to be used in the Hierarchical Profile because, 
>>>>> they happen to have some "glitch" that renders them "undaggable".
>>>>>
>>>>> This is exactly where the forest model comes in, because it does 
>>>>> not have this restriction and problem.
>>>>>>
>>>>>>> As should be clear from above description, and all previous 
>>>>>>> emails on this subject, the preprocessing is done by creating a 
>>>>>>> joint hierarchy. The only difference between the DAG and the 
>>>>>>> forest is that with the DAG, potentially useful information 
>>>>>>> about the joint hierarchy is thrown away, with the forest it is 
>>>>>>> kept. All is done before contexthandler submits request based on 
>>>>>>> what contexthandler is capable of doing with the resource 
>>>>>>> collection of which the requested resource is a member.
>>>>>>
>>>>>> Yes, I agree that the mapping to ancestor attributes throws away 
>>>>>> information. But I think that is a correct limitation for what we 
>>>>>> define as the scope of the profile. With the profile we intend 
>>>>>> only to support those policies which are possible to express with 
>>>>>> the limited set of information about the hierarchy. For instance, 
>>>>>> we can express that a policy should apply to all descendants to a 
>>>>>> given resource. However, we cannot express, for instance, that it 
>>>>>> should apply only three steps down the hierarchy, but not deeper.
>>>>> Again, this is a clear disagreement. I do not see any reason why 
>>>>> the hierarchical profile should exclude hierarchies, not even 
>>>>> based on anything about the hierarchy itself, but based on the 
>>>>> fact that it doesn't "combine into a DAG" with some other hierarchy.
>>>>>>
>>>>>>>
>>>>>>> Unfortunately, this statement appears to characterize the 
>>>>>>> conceptual gap on this issue:
>>>>>>>
>>>>>>>     "This joint hierarchy also needs to meet some consistency
>>>>>>>     criteria, or the whole thing becomes meaningless and 
>>>>>>> inconsistent."
>>>>>>>
>>>>>>> All one needs to do is peruse the emails to quickly realize that 
>>>>>>> it is the profile that mixes the DAG/forest concepts, which 
>>>>>>> renders the existing spec "meaningless and inconsistent" and 
>>>>>>> that my effort has been to separate these concepts in order to 
>>>>>>> establish meaning and consistency to the contents of the spec.
>>>>>>
>>>>>> Yes, I agree that the old profile mixes concepts such as DAGs and 
>>>>>> forests incorrectly. We need to fix that.
>>>>>>
>>>>> I see the problem as insidious, actually, because the hierarchical 
>>>>> profile basically does a "bait and switch" on the user, by 
>>>>> advertising itself as a "Hierarchical" profile, and then 
>>>>> substitutes a DAG, which, while in some math books has navigation 
>>>>> properties equivalent to those of commonly understood hierarchies, 
>>>>> it does not have the authority and control of commonly understood 
>>>>> hierarchies. This is fine for applications where authority and 
>>>>> control are not requirements, but generally security and access 
>>>>> control is all about authority and control.
>>>>>>>>
>>>>>>>> 2. You use the "root" concept. That is actually not required at 
>>>>>>>> all. As you have realized, the concept of a root in a DAG 
>>>>>>>> becomes messy to define and handle. I think we should just drop 
>>>>>>>> any reference to a "root" in the whole profile. All we need are 
>>>>>>>> "ancestors", and those are found by following the edges 
>>>>>>>> upwards. Not down from the root, so the root doesn't have to be 
>>>>>>>> defined. (In fact, in a DAG, there is not necessarily a unique 
>>>>>>>> root anyway.)
>>>>>>> DAG is a directed graph. If you keep following any parent 
>>>>>>> relationship recursively from the requested node you will come 
>>>>>>> to one of the roots of the DAG. If you chose different parents 
>>>>>>> along the way you will come to a different root, in general. In 
>>>>>>> a DAG, it doesn't matter from the perspective of the requested 
>>>>>>> node, all roots are functionally equivalent in the sense that 
>>>>>>> there is no inherent distinction as to the status of one root vs 
>>>>>>> another.
>>>>>>
>>>>>> Yes, it is possible to define roots. But what I say is that they 
>>>>>> are not relevant. We don't need the root in the profile. We only 
>>>>>> need to define ancestors to be able to express the kind of 
>>>>>> policies the profile is intended: policies which apply to 
>>>>>> sections of the hierarchy consisting of descendants of a given node.
>>>>> In most organizations the roots will correspond to sources of 
>>>>> authority and delegation, which I believe are generally relevant 
>>>>> in security applications.
>>>>>>
>>>>>>>
>>>>>>> In the forest model, you can have exactly the same layout as any 
>>>>>>> DAG. And you can traverse the same recursive paths to any of the 
>>>>>>> same roots. The only difference along the way is at each step 
>>>>>>> you know whether you are proceeding along the same hierarchy as 
>>>>>>> in your previous step or whether you are switching to another 
>>>>>>> hierarchy.
>>>>>>>
>>>>>>> In the world of security, these hierarchical paths are commonly 
>>>>>>> known as "lines of authority". Generally, in security 
>>>>>>> applications the notion of "clear lines of authority" is 
>>>>>>> desirable, and the notion of "tangled lines of authority" is 
>>>>>>> detrimental. This is precisely the distinction of forest (clear 
>>>>>>> lines) and DAG (tangled lines).
>>>>>>>>
>>>>>>>> Finally, I think we should write the normative sections so they 
>>>>>>>> target a DAG only. Trees and forests follow as special cases. 
>>>>>>>> We can add explanatory text to make this clear, but the 
>>>>>>>> normative parts become much simpler if we don't define many 
>>>>>>>> different types of hierarchies.
>>>>>>> Obviously, from my above remarks, if we were to target "only" 
>>>>>>> one of DAG or forest, I would choose forest because
>>>>>>>
>>>>>>>     * forest  represents "clear lines of authority" for security
>>>>>>>       applications
>>>>>>>     * URI as recommended in section 2.2 already provides it out 
>>>>>>> of the box
>>>>>>>
>>>>>>> and I would not choose DAG, because
>>>>>>>
>>>>>>>     * DAG represents uncontrolled ambiguous lines of authority
>>>>>>>     * DAG is intended for sub-tree, or whole "sub-assembly at a 
>>>>>>> time"
>>>>>>>       type of operations, which is why it is popular in source code
>>>>>>>       control systems. If we think global enterprises can be 
>>>>>>> modeled
>>>>>>>       as special case of source code control system then DAG 
>>>>>>> will be
>>>>>>>       great, otherwise, a forest is needed.
>>>>>>>
>>>>>>
>>>>>> I would choose to target a DAG since it is more general than a 
>>>>>> forest.
>>>>> I think that after this email that somehow we should be able to 
>>>>> identify the conceptual mismatch that we are basing our arguments 
>>>>> on. Clearly we both think we know exactly what we are talking 
>>>>> about, but somehow one or both of us is missing some assumptions 
>>>>> that the other is basing their arguments on.
>>>>>>
>>>>>>> Bottom line: I think when the dust and smoke is removed from 
>>>>>>> this issue, we are left with what kind of model do we want for 
>>>>>>> resources: a highly structured model as in forest, or a more 
>>>>>>> loosely structured, "social network" type of model such as DAG.
>>>>>>>
>>>>>>> Or we could follow the path I have represented in the profile 
>>>>>>> which is that you can choose either, as appropriate, for 
>>>>>>> specific subset of the overall enterprise resources.
>>>>>>
>>>>>> If we do DAG for the ancestor scheme and tree for the URI scheme 
>>>>>> then we cover both cases.
>>>>> True. This is what I have designed proposal 5-02 to address. 
>>>>> Section 3.2.1 is the DAG, and section 3.2.2 is the forest 
>>>>> (multiple trees), and 3.2.2.1 is the URI.
>>>>>>
>>>>>> Best regards,
>>>>>> Erik
>>>>> Thanks,
>>>>> Rich
>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Rich
>>>>>>>
>>>>>>>>
>>>>>>>> I propose the following changes:
>>>>>>>>
>>>>>>>> - First, a small nitpick. ;-) I don't like "Working draft 
>>>>>>>> 05-02". I think working drafts should progress 5, 6, 7, 8 and 
>>>>>>>> so on. It's confusing that there are several documents, all 
>>>>>>>> called working draft 5.
>>>>>>>>
>>>>>>>> - Remove all the new definitions of "polyarchy", etc. They are 
>>>>>>>> not needed. Use only the term "DAG".
>>>>>>>>
>>>>>>>> - Define a hierarchy as a DAG, where the nodes correspond to 
>>>>>>>> resources and the edges correspond to child-parent relationships.
>>>>>>>>
>>>>>>>> - Define that each node in the hierarchy has one or more 
>>>>>>>> "normative representations" (names). A normative 
>>>>>>>> representations is defined as an XACML datatype value instance, 
>>>>>>>> which is provided in the request (through the context handler 
>>>>>>>> or the PEP). A representation which is not provided in the 
>>>>>>>> request is not normative, and may not be referenced in policies.
>>>>>>>>
>>>>>>>> - This is actually already implied, but maybe worth stating: if 
>>>>>>>> one merges a number of hierarchies in the pre-processing step, 
>>>>>>>> the merged hiearchy must be consistent with respect to node 
>>>>>>>> representation/naming and the parent-child relationship. That 
>>>>>>>> is, if A and B are two representations of a node and C and D 
>>>>>>>> are representations of another node, and there is a 
>>>>>>>> relationship between the nodes, the same relationship applies 
>>>>>>>> to all representations/names. So all of the following would 
>>>>>>>> apply, not just some of them: A-C, A-D, B-C and B-D. I think 
>>>>>>>> the complexities in what you have done Rich is much due to that 
>>>>>>>> you have tried to cover hierarchies where this is not true. But 
>>>>>>>> those hierarchies are not internally consistent, so we cannot 
>>>>>>>> make them work.
>>>>>>>>
>>>>>>>> - The ancestors of a node are defined as simply the transitive 
>>>>>>>> closure of the parent-child relationship.
>>>>>>>>
>>>>>>>> Note that the above points imply that there is a single 
>>>>>>>> hierarchy which is a DAG. Also note that I don't make use of 
>>>>>>>> the term "root". It's not needed.
>>>>>>>>
>>>>>>>> - Add in a couple of examples with illustrations showing a 
>>>>>>>> simple tree formed DAG and a more complex DAG which is not a 
>>>>>>>> tree and show how the ancestors are found.
>>>>>>>>
>>>>>>>> - Remove section 1.1.1. It's not needed if we specify the 
>>>>>>>> algorithms on a sigle DAG only.
>>>>>>>>
>>>>>>>> - Make a separate section about the URI-only scheme, saying 
>>>>>>>> that "in some cases when the resources are represented as URIs, 
>>>>>>>> it may be possible to simply do matching on portions of the 
>>>>>>>> resource representations". Also make it clear that the PEP and 
>>>>>>>> PDP must agree on which scheme is used, or the policies won't 
>>>>>>>> work.
>>>>>>>>
>>>>>>>> - I think that a node may be represented by any XACML data 
>>>>>>>> type, like a string for instance, not just URIs. This is what 
>>>>>>>> the user posted to the comments list and requested that we change.
>>>>>>>>
>>>>>>>> - I think there are some problems with section 2.2. In 
>>>>>>>> particular, it should not say anything about UTF-8 encoding. 
>>>>>>>> That's already defined by the core schema and it's unicode 
>>>>>>>> consistency requirements. I think actually that we can drop the 
>>>>>>>> whole of section 2.2 and allow any form on the normative 
>>>>>>>> representations of nodes. There is no reason to restrict it to 
>>>>>>>> a particular form of a URI. (The section on the URI-based 
>>>>>>>> schema should of course contain some restrictions for how that 
>>>>>>>> scheme is made to work.)
>>>>>>>>
>>>>>>>> - We should not define a new identifier for a functionality 
>>>>>>>> named "...:forest:...".
>>>>>>>>
>>>>>>>> - There is no need to various subsections on multi-rooted 
>>>>>>>> hierarchies or polyarchies. See for instance 3.2.1 and 3.2.2.
>>>>>>>>
>>>>>>>> In short, I think we need very few changes compared to the 
>>>>>>>> original profile. We just need to clarify the terminology and 
>>>>>>>> definitions, put in a couple of illustrations, relax the data 
>>>>>>>> type restrictions and add a section of a URI matching based 
>>>>>>>> scheme as an alternative to the other two schemes.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Erik
>>>>>>>>
>>>>>>>> Rich.Levinson wrote:
>>>>>>>>> Hi Erik,
>>>>>>>>>
>>>>>>>>> The hierarchical profile is ready for review as is. There are 
>>>>>>>>> no more changes planned.
>>>>>>>>>
>>>>>>>>>     Note: The two added identifiers in section 2.2,
>>>>>>>>>     "...hierarchical:forest:non-xml-node-id" and 3.2.2,
>>>>>>>>>     "...hierarchical:forest:non-xml-node-req" are for 
>>>>>>>>> convenience only
>>>>>>>>>     and the spec could be rephrased without them, if necessary.
>>>>>>>>>
>>>>>>>>> The profile is located at:
>>>>>>>>> http://www.oasis-open.org/committees/document.php?document_id=31407&wg_abbrev=xacml 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The example that Hal requested, which provides further 
>>>>>>>>> motivation for the changes, as well as detailed explanatory 
>>>>>>>>> technical structure, is at:
>>>>>>>>> http://lists.oasis-open.org/archives/xacml/200902/msg00058.html
>>>>>>>>>
>>>>>>>>> A fresh example of application of the profile using URIs that 
>>>>>>>>> came up yesterday on the xacml-users list is at:
>>>>>>>>> http://lists.oasis-open.org/archives/xacml-users/200903/msg00001.html 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     Thanks,
>>>>>>>>>     Rich
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Erik Rissanen wrote:
>>>>>>>>>> All,
>>>>>>>>>>
>>>>>>>>>> I have posted new drafts of the core and the multiple 
>>>>>>>>>> resource profile. See the change logs and tracked changes for 
>>>>>>>>>> details.
>>>>>>>>>>
>>>>>>>>>> As far as I can tell, we don't have any open issues on the 
>>>>>>>>>> following specs:
>>>>>>>>>>
>>>>>>>>>> - Core
>>>>>>>>>> - Multiple resource
>>>>>>>>>> - Administration
>>>>>>>>>> - Privacy
>>>>>>>>>> - SAML
>>>>>>>>>> - Dsig
>>>>>>>>>>
>>>>>>>>>> The hierarchical profile is being discussed currently and 
>>>>>>>>>> there was discussion about improving the RBAC profile.
>>>>>>>>>>
>>>>>>>>>> The proposed work on the RBAC profile seems in very early 
>>>>>>>>>> stages and the issue (policies about management of roles) is 
>>>>>>>>>> a major topic, so I propose that we don't bring this in 3.0.
>>>>>>>>>>
>>>>>>>>>> So, could we agree on a feature freeze on the above mentioned 
>>>>>>>>>> profiles? If so, all of the expect hierarchical are ready for 
>>>>>>>>>> review before going to committee draft.
>>>>>>>>>>
>>>>>>>>>> I also propose that if we don't get resolutions on the issues 
>>>>>>>>>> in the hierarchical profile soon and it would appear that 
>>>>>>>>>> there are major changes required, then we use the old version 
>>>>>>>>>> of that profile. However, my understanding is that Rich has 
>>>>>>>>>> pretty much completed the work on that. I haven't had the 
>>>>>>>>>> time to review it myself yet, but I will do so now.
>>>>>>>>>>
>>>>>>>>>> So, given the above, can we agree on the following?
>>>>>>>>>>
>>>>>>>>>> - everybody reviews the above mentioned profiles
>>>>>>>>>> - We correct any mistakes
>>>>>>>>>> - I will fix the metadata, references, namespaces, etc,
>>>>>>>>>> - Go CD with the above
>>>>>>>>>>
>>>>>>>>>> One final issue: we need to update the acknowledgements 
>>>>>>>>>> section of the core. What goes in there? My name is not in 
>>>>>>>>>> there, and I would like to include it. :-) I presume that we 
>>>>>>>>>> keep all the old names, right? John Tolbert has requested to 
>>>>>>>>>> be added. Anybody else?
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Erik
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------------------- 
>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this mail list, you must leave the OASIS 
>>>>>>>>>> TC that
>>>>>>>>>> generates this mail.  Follow this link to all your TCs in 
>>>>>>>>>> OASIS at:
>>>>>>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --------------------------------------------------------------------- 
>>>>>>>>
>>>>>>>> To unsubscribe from this mail list, you must leave the OASIS TC 
>>>>>>>> that
>>>>>>>> generates this mail.  Follow this link to all your TCs in OASIS 
>>>>>>>> at:
>>>>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------- 
>>>>>>
>>>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>



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