Hi,
I agree with Hal. We should make section 4 non-normative and rename
it "Example rules".
Where does it say anything about blacklists? I could not find
anything like that in the document. In any case, I agree with Hal
that we should not put restrictions on forms of policies.
Best regards,
Erik
On 2014-08-07 20:09, Hal Lockhart
wrote:
My
opinions on some of the points raised in this thread.
Undesirability
of black lists. In the abstract, the argument goes back to
the earliest days of XACML. It has appeared in many forms.
Should negative policies be allowed? Should combining
algorithms like default allow be prohibited? Should policy
creation tools prohibit “impossible” or “illogical”
policies. I believe you can find debates between me and Bill
on subjects of this sort dating back to 2001. That is before
XACML 1.0 existed.
The
approach the TC has always taken is to NOT limit the power
of the language, just because we can’t see a use for a
certain construct doesn’t mean there isn’t a legitimate one.
In addition there has generally been a sense that although
there might be a small number of truly useless policies,
(“A” and NOT “A”) it is not worth the trouble to try to
figure out what they are and require everyone to prohibit
them. Of course it is perfectly legal for editing tools to
detect questionable constructs and issue warnings or
suggestions.
Consistent
with this, I think it is ok to mention the use of blacklists
while warning of theuir dangers.
I
question the use of a policy as normative in any Profile. In
practice, the policies even if written with the same intent
there are bound to be small deployment–specific differences.
For example, what If I add an Issuer? What if I set
must_be_present to “true”? Without a detailed set of
criteria, how can I determine if a given policy is
compliant? I would prefer to say” You must check such and
such her is a sample of a policy that does the right thing.
As
far as exhibiting Privacy policies in general, I think it
would be a lot more useful to create a library of rules and
policies which are useful for checking Privacy. We could for
example start with the ones from the XSPA interops and then
add ones to cover the cases Mohammad has suggested.
In
my view the key thing in the policy that needs to be
normative is the syntax and semantics of the attributes and
any datatypes or functions defined in the Profile.
In
any event, I would like to get consensus on whether changes
are required and who is going to propose them.
Hal
From:
Erik Rissanen [mailto:]
Sent: Thursday, June 26, 2014 7:00 AM
To: Mohammad Jafari;
Subject: Re: [xacml] Comments on XACML Privacy
Policy v1.0 profile
Hi Hohammad,
What I meant is that someone may want to do a mix of user,
resource, action, etc, centric policies. Doing so would be
best done with the nested entities profile because then one
can store the different properties of allowed combinations
as data in a PIP, rather than lots of rules which describe
individual permissions.
Best regards,
Erik
On 2014-06-05 23:26, Mohammad Jafari
wrote:
Hi
Erik,
I
don’t follow how this relates to the nested and related
entities profile and I didn’t mean to suggest we extend
the profile using regex matching. Could you perhaps
elaborate?
My
point is that if the profile is supposed to be called
the “privacy” profile it should not be restricted to a
very specific use-case and it should at least cover
other forms of purpose-based policies. My problem is
with the normative policy which addresses only a very
simple use-case while the profile bears the very broad
title of “privacy”.
Regards,
Mohammad
From:
[mailto:]
On Behalf Of Erik Rissanen
Sent: Wednesday, June 04, 2014 7:55 AM
To:
Subject: Re: [xacml] Comments on XACML
Privacy Policy v1.0 profile
Hi
Mohammad,
There are lots of more use cases similar to these, since
various properties could be used in combination. These
would be better handled by the related and nested
entities profile, so rather than expanding specific
attributes here to cover a few use cases by simple regex
matching, I suggest that we put this profile on hold for
now, and review it from ground up based on the entities
profile.
Best regards,
Erik
On 2014-05-26 19:50, Mohammad
Jafari wrote:
Hello,
Now
that we are in the process of public review, I
wanted to share some comments that I have had on the
privacy profile. I think the privacy profile can be
updates to support much broader privacy policies.
Purpose
constraints can take the following basic forms
(there might be more complex/combined forms but
let’s only consider the most common forms):
1.
white list: a list of purposes that are allowed. Any
other purposes will be denied.
2.
black list: a list of prohibited purposes. Any other
purpose will be allowed.
These
constraints can be combined with other authorization
factors and form purpose-based policies. The
following are the main categories for such policies.
These can be combined to form more complex policies.
A. Action-centric:
a purpose constraint on the action or action
attributes: e.g.
"printing
is only allowed for the purpose of treatment."
"research
purpose is forbidden for remote actions."
B. Resource-centric:
a purpose constraints on the use of a certain
resource or a group of resources: e.g.
"Alice's
medical record must only be used for the purpose of
treatment."
"Reproductive
health data must not be used for the purpose of
research."
C. Subject-centric:
a purpose constraint on the subject or a group of
subjects: e.g.
"The
purpose of treatment is forbidden for members of the
role 'admin'."
"Research
staff can only assume the purpose of research."
D. Environment-centric:
a purpose constraint on the environmental
attributes: e.g.
"No
action for the purpose of ‘product research’ is
allowed on the sales department computers."
"The
only purposes allowed outside business hours are
telephone and email marketing."
The
current profile only supports type 1.B.
My
suggestions is that the attributes definitions be
extended and remain normative while the standard
rules section is made non-normative and extended to
incorporate the above forms as different possible
forms of purpose-based policies.
Regards,
Regards,
Mohammad
Jafari, Ph.D.
Security
Architect, Edmond Scientific Company
From:
[mailto:]
On Behalf Of Chet Ensign
Sent: Thursday, May 22, 2014 8:15 AM
To:
Subject: [xacml] Your Public Review for
XACML Privacy Policy v1.0 has been announced
Members of the XACML TC,
Your 15 day public review for
XACML v3.0 Privacy Policy Profile Version 1.0
has been announced. The review ends on 6 June
2014. You can find the announcement at https://www.oasis-open.org/news/announcements/15-day-public-review-for-xacml-v3-0-privacy-policy-profile-v1-0-ends-june-6th.
I have also posted an
announcement to the OASIS and XACML LinkedIn
groups, Twitter and the OASIS FaceBook page.
Feel free to like/comment/retweet these
announcements to spread the word.
Please consider forwarding
these announcement on to other parties who may
be interested in the work. In my experience, TCs
that actively solicit outside review get more
and better quality feedback on their
specifications.
Also, please keep in mind the
OASIS requirements for handling comments [1].
Non-TC member feedback can only be submitted to
the TC's comment list .
The TC must have someone subscribed to this mail
list to monitor comments. All submitted comments
must be acknowledged by the TC. In addition, the
TC needs to maintain a log of comments received
and their resolutions. The comment resolution
log will need to be available when you begin
your next public review. A simple comment
resolution log template is available in
OpenDocument [2] and Office [3] format.
Let me know if you have any
questions regarding the review or next steps.
=== Additional references:
[1] https://www.oasis-open.org/resources/tcadmin/handling-the-comments-received-during-a-public-review
[2] https://www.oasis-open.org/sites/www.oasis-open.org/files/Simple-comment-resolution-log-template_0.ods
[3] https://www.oasis-open.org/sites/www.oasis-open.org/files/Simple-comment-resolution-log-template_0.xls
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC
Administration
OASIS: Advancing open standards for the
information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
Check your work using the
Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html
TC Administration information and support is
available at http://www.oasis-open.org/resources/tcadmin
Follow OASIS on:
LinkedIn: http://linkd.in/OASISopen
Twitter: http://twitter.com/OASISopen
Facebook: http://facebook.com/oasis.open
