[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: XACML F2F Notes on ebXML Registry Use Case
Sekhar, First of all, many thanks for attending, and also standing in my place. On the "Order" issue, the use of conditions is possibly the best approach for us. In this case, a (pre)condition for a rule could include the execution of certain actions on the target (in the case of the Registry the lifecycle operations have dependencies) E.g., remove happens after create. I don't believe "evaluation strategy" specification is the right solution. Accessing deprecated links is interesting (I remember talking about it in a con-call). I don't think this poses a big problem in representation. If the set of principals that can read a doc can change after deprecation, then we could add this condition for the "read" rule. I hope the above clarifies the issues discussed below. It is quite possible that I am not addressing the "real" issues discussed below. In which case, do let me know. Cheers, -Suresh -----Original Message----- From: sekhar vajjhala [mailto:sekhar.vajjhala@Sun.COM] Sent: Thursday, September 20, 2001 11:32 AM To: Damodaran, Suresh; regrep-security@lists.oasis-open.org Subject: XACML F2F Notes on ebXML Registry Use Case Suresh, Some clarifications are required with respect to the ebXML Use case submitted to the last XACML F2F meeting. I attended that meeting. There were some questions regarding this use case. I have extracted the ebXML related information from the informal F2F minutes (sent by Marlena Erdos) which show the questions raised. I did not have time to look into all this use case before the meeting. So I did not have an answer to all the questions but said I would take these questions back to you. The broad requirements that are indicated by this case have been noted. (i.e. ability for a client to specify access control policies). So summary: more examples and clarifications are needed for the use case. Sekhar ---- Log of minutes for ebXML Use Case ---- Sekhar: ebXML ver 1.0 . Registry clients can submit content to a registry. Currently there is only a defualt access control policy. The default is "The content can be submitted given that it is submitted by someone the registry wants to accept." There are no controls on reading the content. Now (new version?), the client can specify who can read and who can modify and delete. Anyone who submitted can modify or delete. "Deprecate" is harder. The idea is that no one else can create references to deprecated content. Existing users of the doc can continue. The bottom line on this use case: Submitter can specify custom access controls. Hal: With regard to linking to content do you have to be an author to link to a content? Can arbitrary links be done? Sekhar: This is an issue I can take back. As far as I know, anyone can link to a document that has been submitted to the registry. Hal: The issue of the access semantics of linking is interesting: not difficult but unusual. Bill: This issue comes up whenever there are multiple documents. Hal: The deprecation issues makes things different. Sekhar: The idea is that once a doc is deprecated no one else can link to it. Sekhar: A question on 2.3.4 "Order". Did this come up in the last conf call? Carlisle: Suresh brought it. He thought there might need to be an ordering of rules for evaluation. Simon: We have to specifiy an evaluation strategy for the policy. "Ordering" is one tactic. Sekhar: An OR-of-AND semantic is a possibility. Hal: Order of what? Simon raised up issues of resolving conflicting policies. Ordering is one tactic. But there is also the issue of conditions: a condition that must be fulfilled before a rule comes into play. Also, what about the notion of actions that must be fulfilled prior to access. This also requires sequencing. What are the real world requirements? Sekhar: I need to take back the issue of "conditions" to Suresh. -- -- Sekhar
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC