[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