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
