OASIS eXtensible Access Control Markup Language (XACML) TC

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: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org]
On Behalf Of Chet Ensign
Sent: Thursday, May 22, 2014 8:15 AM
To: xacml@lists.oasis-open.org
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
xacml-comment@lists.oasis-open.org . 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

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: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Chet Ensign Sent: Thursday, May 22, 2014 8:15 AM To: xacml@lists.oasis-open.org 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 xacml-comment@lists.oasis-open.org . 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

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: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org]
On Behalf Of Erik Rissanen
Sent: Wednesday, June 04, 2014 7:55 AM
To: xacml@lists.oasis-open.org
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:
xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ]
On Behalf Of Chet Ensign
Sent: Thursday, May 22, 2014 8:15 AM
To: xacml@lists.oasis-open.org
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
xacml-comment@lists.oasis-open.org . 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




 

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: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Erik Rissanen Sent: Wednesday, June 04, 2014 7:55 AM To: xacml@lists.oasis-open.org 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: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Chet Ensign Sent: Thursday, May 22, 2014 8:15 AM To: xacml@lists.oasis-open.org 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 xacml-comment@lists.oasis-open.org . 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  

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:erik@axiomatics.com] Sent: Thursday, June 26, 2014 7:00 AM To: Mohammad Jafari; xacml@lists.oasis-open.org 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: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Erik Rissanen Sent: Wednesday, June 04, 2014 7:55 AM To: xacml@lists.oasis-open.org 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: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Chet Ensign Sent: Thursday, May 22, 2014 8:15 AM To: xacml@lists.oasis-open.org 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 xacml-comment@lists.oasis-open.org . 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    

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:erik@axiomatics.com ] Sent: Thursday, June 26, 2014 7:00 AM To: Mohammad Jafari; xacml@lists.oasis-open.org 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: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Erik Rissanen Sent: Wednesday, June 04, 2014 7:55 AM To: xacml@lists.oasis-open.org 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: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Chet Ensign Sent: Thursday, May 22, 2014 8:15 AM To: xacml@lists.oasis-open.org 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 xacml-comment@lists.oasis-open.org . 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    

Whitelists and Blacklists come from Mohammad’s comments. I interpret his comments as suggesting the Profile contain more (sample) policies covering additional usecases.   Hal   From: Erik Rissanen [mailto:erik@axiomatics.com] Sent: Friday, August 08, 2014 3:01 AM To: Hal Lockhart; Mohammad Jafari; xacml@lists.oasis-open.org Subject: Re: [xacml] Comments on XACML Privacy Policy v1.0 profile   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:erik@axiomatics.com ] Sent: Thursday, June 26, 2014 7:00 AM To: Mohammad Jafari; xacml@lists.oasis-open.org 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: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Erik Rissanen Sent: Wednesday, June 04, 2014 7:55 AM To: xacml@lists.oasis-open.org 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: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Chet Ensign Sent: Thursday, May 22, 2014 8:15 AM To: xacml@lists.oasis-open.org 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 xacml-comment@lists.oasis-open.org . 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      

Hi Mohammad, On 27/05/2014 3:50 AM, 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. A black list doesn't sound safe to me. If new purposes are conceived after the data are collected and/or consent obtained, then those new purposes are implicitly allowed by black listing without explicit consent. Under white listing the new purposes are implicitly disallowed. 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. I'm not so sure it even does that. The constraint "Alice's medical record must only be used for the purpose of treatment" would translate into a resource:purpose attribute for Alice's medical record that contained the value "treatment". The rule in Section 4.1 would permit access (i.e., not deny access) if any value of the action:purpose attribute was "treatment". If the action:purpose attribute contained "treatment" and "research", then access would still be permitted (not denied), incorrectly implying that Alice's medical record can also be used for research. The reason for that error is the use of the any-of-any function in the condition. Access is permitted if any action:purpose value matches any resource:purpose value, regardless of the action:purpose values that don't match any resource:purpose value. That's okay if the action:purpose attribute is single-valued, but I didn't see that stated as an assumption. Where the action:purpose attribute is multi-valued I think it should be the case that access is permitted (not denied) if *all* action:purpose values are matched by at least one resource:purpose value. To that end, the function should be any-of-all rather than any-of-any (or expressed using the ForAll and ForAny expressions from the entities profile, which is perhaps what Erik was alluding to in mentioning that profile). 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. I agree that making the rule a MUST is overly restrictive. A SHOULD or RECOMMENDED would be better. It's not clear to me how some of these other forms would be appropriately expressed as simple, illustrative rules. Take "the purpose of treatment is forbidden for members of the role 'admin'", for example. That could be expressed in a deny rule, but that would leave users with both the 'admin' and 'doctor' roles unable to access any records for the purpose of "treatment" (of course I'm assuming doctors are allowed to treat patients :-) ). Role entitlements are normally regarded as additive, which is at odds with the way this constraint is expressed. The "research staff can only assume the purpose of research" constraint has a similar problem. Regards, Steven Regards, Regards, Mohammad Jafari, Ph.D. Security Architect, Edmond Scientific Company *From:*xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] *On Behalf Of *Chet Ensign *Sent:* Thursday, May 22, 2014 8:15 AM *To:* xacml@lists.oasis-open.org *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 xacml-comment@lists.oasis-open.org < mailto:xacml-comment@lists.oasis-open.org >. 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